[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt
On Tuesday, Apr 8, 2003, at 10:56 Canada/Eastern, Michel Py wrote:
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>jabley@isc.org</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>jabley@mfnx.net</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">