Subject: RE: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt

From: "Michel Py" <[email-masked]>
Date: Tue, 8 Apr 2003 07:56:56 -0700

Are there any changes other than the removal of normative language?

Michel.

Me and Sean will give people the time to (re-)read this document, and  
in two weeks issue WG last call on this. I hope this should not be to  
controversial...:-)

- kurtis -

On måndag, apr 7, 2003, at 13:10 Europe/Stockholm,  
[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Site Multihoming in IPv6 Working  
> Group of the IETF.
>
> 	Title		: Goals for IPv6 Site-Multihoming Architectures
> 	Author(s)	: B. Black, V. Gill, J. Abley
> 	Filename	: draft-ietf-multi6-multihoming-requirements-04.txt
> 	Pages		: 9
> 	Date		: 2003-4-4
> 	
> Site-multihoming, i.e. connecting to more than one IP service
> provider, is an essential component of service for many sites which
> are part of the Internet.  Existing IPv4 site-multihoming practices
> provide a set of capabilities that it would ideally be accommodated
> by the adopted site-multihoming architecture in IPv6, and a set of
> limitations that must be overcome, relating in particular to
> scalability.
> This document outlines a set of goals for proposed new IPv6
> site-multihoming architectures.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- 
> requirements-04.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the  
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-multi6-multihoming-requirements-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE  
> /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID:	<[email-masked]>

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2003 13:48:42 -0400

> Are there any changes other than the removal of normative language?

Here's a unified diff of the rfc2629 xml source for the document (which 
should give an idea of the content changes without the noise of 
formatting changes):

Index: draft-ietf-multi6-multihoming-requirements.xml
===================================================================
RCS file: 
/home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- draft-ietf-multi6-multihoming-requirements.xml      18 Jul 2002 
15:30:57 -0000      1.2
+++ draft-ietf-multi6-multihoming-requirements.xml      4 Apr 2003 
00:55:37 -0000       1.3
@@ -1,11 +1,31 @@
  <?xml version="1.0"?>
  <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
-<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-03">
+
+<?rfc strict="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+
+<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-04">
  <front>
-  <title abbrev="IPv6 Site-Multihoming Requirements">
-    Requirements for IPv6 Site-Multihoming Architectures
+  <title abbrev="IPv6 Site-Multihoming Goals">
+    Goals for IPv6 Site-Multihoming Architectures
    </title>

+  <author initials="J." surname="Abley" fullname="Joe Abley">
+    <organization abbrev="ISC">Internet Software 
Consortium</organization>
+    <address>
+      <postal>
+        <street>10805 Old River Road</street>
+        <country>Canada</country>
+        <code>N0L 1R0</code>
+        <region>ON</region>
+        <city>Komoka</city>
+      </postal>
+      <phone>+1 519 641 4368</phone>
+      <email>[email-masked]</email>
+    </address>
+  </author>
+
    <author initials="B." surname="Black" fullname="Benjamin Black">
      <organization>Layer8 Networks</organization>
      <address>
@@ -20,39 +40,23 @@
      </address>
    </author>

-  <author initials="J." surname="Abley" fullname="Joe Abley">
-    <organization>MFN</organization>
-    <address>
-      <postal>
-        <street>10805 Old River Road</street>
-        <country>Canada</country>
-        <code>N0L 1R0</code>
-        <region>ON</region>
-        <city>Komoka</city>
-      </postal>
-      <phone>+1 519 641 4368</phone>
-      <email>[email-masked]</email>
-    </address>
-  </author>
-
-  <date month="May" year="2002" />
+  <date month="April" year="2003" />

    <area>Operations and Management</area>
-  <workgroup>Site Multihoming in IPv6 (multi6)</workgroup>
+  <workgroup>multi6</workgroup>

    <abstract>
      <t>Site-multihoming, i.e. connecting to more than one IP service
        provider, is an essential component of service for many sites
        which are part of the Internet.  Existing IPv4 site-multihoming
