Subject: requirements-06

From: Joe Abley <[email-masked]>
Date: Fri, 16 May 2003 13:28:13 -0400

Revised draft, attached below, has been sent in and should appear in 
the usual places in due course. Apologies for the delay in making these 
changes.

RFC 2629 source diff follows.

[jabley@snowfall]% cvs diff -u -r 1.5 -r 1.6 
draft-ietf-multi6-multihoming-requirements.xml
Index: draft-ietf-multi6-multihoming-requirements.xml
===================================================================
RCS file: 
/home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- draft-ietf-multi6-multihoming-requirements.xml      16 Apr 2003 
13:40:47 -0000      1.5
+++ draft-ietf-multi6-multihoming-requirements.xml      16 May 2003 
17:19:43 -0000      1.6
@@ -5,7 +5,7 @@
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>

-<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-05">
+<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-06">
  <front>
    <title abbrev="IPv6 Site-Multihoming Goals">
      Goals for IPv6 Site-Multihoming Architectures
@@ -15,13 +15,13 @@
      <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>
+        <street>950 Charter Street</street>
+        <country>USA</country>
+        <code>94063</code>
+        <region>CA</region>
+        <city>Redwood City</city>
        </postal>
-      <phone>+1 519 641 4368</phone>
+      <phone>+1 650 423 1317</phone>
        <email>[email-masked]</email>
      </address>
    </author>
@@ -43,7 +43,7 @@
    <date month="April" year="2003" />

    <area>Operations and Management</area>
-  <workgroup>multi6</workgroup>
+  <workgroup>Network Working Group</workgroup>

    <abstract>
      <t>Site-multihoming, i.e. connecting to more than one IP service
@@ -65,16 +65,15 @@

      <t>However,
        it appears that this hierarchy is being supplanted by a dense 
mesh
-      of interconnections <xref target="refs.Huston" />.  Additionally,
+      of interconnections <xref target="refs.RFC3221" />.  
Additionally,
        there has been an enormous growth in the number of multihomed
        sites. For purposes of redundancy and load-sharing, the
-      multihomed address blocks, which are almost always a longer 
prefix
-      than the provider aggregate, are announced along with the larger,
-      covering
-      aggregate originated by the provider. This contributes to the
-      rapidly-increasing size
-      of the global routing table. This explosion places significant
-      stress on the inter-provider routing system.</t>
+      multihomed address blocks are introduced into the global table
+      even if they are covered by a provider aggregate.
+      This contributes to the
+      rapidly-increasing size of both
+      the global routing table and the turbulence exhibited within
+      it, and places stress on the inter-provider routing system.</t>

      <t>Continued growth of both the Internet and the practice of
        site-multihoming will seriously exacerbate this stress. The
@@ -123,7 +122,8 @@
            circuits ordered from different suppliers and connecting
            a site to independent transit providers may share a single
            conduit from the street into a building; in this case
-          backhoe-fade of both circuits may be experienced due to a
+          physical disruption (sometimes referred to as
+          "backhoe-fade") of both circuits may be experienced due to a
            single incident in the street. The two circuits are said
            to "share fate".</t>

@@ -146,7 +146,7 @@
        <section anchor="loadshare" title="Load Sharing">
          <t>By multihoming, a site should be able to
            distribute both inbound and outbound traffic between multiple
-          transit providers. This requirement is for concurrent
+          transit providers. This goal is for concurrent
            use of the multiple transit providers, not just the usage
            of one provider over one interval of time and another 
provider
            over a different interval.</t>
@@ -184,9 +184,12 @@
          <t>As any proposed multihoming solution must be deployed in 
real
            networks with real customers, simplicity is paramount. The
            current multihoming solution is quite
-          straightforward to deploy and maintain. A new IPv6 
multihoming
-          proposal should not be substantially more complex to deploy 
and
-          operate than current IPv4 multihoming practices.</t>
+          straightforward to deploy and maintain.</t>
+
+         <t>A new IPv6 multihoming
+          solution should not be substantially more complex to deploy 
and
+          operate (for multihomed sites or for the rest of the 
Internet)
+          than current IPv4 multihoming practices.</t>
        </section>

        <section anchor="transportSurvivability" title="Transport-Layer
@@ -213,13 +216,14 @@
          <t>Multi-homing solutions either should be compatible with the
            observed dynamics of the current DNS system, or the solutions
            should demonstrate that the modified name resolution
-          system required to support them are readily deployable.</t>
+          system required to support them is readily deployable.</t>
        </section>

        <section anchor="antiSpoofing" title="Packet Filtering">
          <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>
