draft-ietf-mpls-targeted-mldp-03.txt   draft-ietf-mpls-targeted-mldp-04.txt 
MPLS Working Group Maria Napierala MPLS Working Group Maria Napierala
Internet Draft AT&T Internet Draft AT&T
Intended Status: Standards Track Intended Status: Standards Track
Expires: February 5, 2014 Eric C. Rosen Expires: March 4, 2014 Eric C. Rosen
IJsbrands Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
August 5, 2013 September 4, 2013
Using LDP Multipoint Extensions on Targeted LDP Sessions Using LDP Multipoint Extensions on Targeted LDP Sessions
draft-ietf-mpls-targeted-mldp-03.txt draft-ietf-mpls-targeted-mldp-04.txt
Abstract Abstract
As specified in RFC 6388, Label Distribution Protocol (LDP) can be Label Distribution Protocol (LDP) can be used to set up Point-to-
used to set up Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched
Multipoint (MP2MP) Label Switched Paths. However, RFC 6388 Paths. However, the specification for the Multipoint Extensions to
presupposes that the two endpoints of an LDP session are directly LDP presupposes that the two endpoints of an LDP session are directly
connected. The LDP base specification (RFC 5036) allows for the case connected. The LDP base specification allows for the case where the
where the two endpoints of an LDP session are not directly connected; two endpoints of an LDP session are not directly connected; such a
such a session is known as a "Targeted LDP" session. This document session is known as a "Targeted LDP" session. This document provides
provides the specification for using the LDP P2MP/MP2MP extensions the specification for using the LDP Multipoint Extensions over a
over a Targeted LDP session. Targeted LDP session.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction .......................................... 3 1 Introduction .......................................... 3
1.1 Targeted mLDP ......................................... 3 2 Targeted mLDP and the Upstream LSR .................... 3
1.2 Targeted mLDP and the Upstream LSR .................... 3 2.1 Selecting the Upstream LSR ............................ 3
1.2.1 Selecting the Upstream LSR ............................ 3 2.2 Sending data from U to D .............................. 4
1.2.2 Sending data from U to D .............................. 4 3 Applicability of Targeted mLDP ........................ 5
1.3 Applicability of Targeted mLDP ........................ 5 4 LDP Capabilities ...................................... 5
1.4 LDP Capabilities ...................................... 5 5 Targeted mLDP with Unicast Replication ................ 6
2 Targeted mLDP with Unicast Replication ................ 6 6 Targeted mLDP with Multicast Tunneling ................ 7
3 Targeted mLDP with Multicast Tunneling ................ 7 7 IANA Considerations ................................... 8
4 IANA Considerations ................................... 8 8 Security Considerations ............................... 8
5 Security Considerations ............................... 8 9 Acknowledgments ....................................... 8
6 Acknowledgments ....................................... 8 10 Authors' Addresses .................................... 9
7 Authors' Addresses .................................... 9 11 Normative References .................................. 9
8 Normative References .................................. 9
1. Introduction 1. Introduction
1.1. Targeted mLDP
The Label Distribution Protocol (LDP) extensions for setting up The Label Distribution Protocol (LDP) extensions for setting up
Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and
Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This
set of extensions is generally known as "Multipoint LDP" (mLDP). set of extensions is generally known as "Multipoint LDP" (mLDP).
A pair of Label Switched Routers (LSRs) that are the endpoints of an A pair of Label Switched Routers (LSRs) that are the endpoints of an
LDP session are considered to be "LDP peers". When a pair of LDP LDP session are considered to be "LDP peers". When a pair of LDP
peers are "directly connected" (e.g., they are connected by a layer 2 peers are "directly connected" (e.g., they are connected by a layer 2
medium, or are otherwise considered to be neighbors by the network's medium, or are otherwise considered to be neighbors by the network's
interior routing protocol), the LDP session is said to be a "directly interior routing protocol), the LDP session is said to be a "directly
skipping to change at page 3, line 33 skipping to change at page 3, line 30
The base specification for mLDP does not explicitly cover the case The base specification for mLDP does not explicitly cover the case
where the LDP multipoint extensions are used over a targeted LDP where the LDP multipoint extensions are used over a targeted LDP
session. This document provides that specification. session. This document provides that specification.
We will use the term "Multipoint" to mean "either P2MP or MP2MP". We will use the term "Multipoint" to mean "either P2MP or MP2MP".
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Targeted mLDP and the Upstream LSR 2. Targeted mLDP and the Upstream LSR
1.2.1. Selecting the Upstream LSR 2.1. Selecting the Upstream LSR
In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that is an In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that is an
ordered pair of the form <root, opaque value>. The first element of ordered pair of the form <root, opaque value>. The first element of
the ordered pair is the IP address of the MP-LSP's "root node". The the ordered pair is the IP address of the MP-LSP's "root node". The
second element of the ordered pair is an identifier that is unique in second element of the ordered pair is an identifier that is unique in
the context of the root node. the context of the root node.
If LSR D is setting up the MP-LSP <R, X>, D must determine the If LSR D is setting up the MP-LSP <R, X>, D must determine the
"upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>, "upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>,
U, is defined to be the "next hop" on D's path to R, and "next hop" U, is defined to be the "next hop" on D's path to R, and "next hop"
is tacitly assumed to mean "IGP next hop". It is thus assumed that is tacitly assumed to mean "IGP next hop". It is thus assumed that
there is a direct LDP session between D and U. In this there is a direct LDP session between D and U. In this
specification, we extend the notion of "upstream LSR" to cover the specification, we extend the notion of "upstream LSR" to cover the
following cases: following cases:
- U is the "BGP next hop" on D's path to R, where U and D are not - U is the "BGP next hop" on D's path to R, where U and D are not
IGP neighbors, and where there is a Targeted LDP session between necessarily IGP neighbors, and where there is a Targeted LDP
U and D. In this case, we allow D to select U as the "upstream session between U and D. In this case, we allow D to select U as
LSR" for <R,X>. the "upstream LSR" for <R,X>.
- If the "next hop interface" on D's path to R is an RSVP-TE P2P - If the "next hop interface" on D's path to R is an RSVP-TE P2P
tunnel whose remote endpoint is U, and if there is known to be an tunnel whose remote endpoint is U, and if there is known to be an
RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP
session between U and D, then we allow D to select U as the session between U and D, then we allow D to select U as the
"upstream LSR" for <R,X>. This is useful when D and U are part "upstream LSR" for <R,X>. This is useful when D and U are part
of a network area that is fully meshed via RSVP-TE P2P tunnels. of a network area that is fully meshed via RSVP-TE P2P tunnels.
The particular method used to select an "upstream LSR" is determined The particular method used to select an "upstream LSR" is determined
by the Service Provider (SP). The method to use is determined by by the Service Provider (SP), and must be made known a priori (i.e.,
provisioning; whichever method is used, must be known a priori to all by provisioning) to all the LSRs involved.
the LSRs involved.
Other methods than the two specified above MAY be used; however the Other methods than the two specified above MAY be used; however the
specification of other methods is outside the scope of this document. specification of other methods is outside the scope of this document.
1.2.2. Sending data from U to D 2.2. Sending data from U to D
By using Targeted mLDP, we can construct an MP-LSP <R,X> containing By using Targeted mLDP, we can construct an MP-LSP <R,X> containing
an LSR U, where U has one or more downstream LSR neighbors (D1, ..., an LSR U, where U has one or more downstream LSR neighbors (D1, ...,
Dn) to which it is not directly connected. In order for a data Dn) to which it is not directly connected. In order for a data
packet to travel along this MP-LSP, U must have some way of packet to travel along this MP-LSP, U must have some way of
transmitting the packet to D1, ..., Dn. We will cover two methods of transmitting the packet to D1, ..., Dn. We will cover two methods of
transmission: transmission:
- Unicast Replication. - Unicast Replication.
skipping to change at page 5, line 14 skipping to change at page 5, line 13
may need to discard some of the packets received through the may need to discard some of the packets received through the
tunnel. For example, suppose MP-LSP <R1,X1> contains node U with tunnel. For example, suppose MP-LSP <R1,X1> contains node U with
downstream LSRs D1 and D2, while MP-LSP <R2,X2> contains node U downstream LSRs D1 and D2, while MP-LSP <R2,X2> contains node U
with downstream LSRs D2 and D3. Suppose also that there is a with downstream LSRs D2 and D3. Suppose also that there is a
multicast tunnel with U as root and with D1, D2, and D3 as leaf multicast tunnel with U as root and with D1, D2, and D3 as leaf
nodes. U can aggregate both MP-LSPs in this one tunnel. nodes. U can aggregate both MP-LSPs in this one tunnel.
However, D1 will have to discard packets that are traveling on However, D1 will have to discard packets that are traveling on
<R2,X1>, while D3 will have to discard packets that are traveling <R2,X1>, while D3 will have to discard packets that are traveling
on <R1,X2>. on <R1,X2>.
1.3. Applicability of Targeted mLDP 3. Applicability of Targeted mLDP
When LSR D is setting up MP-LSP <R,X>, it MUST NOT use targeted mLDP When LSR D is setting up MP-LSP <R,X>, it MUST NOT use targeted mLDP
unless D implements a procedure that can select, as the "upstream unless D implements a procedure that can select, as the "upstream
LSR" for <R,X>, an LSR U that is a Targeted mLDP peer of D. See LSR" for <R,X>, an LSR U that is a Targeted mLDP peer of D. See
section 1.2.1. section 2.1.
Whether D uses Targeted mLDP when this condition holds is determined Whether D uses Targeted mLDP when this condition holds is determined
by provisioning, or by other methods that are outside the scope of by provisioning, or by other methods that are outside the scope of
this specification. this specification.
When Targeted mLDP is used, the choice between unicast replication When Targeted mLDP is used, the choice between unicast replication
and multicast tunneling is determined by provisioning, or by other and multicast tunneling is determined by provisioning, or by other
methods that are outside the scope of this specification. It is methods that are outside the scope of this specification. It is
presupposed that all nodes will have a priori knowledge of whether to presupposed that all nodes will have a priori knowledge of whether to
use unicast replication or to use multicast tunneling. If the use unicast replication or to use multicast tunneling. If the
latter, it is presupposed that all nodes will have a priori knowledge latter, it is presupposed that all nodes will have a priori knowledge
of the type of multicast tunneling to use. of the type of multicast tunneling to use.
1.4. LDP Capabilities 4. LDP Capabilities
Per [mLDP], any LSR that needs to set up an MP-LSP must support the Per [mLDP], any LSR that needs to set up an MP-LSP must support the
procedures of [LDP-CAP], and in particular must send and receive the procedures of [LDP-CAP], and in particular must send and receive the
P2MP Capability and/or the MP2MP Capability. This specification does P2MP Capability and/or the MP2MP Capability. This specification does
not define any new capabilities; the advertisement of the P2MP and/or not define any new capabilities; the advertisement of the P2MP and/or
MP2MP Capabilities on a Targeted LDP session means that the MP2MP Capabilities on a Targeted LDP session means that the
advertising LSR is capable of following the procedures of this advertising LSR is capable of following the procedures of this
document. document.
Some of the procedures of this document require the use of upstream- Some of the procedures of this document require the use of upstream-
assigned labels [LDP-UP]. In order to use upstream-assigned labels assigned labels [LDP-UP]. In order to use upstream-assigned labels
as part of Targeted mLDP, an LSR must advertise the LDP Upstream- as part of Targeted mLDP, an LSR must advertise the LDP Upstream-
Assigned Label Capability [LDP-UP] on the Targeted LDP session. Assigned Label Capability [LDP-UP] on the Targeted LDP session.
2. Targeted mLDP with Unicast Replication 5. Targeted mLDP with Unicast Replication
When unicast replication is used, the mLDP procedures are exactly the When unicast replication is used, the mLDP procedures are exactly the
same as described in [mLDP], with the following exception. If LSR D same as described in [mLDP], with the following exception. If LSR D
is setting up MP-LSP <R,X>, its "upstream LSR" is selected according is setting up MP-LSP <R,X>, its "upstream LSR" is selected according
to the procedures of section 1.2.1, and is not necessarily the "IGP to the procedures of section 2.1, and is not necessarily the "IGP
next hop" on D's path to R. next hop" on D's path to R.
Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP
<R,X>, and that LSR U is the upstream LSR on each of their paths to <R,X>, and that LSR U is the upstream LSR on each of their paths to
R. D1 and D2 each binds a label to <R,X>, and each uses a label R. D1 and D2 each binds a label to <R,X>, and each uses a label
mapping message to inform U of the label binding. Suppose D1 has mapping message to inform U of the label binding. Suppose D1 has
assigned label L1 to <R,X> and D2 has assigned label L2 to <R,X>. assigned label L1 to <R,X> and D2 has assigned label L2 to <R,X>.
(Note that L1 and L2 could have the same value or different values; (Note that L1 and L2 could have the same value or different values;
D1 and D2 do not coordinate their label assignments.) When U has a D1 and D2 do not coordinate their label assignments.) When U has a
packet to transmit on the MP-LSP <R,X>, it makes a copy of the packet to transmit on the MP-LSP <R,X>, it makes a copy of the
skipping to change at page 7, line 5 skipping to change at page 7, line 5
by looking up label L1. (And similarly, D2 must receive the copy of by looking up label L1. (And similarly, D2 must receive the copy of
the packet carrying label L2, and must process the packet by looking the packet carrying label L2, and must process the packet by looking
up label L2.) up label L2.)
Note that if the method of unicast is MPLS, U will need to push Note that if the method of unicast is MPLS, U will need to push
another label on each copy of the packet before transmitting it. another label on each copy of the packet before transmitting it.
This label needs to ensure that delivery of the packet to the This label needs to ensure that delivery of the packet to the
appropriate LSR, D1 or D2. Use of penultimate-hop popping for that appropriate LSR, D1 or D2. Use of penultimate-hop popping for that
label is perfectly legitimate. label is perfectly legitimate.
3. Targeted mLDP with Multicast Tunneling 6. Targeted mLDP with Multicast Tunneling
Suppose that LSRs D1 and D2 are both setting up MP-LSP <R,X>, and Suppose that LSRs D1 and D2 are both setting up MP-LSP <R,X>, and
that LSR U is the upstream LSR on each of their paths to R. Since that LSR U is the upstream LSR on each of their paths to R. Since
multicast tunneling is being used, when U has a packet to send on multicast tunneling is being used, when U has a packet to send on
this MP-LSP, it does not necessarily send two copies, one to D1 and this MP-LSP, it does not necessarily send two copies, one to D1 and
one to D2. It may send only one copy of the packet, which will get one to D2. It may send only one copy of the packet, which will get
replicated somewhere downstream in the multicast tunnel. Therefore, replicated somewhere downstream in the multicast tunnel. Therefore,
the label that gets bound to the MP-LSP must be an upstream-assigned the label that gets bound to the MP-LSP must be an upstream-assigned
label, assigned by U. This requires a change from the procedures of label, assigned by U. This requires a change from the procedures of
[mLDP]. D1 and D2 do not send label mapping messages to U; instead [mLDP]. D1 and D2 do not send label mapping messages to U; instead
they send label request messages to U, asking U to assign a label to they send label request messages to U, following the procedures of
the MP-LSP <R,X>. U responds with a label mapping message containing Section 4 of [LDP-UP], asking U to assign a label to the MP-LSP
an upstream-assigned label, L (using the procedures specified in <R,X>. U responds with a label mapping message containing an
[LDP-UP]). As part of the same label mapping message, U also sends upstream-assigned label, L (using the procedures specified in [LDP-
an Interface TLV (as specified in [LDP-UP]) identifying the multicast UP]). As part of the same label mapping message, U also sends an
Interface TLV (as specified in [LDP-UP]) identifying the multicast
tunnel in which data on the MP-LSP will be carried. When U transmits tunnel in which data on the MP-LSP will be carried. When U transmits
a packet on this tunnel, it first pushes on the upstream-assigned a packet on this tunnel, it first pushes on the upstream-assigned
label L, and then pushes on the label that corresponds to the label L, and then pushes on the label that corresponds to the
multicast tunnel. multicast tunnel.
If the numerical value L of the upstream-assigned label is the value If the numerical value L of the upstream-assigned label is the value
3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the 3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the
specified multicast tunnel will carry only the specified MP-LSP. specified multicast tunnel will carry only the specified MP-LSP.
That is, aggregation of multiple MP-LSPs into a single multicast That is, aggregation of multiple MP-LSPs into a single multicast
tunnel is not being done. In this case, no upstream-assigned label tunnel is not being done. In this case, no upstream-assigned label
is pushed onto a packet that is transmitted through the multicast is pushed onto a packet that is transmitted through the multicast
tunnel. tunnel.
Various types of multicast tunnel may be used. The choice of tunnel Various types of multicast tunnel may be used. The choice of tunnel
type is determined by provisioning, or by some other method that is type is determined by provisioning, or by some other method that is
outside the scope of this document. [LDP-UP] specifies encodings outside the scope of this document. [LDP-UP] specifies encodings
allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well
as other types of multicast tunnel. as other types of multicast tunnel.
This document does not specify procedures for tunneling one or more Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are
MP2MP LSPs through P2MP tunnels. While it is possible to do this, it outside the scope of this document.
is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs
(unless, of course, unicast replication is being used).
If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP,
when U transmits a packet on the MP-LSP <R,X>, the upstream-assigned when U transmits a packet on the MP-LSP <R,X>, the upstream-assigned
label L will be the second label in the label stack. Penultimate-hop label L will be the second label in the label stack. Penultimate-hop
popping MUST NOT be done, because the top label provides the context popping MUST NOT be done, because the top label provides the context
in which the second label is to be interpreted. See [RFC5331]. in which the second label is to be interpreted. See [RFC5331].
When LSR U uses these procedures to inform LSR D that a particular When LSR U uses these procedures to inform LSR D that a particular
MP-LSP is being carried in a particular multicast tunnel, U and D MP-LSP is being carried in a particular multicast tunnel, U and D
MUST take appropriate steps to ensure that packets U sends into this MUST take appropriate steps to ensure that packets U sends into this
skipping to change at page 8, line 28 skipping to change at page 8, line 27
by those packets will not be recognized by D3, hence D3 will discard by those packets will not be recognized by D3, hence D3 will discard
those packets. Similarly, D1 will discard the <R2,X2> packets. those packets. Similarly, D1 will discard the <R2,X2> packets.
This document does not specify any rules for deciding whether to This document does not specify any rules for deciding whether to
aggregate two or more MP-LSPs into a single multicast tunnel. Such aggregate two or more MP-LSPs into a single multicast tunnel. Such
rules are outside the scope of this document. rules are outside the scope of this document.
Except for the procedures explicitly detailed in this document, the Except for the procedures explicitly detailed in this document, the
procedures of [mLDP] and [LDP-UP] apply unchanged. procedures of [mLDP] and [LDP-UP] apply unchanged.
4. IANA Considerations 7. IANA Considerations
This document has no considerations for IANA. This document has no considerations for IANA.
5. Security Considerations 8. Security Considerations
This document raises no new security considerations beyond those This document raises no new security considerations beyond those
discussed in [LDP], [LDP-UP], and [RFC5331]. discussed in [LDP], [LDP-UP], and [RFC5331].
6. Acknowledgments 9. Acknowledgments
The authors wish to think Lizhong Jin and Lizhen Bin for their The authors wish to thank Lizhong Jin and Lizhen Bin for their
comments. comments.
7. Authors' Addresses 10. Authors' Addresses
Maria Napierala Maria Napierala
AT&T Labs AT&T Labs
200 Laurel Avenue, Middletown, NJ 07748 200 Laurel Avenue, Middletown, NJ 07748
USA
E-mail: mnapierala@att.com E-mail: mnapierala@att.com
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA, 01719 Boxborough, MA, 01719
USA
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831 De kleetlaan 6a Diegem 1831
Belgium Belgium
E-mail: ice@cisco.com E-mail: ice@cisco.com
8. Normative References 11. Normative References
[LDP] Loa Andersson, Ina Minei, Bob Thomas, editors, "LDP [LDP] Loa Andersson, Ina Minei, Bob Thomas, editors, "LDP
Specification", RFC 5036, October 2007 Specification", RFC 5036, October 2007
[LDP-CAP] Bob Thomas, Kamran Raza, Shivani Aggarwal, Rahul Aggarwal, [LDP-CAP] Bob Thomas, Kamran Raza, Shivani Aggarwal, Rahul Aggarwal,
Jean-Louis Le Roux, "LDP Capabilities", RFC 5561, July 2009 Jean-Louis Le Roux, "LDP Capabilities", RFC 5561, July 2009
[mLDP] IJsbrand Wijnands, Ina Minei, Kireeti Kompella, Bob Thomas, [mLDP] IJsbrand Wijnands, Ina Minei, Kireeti Kompella, Bob Thomas,
"Label Distribution Protocol Extensions for Point-to-Multipoint and "Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November
 End of changes. 27 change blocks. 
59 lines changed or deleted 55 lines changed or added

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