-      practices, described in a companion draft
-      <xref target="refs.draft-ietf-multi6-v4-multihoming-00" />,
-      provides a set of capabilities that must be accommodated
+      practices provide a set of capabilities that it would ideally
+      be accommodated
        by the adopted site-multihoming architecture in IPv6, and a
        set of limitations that must be overcome, relating in particular
        to scalability.</t>

-    <t>This document outlines a set of requirements for a new IPv6
-      site-multihoming architecture.</t>
+    <t>This document outlines a set of goals for proposed new IPv6
+      site-multihoming architectures.</t>
    </abstract>
  </front>

@@ -62,8 +66,7 @@
      <t>Current IPv4 site-multihoming practices have been added
        on to the CIDR architecture <xref target="refs.RFC1519" />,
        which assumes that routing table entries can be aggregated based
-      upon a hierarchy of customers and service providers
-      <xref target="refs.draft-ietf-multi6-v4-multihoming-00" />.</t>
+      upon a hierarchy of customers and service providers.</t>

      <t>However,
        it appears that this hierarchy is being supplanted by a dense 
mesh
@@ -85,11 +88,6 @@
    </section>

    <section anchor="terms" title="Terminology">
-    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT",
-      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 
this
-      document are to be interpreted as described in RFC 2119
-      <xref target="refs.RFC2119" />.</t>
-
      <t>A "site" is an entity autonomously operating a network
        using IP and, in particular, determining the addressing
        plan and routing policy for that network. This definition
@@ -112,15 +110,14 @@
        connectivity between the site and its transit providers' 
sites.</t>
    </section>

-  <section anchor="multihoming" title="Multihoming Requirements">
+  <section anchor="multihoming" title="Multihoming Goals">
      <section anchor="v4" title="Capabilities of IPv4 Multihoming">
        <t>The following capabilities of current IPv4 multihoming
-        practices MUST be supported by an IPv6 multihoming
-        architecture. IPv4 multihoming is discussed in more detail
-        in <xref target="refs.draft-ietf-multi6-v4-multihoming-00" 
/>.</t>
+        practices should be supported by an IPv6 multihoming
+        architecture.</t>

        <section anchor="redundancy" title="Redundancy">
-        <t>By multihoming, a site MUST be able to
+        <t>By multihoming, a site should be able to
            insulate itself from certain failure modes within one or
            more transit providers, as well as failures in the network
            providing interconnection among one or more transit 
providers.</t>
@@ -135,7 +132,7 @@
            single incident in the street. The two circuits are said
            to "share fate".</t>

