draft-ietf-rtgwg-ipfrr-notvia-addresses-00.txt   draft-ietf-rtgwg-ipfrr-notvia-addresses-01.txt 
Network Working Group S. Bryant Network Working Group S. Bryant
Internet Draft M. Shand Internet Draft M. Shand
Expiration Date: June 2007 S. Previdi Expiration Date: Jan 2008 S. Previdi
Cisco Systems Cisco Systems
IP Fast Reroute Using Not-via Addresses IP Fast Reroute Using Not-via Addresses
<draft-ietf-rtgwg-ipfrr-notvia-addresses-00.txt> <draft-ietf-rtgwg-ipfrr-notvia-addresses-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress". reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
This draft describes a mechanism that provides fast reroute in an IP This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure, and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics. regardless of network topology and metrics.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 2, line 13 skipping to change at page 2, line 13
regardless of network topology and metrics. regardless of network topology and metrics.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Overview of Not-via Repairs.........................................3 1. Overview of Not-via Repairs.........................................3
1.1 Use of Equal Cost Multi-Path......................................5 1.1 Use of Equal Cost Multi-Path.....................................5
1.2 Use of LFA repairs................................................5 1.2 Use of LFA repairs...............................................5
2. Not-via Repair Path Computation.....................................5 2. Not-via Repair Path Computation.....................................5
3. Operation of Repairs................................................6 3. Operation of Repairs................................................6
3.1 Node Failure......................................................6 3.1 Node Failure.....................................................7
3.2 Link Failure......................................................7 3.2 Link Failure.....................................................7
3.3 Multi-homed Prefix................................................7 3.3 Multi-homed Prefix...............................................8
3.4 Installation of Repair Paths......................................9 3.4 Installation of Repair Paths.....................................9
4. Compound failures..................................................10 4. Compound failures..................................................10
4.1 Shared Risk Link Groups..........................................10 4.1 Shared Risk Link Groups.........................................10
4.1.1 Use of LFAs with SRLGs.......................................14 4.1.1 Use of LFAs with SRLGs......................................14
4.2 Local Area Networks..............................................14 4.2 Local Area Networks.............................................14
4.2.1 Simple LAN Repair............................................15 4.2.1 Simple LAN Repair...........................................15
4.2.2 LAN Component Repair.........................................15 4.2.2 LAN Component Repair........................................16
4.2.3 LAN Repair Using Diagnostics.................................16 4.2.3 LAN Repair Using Diagnostics................................17
5. Multiple Simultaneous Failures.....................................17 5. Multiple Simultaneous Failures.....................................17
6. Optimizing not-via computations using LFAs.........................17 6. Optimizing not-via computations using LFAs.........................18
7. Multicast..........................................................18 7. Multicast..........................................................18
8. Fast Reroute in an MPLS LDP Network................................18 8. Fast Reroute in an MPLS LDP Network................................19
9. Encapsulation......................................................18 9. Encapsulation......................................................19
10. Routing Extensions................................................19 10. Routing Extensions................................................19
11. Incremental Deployment............................................19 11. Incremental Deployment............................................20
12. IANA considerations...............................................19 12. IANA considerations...............................................20
13. Security Considerations...........................................19 13. Security Considerations...........................................20
Introduction Introduction
When a link or a router fails, only the neighbors of the failure are When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network initially aware that the failure has occurred. In a network
operating IP fast reroute [IPFRR], the routers that are the operating IP fast reroute [IPFRR], the routers that are the
neighbors of the failure repair the failure. These repairing routers neighbors of the failure repair the failure. These repairing routers
have to steer packets to their destinations despite the fact that have to steer packets to their destinations despite the fact that
most other routers in the network are unaware of the nature and most other routers in the network are unaware of the nature and
location of the failure. location of the failure.
A common limitation in most IPFRR mechanisms is an inability to A common limitation in most IPFRR mechanisms is an inability to
steer the repaired packet round an identified failure. The extent to indicate the identity of the failure and to explicitly steer the
which this limitation affects the repair coverage is topology repaired packet round the failure. The extent to which this
dependent. The mechanism proposed here is to encapsulate the packet limitation affects the repair coverage is topology dependent. The
to an address that explicitly identifies the network component that mechanism proposed here is to encapsulate the packet to an address
the repair must avoid. This produces a repair mechanism, which, that explicitly identifies the network component that the repair
provided the network is not partitioned by the failure, will always must avoid. This produces a repair mechanism, which, provided the
achieve a repair. network is not partitioned by the failure, will always achieve a
repair.
1. Overview of Not-via Repairs 1. Overview of Not-via Repairs
The purpose of a repair is to deliver packets to their destination The purpose of a repair is to deliver packets to their destination
without traversing a known failure in the network, i.e. to deliver without traversing a known failure in the network, i.e. to deliver
the packet not via the failure. A special address is assigned to the packet not via the failure. A special address is assigned to
each protected component. This address is called the not-via each protected component. This address is called the not-via
address. The semantics of a not-via address are that a packet address. The semantics of a not-via address are that a packet
addressed to a not-via address must be delivered to the router addressed to a not-via address must be delivered to the router
advertising that address, not via the protected component (link, advertising that address, not via (i.e. without traversing or
node, SRLG etc.) with which that address is associated. attempting to traverse) the protected component (link, node, SRLG
etc.) with which that address is associated.
A simple example would be node repair in which an additional address A simple example would be node repair in which an additional address
is assigned to each interface in the network. To repair a failure, is assigned to each interface in the network. To repair a failure,
the repairing router encapsulates the packet to the not-via address the repairing router encapsulates the packet to the not-via address
of the router interface on the far side of the failure. The routers of the router interface on the far side of the failure. The routers
on the repair path then know to which router they must deliver the on the repair path then know to which router they must deliver the
packet, and which network component they must avoid. The network packet, and which network component they must avoid. The network
fragment shown in Figure 1 illustrates a not-via repair for the case fragment shown in Figure 1 illustrates a not-via repair for the case
of a router failure. of a router failure.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
a not-via repair. a not-via repair.
A router computing a not-via repair path MAY subject the repair to A router computing a not-via repair path MAY subject the repair to
ECMP. ECMP.
1.2 Use of LFA repairs 1.2 Use of LFA repairs
The not-via approach provides complete repair coverage and therefore The not-via approach provides complete repair coverage and therefore
may be used as the sole repair mechanism. There are, however, may be used as the sole repair mechanism. There are, however,
advantages in using not-via in combination with loop free alternates advantages in using not-via in combination with loop free alternates
(LFA) as documented in [LFA]. (LFA) and or downstream paths as documented in [LFA].
LFAs are computed on a per destination basis and in general, only a LFAs are computed on a per destination basis and in general, only a
subset of the destinations requiring repair will have a suitable LFA subset of the destinations requiring repair will have a suitable LFA
repair. In this case, those destinations which are repairable by repair. In this case, those destinations which are repairable by
LFAs are so repaired and the remainder of the destinations are LFAs are so repaired and the remainder of the destinations are
repaired using the not-via encapsulation. This has the advantage of repaired using the not-via encapsulation. This has the advantage of
reducing the volume of traffic that requires encapsulation. On the reducing the volume of traffic that requires encapsulation. On the
other hand, the path taken by an LFA repair may be less optimal than other hand, the path taken by an LFA repair may be less optimal than
that of the equivalent not-via repair. The description in this that of the equivalent not-via repair for traffic destined to nodes
document assumes that LFAs will be used where available, but the close to the far end of the failure, but may be more optimal for
distribution of repairs between the two mechanisms is a local some other traffic. The description in this document assumes that
implementation choice. LFAs will be used where available, but the distribution of repairs
between the two mechanisms is a local implementation choice.
2. Not-via Repair Path Computation 2. Not-via Repair Path Computation
The not-via repair mechanism requires that all routers on the path The not-via repair mechanism requires that all routers on the path
from S to B (Figure 1) have a route to Bp. They can calculate this from S to B (Figure 1) have a route to Bp. They can calculate this
by failing node P, running an SPF, and finding the shortest route to by failing node P, running an SPF, and finding the shortest route to
B. B.
A router has no simple way of knowing whether it is on the shortest A router has no simple way of knowing whether it is on the shortest
path for any particular repair. It is therefore necessary for every path for any particular repair. It is therefore necessary for every
skipping to change at page 6, line 30 skipping to change at page 6, line 31
This algorithm is significantly less expensive than a set of full This algorithm is significantly less expensive than a set of full
SPFs. Thus, although a router has to calculate the repair paths for SPFs. Thus, although a router has to calculate the repair paths for
n-1 failures, the computational effort is much less than n-1 SPFs. n-1 failures, the computational effort is much less than n-1 SPFs.
Experiments on a selection of real world network topologies with Experiments on a selection of real world network topologies with
between 40 and 400 nodes suggest that the worst-case computational between 40 and 400 nodes suggest that the worst-case computational
complexity using the above optimizations is equivalent to performing complexity using the above optimizations is equivalent to performing
between 5 and 13 full SPFs. Further optimizations are described in between 5 and 13 full SPFs. Further optimizations are described in
section 6. section 6.
2.1 Computing not-via repairs in routing vector protocols
While this document focuses on link state routing protocols, it is
equally possible to compute not-via repairs in distance vector (e.g.
RIP) or path vector (e.g. BGP) routing protocols. This can be
achieved with very little protocol modification by advertising the
not-via address in the normal way, but ensuring that the information
about a not-via address Ps is not propagated through the node S. In
the case of link protection this simply means that the advertisement
from P to S is suppressed, with the result that S and all other
nodes compute a route to Ps which doesn't traverse S, as required.
In the case of node protection, where P is the protected node, and N
is some neighbor, the advertisement of Np must be suppressed not
only across the link N->P, but also across any link to P. The
simplest way of achieving this is for P itself to perform the
suppression of any address of the form Xp.
3. Operation of Repairs 3. Operation of Repairs
This section explains the basic operation of the not-via repair of This section explains the basic operation of the not-via repair of
node and link failure. node and link failure.
3.1 Node Failure 3.1 Node Failure
When router P fails (Figure 2) S encapsulates any packet that it When router P fails (Figure 2) S encapsulates any packet that it
would send to B via P to Bp, and then sends the encapsulated packet would send to B via P to Bp, and then sends the encapsulated packet
on the shortest path to Bp. S follows the same procedure for routers on the shortest path to Bp. S follows the same procedure for routers
skipping to change at page 9, line 9 skipping to change at page 9, line 21
may be specified by using a special address with the above may be specified by using a special address with the above
semantics. Note that only one such address is required per node. semantics. Note that only one such address is required per node.
Notice that using the not-via approach, only one level of Notice that using the not-via approach, only one level of
encapsulation was needed to repair MHPs to the alternate router. encapsulation was needed to repair MHPs to the alternate router.
3.4 Installation of Repair Paths 3.4 Installation of Repair Paths
The following algorithm is used by node S (Figure 3) to pre- The following algorithm is used by node S (Figure 3) to pre-
calculate and install repair paths in the FIB, ready for immediate calculate and install repair paths in the FIB, ready for immediate
use in the event of a failure. use in the event of a failure. It is assumed that the not-via repair
paths have already been calculated as described above.
For each neighbor P, consider all destinations which are reachable For each neighbor P, consider all destinations which are reachable
via P in the current topology:- via P in the current topology:-
1. For all destinations with an ECMP or LFA repair (as described 1. For all destinations with an ECMP or LFA repair (as described
in [LFA] ) install that repair. in [LFA] ) install that repair.
2. For each destination (DR) that remains, identify in the current 2. For each destination (DR) that remains, identify in the current
topology the next-next-hop (H) (i.e. the neighbor of P that P topology the next-next-hop (H) (i.e. the neighbor of P that P
will use to send the packet to DR). will use to send the packet to DR). This can be determined
during the normal SPF run by recording the additional
3. For each next-next-hop node H for which S has a path to the information. If S has a path to the not-via address Hp (H not
not-via address Hp (H not via P), identify each destination via P), install a not-via repair to Hp for the destination DR.
with current next-next-hop H and install a not-via repair to Hp
for that destination.
4. Identify all remaining destinations (M) which can still be 3. Identify all remaining destinations (M) which can still be
reached when node P fails. These will be multi-homed prefixes reached when node P fails. These will be multi-homed prefixes
that are not repairable by LFA, for which the normal attachment that are not repairable by LFA, for which the normal attachment
node is P, or a router for which P is a single point of node is P, or a router for which P is a single point of
failure, and have an attachment point that is reachable after P failure, and have an alternative attachment point that is
has failed. reachable after P has failed. One way of determining these
destinations would be to run an SPF rooted at S with node P
removed, but an implementation may record alternative
attachment points during the normal SPF run. In either case,
the next best point of attachment can also be determined for
use in step (4) below.
5. For each multi-homed prefix (M) identified in step (4):- 4. For each multi-homed prefix (M) identified in step (3):-
a. Identify the new attachment node (as shown in Figure 3). a. Identify the new attachment node (as shown in Figure 3).
This may be:- This may be:-
i. Y, where the next hop towards Y is P, or i. Y, where the next hop towards Y is P, or
ii. Z, where the next hop towards Z is not P. ii. Z, where the next hop towards Z is not P.
b. If the attachment node is Z, install the repair for M as a b. If the attachment node is Z, install the repair for M as a
tunnel to Z' (where Z' is the address of Z that is used to tunnel to Z' (where Z' is the address of Z that is used to
force local forwarding). force local forwarding).
c. For the subset of prefixes (M) that remain (having c. For the subset of prefixes (M) that remain (having
attachment point Y), install the repair path previously attachment point Y), install the repair path previously
installed for destination Y. installed for destination Y.
skipping to change at page 9, line 50 skipping to change at page 10, line 14
ii. Z, where the next hop towards Z is not P. ii. Z, where the next hop towards Z is not P.
b. If the attachment node is Z, install the repair for M as a b. If the attachment node is Z, install the repair for M as a
tunnel to Z' (where Z' is the address of Z that is used to tunnel to Z' (where Z' is the address of Z that is used to
force local forwarding). force local forwarding).
c. For the subset of prefixes (M) that remain (having c. For the subset of prefixes (M) that remain (having
attachment point Y), install the repair path previously attachment point Y), install the repair path previously
installed for destination Y. installed for destination Y.
6. For each destination (DS) that remains, install a not-via 5. For each destination (DS) that remains, install a not-via
repair to Ps (P not via S). Note, these are destinations for repair to Ps (P not via S). Note, these are destinations for
which node P is a single point of failure, and can only be which node P is a single point of failure, and can only be
repaired by assuming that the apparent failure of node P was repaired by assuming that the apparent failure of node P was
simply a failure of the S-P link. simply a failure of the S-P link. Note that, if available, a
downstream path to P may be used for such a repair. This cannot
generate a persistent loop in the event of the failure of node
P, but if one neighbor of P uses a not-via repair and another
uses a downstream path, it is possible for a packet sent on the
downstream path to be returned to the sending node inside a
not-via encapsulation. Since packets destined to not-via
addresses are not repaired, the packet will be dropped after
executing a single turn loop.
4. Compound failures 4. Compound failures
4.1 Shared Risk Link Groups 4.1 Shared Risk Link Groups
A Shared Risk Link Group (SRLG) is a set of links whose failure can A Shared Risk Link Group (SRLG) is a set of links whose failure can
be caused by a single action such as a conduit cut or line card be caused by a single action such as a conduit cut or line card
failure. When repairing the failure of a link that is a member of an failure. When repairing the failure of a link that is a member of an
SRLG, it must be assumed that all the other links that are also SRLG, it must be assumed that all the other links that are also
members of the SRLG have also failed. Consequently, any repair path members of the SRLG have also failed. Consequently, any repair path
skipping to change at page 21, line 5 skipping to change at page 21, line 26
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full copyright statement Disclaimer of Validity
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Normative References Normative References
There are no normative references. There are no normative references.
Informative References Informative References
Internet-drafts are works in progress available from Internet-drafts are works in progress available from
<http://www.ietf.org/internet-drafts/> <http://www.ietf.org/internet-drafts/>
[BFD] Katz, D., Ward, D., "Bidirectional Forwarding [BFD] Katz, D., Ward, D., "Bidirectional Forwarding
Detection", < draft-ietf-bfd-base-05.txt>, Detection", < draft-ietf-bfd-base-06.txt>,
June 2006, (work in progress). March 2007, (work in progress).
[GRE] S. Hanks, T. Li, D. Farinacci, P. Traina. [GRE] S. Hanks, T. Li, D. Farinacci, P. Traina.
"Generic Routing Encapsulation (GRE)", "Generic Routing Encapsulation (GRE)",
RFC 1701,. October 1994. RFC 1701,. October 1994.
[IPFRR] Shand, M., Bryant, S., "IP Fast-reroute [IPFRR] Shand, M., Bryant, S., "IP Fast-reroute
Framework", Framework",
<draft-ietf-rtgwg-ipfrr-framework-06.txt>, <draft-ietf-rtgwg-ipfrr-framework-07.txt>,
October 2006, (work in progress). June 2007, (work in progress).
[IPIP] Perkins, C., "IP encapsulation within IP", RFC [IPIP] Perkins, C., "IP encapsulation within IP", RFC
2003, October 1996 2003, October 1996
[ISPF] McQuillan, J., I. Richer and E. Rosen, "ARPANET [ISPF] McQuillan, J., I. Richer and E. Rosen, "ARPANET
Routing Algorithm Improvements", BBN Technical Routing Algorithm Improvements", BBN Technical
Report 3803, April 1978. Report 3803, April 1978.
[L2TPv3] J. Lau, Ed., et al., "Layer Two Tunneling [L2TPv3] J. Lau, Ed., et al., "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005. March 2005.
[LDP] Andersson, L., Doolan, P., Feldman, N., [LDP] Andersson, L., Doolan, P., Feldman, N.,
Fredette, A. and B. Thomas, Fredette, A. and B. Thomas,
"LDP Specification", RFC 3036, January 2001. "LDP Specification", RFC 3036, January 2001.
[LFA] A. Atlas, Ed, A. Zinin, Ed, "Basic [LFA] A. Atlas, Ed, A. Zinin, Ed, "Basic
Specification for IP Fast-Reroute: Loop-free Specification for IP Fast-Reroute: Loop-free
Alternates", Alternates",
<draft-ietf-rtgwg-ipfrr-spec-base-05.txt>, <draft-ietf-rtgwg-ipfrr-spec-base-06.txt>,
Feb 2006, (work in progress). March 2007, (work in progress).
[MPLS-TE] Ping Pan, et al, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[NNHL] Shen, N., et al "Discovering LDP Next-Nexthop [NNHL] Shen, N., et al "Discovering LDP Next-Nexthop
Labels", Labels",
<draft-shen-mpls-ldp-nnhop-label-02.txt>, <draft-shen-mpls-ldp-nnhop-label-02.txt>,
May 2005, (work in progress) May 2005, (work in progress)
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119 Indicate Requirement Levels", RFC 2119
Acknowledgements Acknowledgements
 End of changes. 31 change blocks. 
62 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/