+          at the administrative boundary of the multihomed site, or
+          at the administrative boundaries of any site in the 
Internet.</t>
        </section>
      </section>

@@ -231,7 +235,7 @@
            is a concern both because of the hardware requirements
            it imposes and also because of the impact on the stability
            of the routing system. This issue is discussed in great
-          detail in <xref target="refs.Huston" />.</t>
+          detail in <xref target="refs.RFC3221" />.</t>

          <t>A new IPv6 multihoming architecture should scale
            to accommodate orders of magnitude more multihomed sites
@@ -240,7 +244,7 @@
        </section>

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

@@ -253,7 +257,7 @@
          <t>The solution should not destroy IPv6 connectivity for a 
legacy host
            implementing RFC 3513 <xref target="refs.RFC3513" />,
            RFC 2460 <xref target="refs.RFC2460" />,
-          RFC 2553 <xref target="refs.RFC2553" /> and other basic IPv6
+          RFC 3493 <xref target="refs.RFC3493" /> and other basic IPv6
            specifications current in April 2003. That is to say, if a 
host
            can work
            in a single-homed site, it should still be able to work in a
@@ -274,7 +278,7 @@
            cannot benefit from multihoming.</t>

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

        <section anchor="hostrouter" title="Interaction between Hosts and
@@ -285,7 +289,7 @@
        </section>

        <section anchor="operations" title="Operations and Management">
-        <t>It should be posssible for staff responsible for the 
operation
+        <t>It should be possible for staff responsible for the 
operation
            of a site to monitor and configure the site's
            multihoming system.</t>
        </section>
@@ -296,6 +300,11 @@
            and its transit providers, but should not require cooperation
            (relating specifically to the multihomed site)
            directly between the transit providers.</t>
+
+        <t>The impact of any inter-site cooperation that might be
+          required to facilitate the multihoming solution should be
+          examined and assessed from the point of view of operational
+          practicality.</t>
        </section>

        <section anchor="multipleSolutions" title="Multiple Solutions">
@@ -381,23 +390,6 @@
        <seriesInfo name="RFC" value="3513" />
      </reference>

-    <reference anchor="refs.RFC2374">
-      <front>
-        <title>An IPv6 Aggregatable Global Unicast Address 
Format</title>
-        <author initials="R." surname="Hinden">
-          <organization>Nokia</organization>
-        </author>
-        <author initials="M." surname="O'Dell">
-          <organization>UUNET</organization>
-        </author>
-        <author initials="S." surname="Deering">
-          <organization>Cisco</organization>
-        </author>
-        <date month="July" year="1998" />
-      </front>
-      <seriesInfo name="RFC" value="2374" />
-    </reference>
-
      <reference anchor="refs.RFC2460">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) 
Specification</title>
@@ -412,34 +404,35 @@
        <seriesInfo name="RFC" value="2460" />
      </reference>

-    <reference anchor="refs.RFC2553">
+    <reference anchor="refs.RFC3493">
        <front>
          <title>Basic Socket Interface Extensions for IPv6</title>
          <author initials="R." surname="Gilligan">
-          <organization>FreeGate</organization>
+          <organization>Intransa, Inc.</organization>
          </author>
          <author initials="S." surname="Thomson">
-          <organization>Bellcore</organization>
+          <organization>Cisco Systems</organization>
          </author>
          <author initials="J." surname="Bound">
-          <organization>Compaq</organization>
+          <organization>Hewlett-Packard Company</organization>
          </author>
-        <author initials="W." surname="Stevens">
-          <organization>Consultant</organization>
+        <author initials="J." surname="McCann">
+          <organization>Hewlett-Packard Company</organization>
          </author>
-        <date month="March" year="1999" />
+        <date month="February" year="2003" />
        </front>
-      <seriesInfo name="RFC" value="2553" />
+      <seriesInfo name="RFC" value="3493" />
      </reference>

-    <reference anchor="refs.Huston">
+    <reference anchor="refs.RFC3221">
        <front>
-        <title>Analyzing the Internet's BGP Routing Table</title>
+        <title>Commentary on Inter-Domain Routing in the 
Internet</title>
          <author initials="G." surname="Huston">
            <organization>Telstra</organization>
          </author>
-        <date month="January" year="2001" />
+        <date month="December" year="2001" />
        </front>
+      <seriesInfo name="RFC" value="3221" />
      </reference>
    </references>
  </back>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 May 2003 13:35:23 +0200

Great. Let's ship it and move on.

  Brian

Joe Abley wrote:
> the usual places in due course.