-        <t>The multihoming architecture MUST accommodate (in the 
general
+        <t>The multihoming architecture should accommodate (in the 
general
            case, issues of shared fate notwithstanding) continuity of
            connectivity during the following failures:

@@ -152,7 +149,7 @@
        </section>

        <section anchor="loadshare" title="Load Sharing">
-        <t>By multihoming, a site MUST be able to
+        <t>By multihoming, a site should be able to
            distribute both inbound and outbound traffic between multiple
            transit providers. This requirement is for concurrent
            use of the multiple transit providers, not just the usage
@@ -161,19 +158,19 @@
        </section>

        <section anchor="performance" title="Performance">
-        <t>By multihoming, a site MUST be able to protect
+        <t>By multihoming, a site should be able to protect
            itself from performance difficulties directly between
            the site's transit providers.</t>

          <t>For example, suppose site E obtains transit from transit
            providers T1 and T2, and there is long-term congestion 
between
-          T1 and T2. The multihoming architecture MUST allow E to
+          T1 and T2. The multihoming architecture should allow E to
            ensure that
            in normal operation none of its traffic is carried
            over the congested interconnection T1-T2. The process
-          by which this is achieved MAY be a manual one.</t>
+          by which this is achieved should be a manual one.</t>

-        <t>A multihomed site MUST be able to distribute
+        <t>A multihomed site should be able to distribute
            inbound traffic from particular multiple transit providers 
according
            to the particular address range within their site which is
            sourcing or sinking the traffic.</t>
@@ -184,7 +181,7 @@
            beyond technical scope (e.g. cost, acceptable use 
conditions, etc.)
            For example, customer C homed to ISP A may wish to shift 
traffic of a
            certain class or application, NNTP, for example, to ISP B as 
matter
-          of policy.  A new IPv6 multihoming proposal MUST provide 
support
+          of policy.  A new IPv6 multihoming proposal should provide 
support
            for site-multihoming for external policy reasons.</t>
        </section>

@@ -193,13 +190,13 @@
            networks with real customers, simplicity is paramount. The
            current multihoming solution is quite
            straightforward to deploy and maintain. A new IPv6 
multihoming
-          proposal MUST NOT be substantially more complex to deploy and
+          proposal should not be substantially more complex to deploy 
and
            operate than current IPv4 multihoming practices.</t>
        </section>

        <section anchor="transportSurvivability" title="Transport-Layer
          Survivability">
-        <t>Multihoming solutions MUST provide re-homing transparency
+        <t>Multihoming solutions should provide re-homing transparency
            for transport-layer sessions;
            i.e. exchange of data between devices on
            the multihomed site and devices elsewhere
@@ -207,25 +204,25 @@
            that associated with the transient packet loss during the
            re-homing event.</t>

-        <t>New transport-layer sessions MUST be able to be created
+        <t>New transport-layer sessions should be able to be created
            following a re-homing event.</t>

          <t>Transport-layer sessions include those involving
            transport-layer protocols such as TCP, UDP and SCTP
            over IP. Applications which communicate over raw
-          IP and other network-layer protocols MAY also enjoy
+          IP and other network-layer protocols may also enjoy
            re-homing transparency.</t>
        </section>

        <section anchor="dns" title="Impact on DNS">
-        <t>Multi-homing solutions either MUST be compatible with the
+        <t>Multi-homing solutions either should be compatible with the
            observed dynamics of the current DNS system, or the solutions
-          MUST have demonstrate that the modified name resolution
+          should demonstrate that the modified name resolution
            system required to support them are readily deployable.</t>
        </section>

        <section anchor="antiSpoofing" title="Packet Filtering">
-        <t>Multihoming solutions MUST NOT preclude filtering packets
+        <t>Multihoming solutions should not preclude filtering packets
            with forged or otherwise inappropriate source IP addresses
            at the administrative boundary of the multihomed site.</t>
        </section>
@@ -241,24 +238,24 @@
            of the routing system. This issue is discussed in great
            detail in <xref target="refs.Huston" />.</t>

-        <t>A new IPv6 multihoming architecture MUST scale
+        <t>A new IPv6 multihoming architecture should scale
            to accommodate orders of magnitude more multihomed sites
            without imposing unreasonable requirements on the routing
            system.</t>
        </section>

        <section anchor="routerImpact" title="Impact on Routers">
-        <t>The solution MAY require changes to IPv6 router 
implementations,
+        <t>The solution may require changes to IPv6 router 
implementations,
            but these changes must be either minor, or in the form of 
logically
            separate functions added to existing functions.</t>

-        <t>Such changes MUST NOT prevent normal single-homed 
operation, and
+        <t>Such changes should not prevent normal single-homed 
operation, and
            routers implementing these changes must be able to 
interoperate
            fully with hosts and routers not implementing them.</t>
        </section>

        <section anchor="hostImpact" title="Impact on Hosts">
-        <t>The solution MUST NOT destroy IPv6 connectivity for a 
legacy host
+        <t>The solution should not destroy IPv6 connectivity for a 
legacy host
            implementing RFC 2373 <xref target="refs.RFC2373" />,
            RFC 2460 <xref target="refs.RFC2460" />,
            RFC 2553 <xref target="refs.RFC2553" /> and other basic IPv6
@@ -273,41 +270,41 @@
            connections were still operational.</t>

          <t>If the solution requires changes to the host stack, these 
changes
-          MUST be either minor, or in the form of logically separate 
functions
+          should be either minor, or in the form of logically separate 
functions
            added to existing functions.</t>

          <t>If the solution requires changes to the socket API and/or 
the
-          transport layer, it MUST be possible to retain the original
+          transport layer, it should be possible to retain the original
            socket API and transport protocols in parallel, even if they
            cannot benefit from multihoming.</t>

-        <t>The multihoming solution MAY allow host or application
+        <t>The multihoming solution may allow host or application
            changes if that would enhance session survivability.</t>
        </section>

        <section anchor="hostrouter" title="Interaction between Hosts and
          the Routing System">
-        <t>The solution MAY involve interaction between a site's hosts
-          and its routing system; such an interaction MUST be simple,
+        <t>The solution may involve interaction between a site's hosts
+          and its routing system; such an interaction should be simple,
            scaleable and securable.</t>
        </section>

        <section anchor="operations" title="Operations and Management">
-        <t>It MUST be posssible for staff responsible for the operation
+        <t>It should be posssible for staff responsible for the 
operation
            of a site to monitor and configure the site's
            multihoming system.</t>
        </section>

        <section anchor="cooperation" title=
          "Cooperation between Transit Providers">
-        <t>A multihoming strategy MAY require cooperation between a 
site
-          and its transit providers, but MUST NOT require cooperation
+        <t>A multihoming strategy may require cooperation between a 
site
+          and its transit providers, but should not require cooperation
            (relating specifically to the multihomed site)
            directly between the transit providers.</t>
        </section>

        <section anchor="multipleSolutions" title="Multiple Solutions">
-        <t>There MAY be more than one approach to multihoming, provided
+        <t>There may be more than one approach to multihoming, provided
            all approaches are orthogonal (e.g. each approach addresses
            a distinct segment or category within the site multihoming
            problem. Multiple solutions will incur a greater management
@@ -320,31 +317,13 @@
    </section>

    <section anchor="security" title="Security Considerations">
-    <t>A multihomed site MUST NOT be more vulnerable to
+    <t>A multihomed site should not be more vulnerable to
        security breaches than a traditionally IPv4-multihomed site.</t>
    </section>
  </middle>

  <back>
-  <references>
-    <reference anchor="refs.draft-ietf-multi6-v4-multihoming-00">
-      <front>
-        <title>IPv4 Multihoming Motivation, Practices and
-          Limitations (work-in-progress)</title>
-        <author initials="J." surname="Abley" fullname="Joe Abley">
-          <organization>Metromedia Fiber Network Inc.</organization>
-        </author>
-        <author initials="B." surname="Black" fullname="Benjamin 
Black">
-          <organization>Layer8 Networks</organization>
-        </author>
-        <author initials="V." surname="Gill" fullname="Vijay Gill">
-          <organization>Metromedia Fiber Network Inc.</organization>
-        </author>
-        <date month="June" year="2001" />
-      </front>
-      <seriesInfo name="I-D" 
value="draft-ietf-multi6-v4-multihoming-00" />
-    </reference>
-
+  <references title="Normative References">
      <reference anchor="refs.RFC1519">
        <front>
          <title>Classless Inter-Domain Routing (CIDR): an Address
@@ -387,18 +366,6 @@
          <date month="February" year="1996" />
        </front>
        <seriesInfo name="RFC" value="1918" />
-    </reference>
-
-    <reference anchor="refs.RFC2119">
-      <front>
-        <title>Key words for use in RFCs to Indicate
-          Requirement Levels</title>
-        <author initials="S." surname="Bradner">
-          <organization>Harvard University</organization>
-        </author>
-        <date month="March" year="1997" />
-      </front>
-      <seriesInfo name="RFC" value="2119" />
      </reference>

      <reference anchor="refs.RFC2373">