draft-ietf-mpls-ldp-p2mp-01.txt   draft-ietf-mpls-ldp-p2mp-02.txt 
Network Working Group I. Minei (Editor) Network Working Group I. Minei (Editor)
Internet-Draft K. Kompella Internet-Draft K. Kompella
Expires: December 27, 2006 Juniper Networks Intended status: Standards Track Juniper Networks
I. Wijnands (Editor) Expires: December 3, 2006 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
June 25, 2006
Label Distribution Protocol Extensions for Point-to-Multipoint and Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-01 draft-ietf-mpls-ldp-p2mp-02
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 38 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on December 27, 2006. This Internet-Draft will expire on December 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to- (LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 4 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 4
2.1. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4 2.1. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4
2.2. The LDP MP Opaque Value Element . . . . . . . . . . . . . 6 2.2. The LDP MP Opaque Value Element . . . . . . . . . . . . . 6
2.2.1. The Generic LSP Identifier . . . . . . . . . . . . . . 6 2.2.1. The Generic LSP Identifier . . . . . . . . . . . . . . 6
2.3. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 7 2.3. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 7
2.3.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 9
3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 11 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 11
4.1. The MP2MP downstream and upstream FEC elements. . . . . . 11 4.1. The MP2MP downstream and upstream FEC elements. . . . . . 11
4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 12 4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 11
4.2.1. MP2MP Label Map upstream and downstream . . . . . . . 13 4.2.1. MP2MP Label Map upstream and downstream . . . . . . . 13
4.2.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 15 4.2.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 15
5. mLDP wildcard FECs . . . . . . . . . . . . . . . . . . . . . . 16 5. Upstream label allocation on Ethernet networks . . . . . . . . 16
5.1. Label Request Message . . . . . . . . . . . . . . . . . . 16 6. Root node redundancy for MP2MP LSPs . . . . . . . . . . . . . 16
5.2. Label Withdraw Message . . . . . . . . . . . . . . . . . . 16 6.1. Root node redundancy procedure . . . . . . . . . . . . . . 16
5.3. Label Release Message . . . . . . . . . . . . . . . . . . 17 7. Make before break . . . . . . . . . . . . . . . . . . . . . . 17
6. Upstream label allocation on Ethernet networks . . . . . . . . 17 7.1. Protocol event . . . . . . . . . . . . . . . . . . . . . . 18
7. Root node redundancy for MP2MP LSPs . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Root node redundancy procedure . . . . . . . . . . . . . . 17 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Make before break . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Protocol event . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributing authors . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
The LDP protocol is described in [1]. It defines mechanisms for The LDP protocol is described in [1]. It defines mechanisms for
setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs
in the network. This document describes extensions to LDP for in the network. This document describes extensions to LDP for
setting up point-to-multipoint (P2MP) and multipoint-to-multipoint setting up point-to-multipoint (P2MP) and multipoint-to-multipoint
(MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP2MP) LSPs. These are collectively referred to as multipoint LSPs
(MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress)
node to be delivered to a number of leaf (or egress) nodes. A MP2MP node to be delivered to a number of leaf (or egress) nodes. A MP2MP
skipping to change at page 5, line 22 skipping to change at page 5, line 22
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | | Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the P2MP FEC element is to be assigned by IANA, Type: The type of the P2MP FEC element is to be assigned by IANA.
such that the U-bit is set (=1) and the F-bit is clear (=0). This
ensures that an LSR which cannot process the P2MP FEC element,
silently ignores it.
Address Family: Two octet quantity containing a value from ADDRESS Address Family: Two octet quantity containing a value from ADDRESS
FAMILY NUMBERS in [3] that encodes the address family for the Root FAMILY NUMBERS in [3] that encodes the address family for the Root
LSR Address. LSR Address.
Address Length: Length of the Root LSR Address in octets. Address Length: Length of the Root LSR Address in octets.
Root Node Address: A host address encoded according to the Address Root Node Address: A host address encoded according to the Address
Family field. Family field.
skipping to change at page 6, line 13 skipping to change at page 6, line 9
Address Lengths are defined at present. Address Lengths are defined at present.
If the Address Length doesn't match the defined length for the If the Address Length doesn't match the defined length for the
Address Family, the receiver SHOULD abort processing the message Address Family, the receiver SHOULD abort processing the message
containing the FEC Element, and send an "Unknown FEC" Notification containing the FEC Element, and send an "Unknown FEC" Notification
message to its LDP peer signaling an error. message to its LDP peer signaling an error.
If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST
be the only FEC Element in the FEC TLV. be the only FEC Element in the FEC TLV.
A P2MP FEC with the Root Node Address octets filled with zeros and
Opaque Length set to 0 is a wildcard P2MP FEC for all P2MPs FECs of
matching root node address family.
2.2. The LDP MP Opaque Value Element 2.2. The LDP MP Opaque Value Element
The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC
elements defined in subsequent sections. It carries information that elements defined in subsequent sections. It carries information that
is meaningful to leaf (and bud) LSRs, but need not be interpreted by is meaningful to leaf (and bud) LSRs, but need not be interpreted by
non-leaf LSRs. non-leaf LSRs.
The LDP MP Opaque Value Element is encoded as follows: The LDP MP Opaque Value Element is encoded as follows:
0 1 2 3 0 1 2 3
skipping to change at page 6, line 43 skipping to change at page 6, line 35
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the LDP MP Opaque Value Element is to be assigned Type: The type of the LDP MP Opaque Value Element is to be assigned
by IANA. by IANA.
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by the Value: String of Length octets, to be interpreted as specified by
Type field. the Type field.
2.2.1. The Generic LSP Identifier 2.2.1. The Generic LSP Identifier
The generic LSP identifier is a type of Opaque Value Element encoded The generic LSP identifier is a type of Opaque Value Element encoded
as follows: as follows:
Type: 1 (to be assigned by IANA) Type: 1 (to be assigned by IANA)
Length: 4 Length: 4
Value: A 32bit integer, unique in the context of the root, as Value: A 32bit integer, unique in the context of the root, as
identified by the root's address. identified by the root's address.
This type of opaque value element is recommended when mapping of This type of opaque value element is recommended when mapping of
traffic to LSPs is non-algorithmic, and done by means outside LDP. traffic to LSPs is non-algorithmic, and done by means outside LDP.
2.3. Using the P2MP FEC Element 2.3. Using the P2MP FEC Element
skipping to change at page 8, line 14 skipping to change at page 8, line 13
leaf node. leaf node.
2.3.1. Label Map 2.3.1. Label Map
The following lists procedures for generating and processing P2MP The following lists procedures for generating and processing P2MP
Label Map messages for nodes that participate in a P2MP LSP. An LSR Label Map messages for nodes that participate in a P2MP LSP. An LSR
should apply those procedures that apply to it, based on its role in should apply those procedures that apply to it, based on its role in
the P2MP LSP. the P2MP LSP.
For the approach described here we use downstream assigned labels. For the approach described here we use downstream assigned labels.
On Ethernet networks this may be less optimal, see Section 6. On Ethernet networks this may be less optimal, see Section 5.
2.3.1.1. Determining one's 'upstream LSR' 2.3.1.1. Determining one's 'upstream LSR'
A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
which lies on the best path from Z to the root node X. If there are which lies on the best path from Z to the root node X. If there are
more than one such LDP peers, only one of them is picked. U is Z's more than one such LDP peers, only one of them is picked. U is Z's
"Upstream LSR" for <X, Y>. "Upstream LSR" for <X, Y>.
When there are several candidate upstream LSRs, the LSR MAY select When there are several candidate upstream LSRs, the LSR MAY select
one upstream LSR using the following procedure: one upstream LSR using the following procedure:
skipping to change at page 8, line 46 skipping to change at page 8, line 45
single upstream LSR is selected. single upstream LSR is selected.
2.3.1.2. Leaf Operation 2.3.1.2. Leaf Operation
A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for
<X, Y> as per Section 2.3.1.1, allocates a label L, and sends a P2MP <X, Y> as per Section 2.3.1.1, allocates a label L, and sends a P2MP
Label Map <X, Y, L> to U. Label Map <X, Y, L> to U.
2.3.1.3. Transit Node operation 2.3.1.3. Transit Node operation
Suppose a transit node Z receives a P2MP Label Map <X, Y, L> over Suppose a transit node Z receives a P2MP Label Map <X, Y, L> from LDP
interface I. Z checks whether it already has state for <X, Y>. If peer T. Z checks whether it already has state for <X, Y>. If not, Z
not, Z allocates a label L', and installs state to swap L' with L allocates a label L', and installs state to swap L' with L over
over interface I. Z also determines its upstream LSR U for <X, Y> as interface I associated with peer T. Z also determines its upstream
per Section 2.3.1.1, and sends a P2MP Label Map <X, Y, L'> to U. LSR U for <X, Y> as per Section 2.3.1.1, and sends a P2MP Label Map
<X, Y, L'> to U.
If Z already has state for <X, Y>, then Z does not send a Label Map If Z already has state for <X, Y>, then Z does not send a Label Map
message for P2MP LSP <X, Y>. All that Z needs to do in this case is message for P2MP LSP <X, Y>. All that Z needs to do in this case is
update its forwarding state. Assuming its old forwarding state was update its forwarding state. Assuming its old forwarding state was
L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state
becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}.
2.3.1.4. Root Node Operation 2.3.1.4. Root Node Operation
Suppose the root node Z receives a P2MP Label Map <X, Y, L> over Suppose the root node Z receives a P2MP Label Map <X, Y, L> from peer
interface I. Z checks whether it already has forwarding state for <X, T. Z checks whether it already has forwarding state for <X, Y>. If
Y>. If not, Z creates forwarding state to push label L onto the not, Z creates forwarding state to push label L onto the traffic that
traffic that Z wants to forward over the P2MP LSP (how this traffic Z wants to forward over the P2MP LSP (how this traffic is determined
is determined is outside the scope of this document). is outside the scope of this document).
If Z already has forwarding state for <X, Y>, then Z adds "push label If Z already has forwarding state for <X, Y>, then Z adds "push label
L, send over interface I" to the nexthop. L, send over interface I" to the nexthop, where I is the interface
associated with peer T.
2.3.2. Label Withdraw 2.3.2. Label Withdraw
The following lists procedures for generating and processing P2MP The following lists procedures for generating and processing P2MP
Label Withdraw messages for nodes that participate in a P2MP LSP. An Label Withdraw messages for nodes that participate in a P2MP LSP. An
LSR should apply those procedures that apply to it, based on its role LSR should apply those procedures that apply to it, based on its role
in the P2MP LSP. in the P2MP LSP.
2.3.2.1. Leaf Operation 2.3.2.1. Leaf Operation
skipping to change at page 9, line 44 skipping to change at page 9, line 43
is the label it had previously advertised to U for <X, Y>. is the label it had previously advertised to U for <X, Y>.
2.3.2.2. Transit Node Operation 2.3.2.2. Transit Node Operation
If a transit node Z receives a Label Withdraw message <X, Y, L> from If a transit node Z receives a Label Withdraw message <X, Y, L> from
a node W, it deletes label L from its forwarding state, and sends a a node W, it deletes label L from its forwarding state, and sends a
Label Release message with label L to W. Label Release message with label L to W.
If deleting L from Z's forwarding state for P2MP LSP <X, Y> results If deleting L from Z's forwarding state for P2MP LSP <X, Y> results
in no state remaining for <X, Y>, then Z propagates the Label in no state remaining for <X, Y>, then Z propagates the Label
Withdraw <X, Y, L> to its upstream for <X, Y>. Withdraw for <X, Y>, to its upstream T, by sending a Label Withdraw
<X, Y, L1> where L1 is the label Z had previously advertised to T for
<X, Y>.
2.3.2.3. Root Node Operation 2.3.2.3. Root Node Operation
The procedure when the root node of a P2MP LSP receives a Label The procedure when the root node of a P2MP LSP receives a Label
Withdraw message are the same as for transit nodes, except that it Withdraw message are the same as for transit nodes, except that it
would not propagate the Label Withdraw upstream (as it has no would not propagate the Label Withdraw upstream (as it has no
upstream). upstream).
2.3.2.4. Upstream LSR change 2.3.2.4. Upstream LSR change
skipping to change at page 11, line 46 skipping to change at page 11, line 46
4.1. The MP2MP downstream and upstream FEC elements. 4.1. The MP2MP downstream and upstream FEC elements.
The structure, encoding and error handling for the MP2MP downstream The structure, encoding and error handling for the MP2MP downstream
and upstream FEC elements are the same as for the P2MP FEC element and upstream FEC elements are the same as for the P2MP FEC element
described in Section 2.1. The difference is that two new FEC types described in Section 2.1. The difference is that two new FEC types
are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD).
If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element
MUST be the only FEC Element in the FEC TLV. MUST be the only FEC Element in the FEC TLV.
A MP2MP Downstream FEC with the Root Node Address octets filled with
zeros and Opaque Length set to 0 is a wildcard MP2MP Downstream FEC
for all MP2MP Downstream FECs of matching root node address family.
Similarly, a MP2MP Upstream FEC with the Root Node Address octets
filled with zeros and Opaque Length set to 0 is a wildcard MP2MP
Upstream FEC for all MP2MP Upstream FECs of matching root node
address family.
4.2. Using the MP2MP FEC elements 4.2. Using the MP2MP FEC elements
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the MP2MP FEC elements. The following notation is used in the the MP2MP FEC elements. The following notation is used in the
processing rules: processing rules:
1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an 1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an
MP2MP LSP downstream path with root node address X and opaque MP2MP LSP downstream path with root node address X and opaque
value Y. value Y.
skipping to change at page 13, line 48 skipping to change at page 13, line 42
Leaf node Z expects an MP2MP Label Map upstream <X, Y, Lu> from node Leaf node Z expects an MP2MP Label Map upstream <X, Y, Lu> from node
U in response to the MP2MP Label Map downstream it sent to node U. Z U in response to the MP2MP Label Map downstream it sent to node U. Z
checks whether it already has forwarding state for upstream <X, Y>. checks whether it already has forwarding state for upstream <X, Y>.
If not, Z creates forwarding state to push label Lu onto the traffic If not, Z creates forwarding state to push label Lu onto the traffic
that Z wants to forward over the MP2MP LSP. How it determines what that Z wants to forward over the MP2MP LSP. How it determines what
traffic to forward on this MP2MP LSP is outside the scope of this traffic to forward on this MP2MP LSP is outside the scope of this
document. document.
4.2.1.4. MP2MP transit node operation 4.2.1.4. MP2MP transit node operation
When node Z receives a MP2MP Label Map downstream <X, Y, L> over When node Z receives a MP2MP Label Map downstream <X, Y, L> from peer
interface I from node D it checks whether it has forwarding state for D associated with interface I, it checks whether it has forwarding
downstream <X, Y>. If not, Z allocates a label L' and installs state for downstream <X, Y>. If not, Z allocates a label L' and
downstream forwarding state to swap label L' with label L over installs downstream forwarding state to swap label L' with label L
interface I. Z also determines its upstream LSR U for <X, Y> as per over interface I. Z also determines its upstream LSR U for <X, Y> as
Section 4.2.1.1, and sends a MP2MP Label Map downstream <X, Y, L'> to per Section 4.2.1.1, and sends a MP2MP Label Map downstream <X, Y,
U. L'> to U.
If Z already has forwarding state for downstream <X, Y>, all that Z If Z already has forwarding state for downstream <X, Y>, all that Z
needs to do is update its forwarding state. Assuming its old needs to do is update its forwarding state. Assuming its old
forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new
forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I,
L>}. L>}.
Node Z checks whether it already has forwarding state upstream <X, Y, Node Z checks whether it already has forwarding state upstream <X, Y,
D>. If it does, then no further action needs to happen. If it does D>. If it does, then no further action needs to happen. If it does
not, it allocates a label Lu and creates a new label swap for Lu from not, it allocates a label Lu and creates a new label swap for Lu from
the label swap(s) from the forwarding state downstream <X, Y>, the label swap(s) from the forwarding state downstream <X, Y>,
omitting the swap on interface I for node D. This allows upstream omitting the swap on interface I for node D. This allows upstream
traffic to follow the MP2MP tree down to other node(s) except the traffic to follow the MP2MP tree down to other node(s) except the
node from which Z received the MP2MP Label Map downstream <X, Y, L>. node from which Z received the MP2MP Label Map downstream <X, Y, L>.
Node Z determines the downstream MP2MP LSR as per Section 4.2.1.2, Node Z determines the downstream MP2MP LSR as per Section 4.2.1.2,
and sends a MP2MP Label Map upstream <X, Y, Lu> to node D. and sends a MP2MP Label Map upstream <X, Y, Lu> to node D.
Transit node Z will also receive a MP2MP Label Map upstream <X, Y, Transit node Z will also receive a MP2MP Label Map upstream <X, Y,
Lu> in response to the MP2MP Label Map downstream sent to node U over Lu> in response to the MP2MP Label Map downstream sent to node U
interface Iu. Node Z will add label swap Lu over interface Iu to the associated with interface Iu. Node Z will add label swap Lu over
forwarding state upstream <X, Y, D>. This allows packets to go up interface Iu to the forwarding state upstream <X, Y, D>. This allows
the tree towards the root node. packets to go up the tree towards the root node.
4.2.1.5. MP2MP root node operation 4.2.1.5. MP2MP root node operation
4.2.1.5.1. Root node is also a leaf 4.2.1.5.1. Root node is also a leaf
Suppose root/leaf node Z receives a MP2MP Label Map downstream <X, Y, Suppose root/leaf node Z receives a MP2MP Label Map downstream <X, Y,
L> over over interface I from node D. Z checks whether it already has L> from node D associated with interface I. Z checks whether it
forwarding state downstream <X, Y>. If not, Z creates forwarding already has forwarding state downstream <X, Y>. If not, Z creates
state for downstream to push label L on traffic that Z wants to forwarding state for downstream to push label L on traffic that Z
forward down the MP2MP LSP. How it determines what traffic to wants to forward down the MP2MP LSP. How it determines what traffic
forward on this MP2MP LSP is outside the scope of this document. If to forward on this MP2MP LSP is outside the scope of this document.
Z already has forwarding state for downstream <X, Y>, then Z will add If Z already has forwarding state for downstream <X, Y>, then Z will
the label push for L over interface I to it. add the label push for L over interface I to it.
Node Z checks if it has forwarding state for upstream <X, Y, D>. If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu and creates upstream forwarding state to not, Z allocates a label Lu and creates upstream forwarding state to
push Lu with the label push(s) from the forwarding state downstream push Lu with the label push(s) from the forwarding state downstream
<X, Y>, except the push on interface I for node D. This allows <X, Y>, except the push on interface I for node D. This allows
upstream traffic to go down the MP2MP to other node(s), except the upstream traffic to go down the MP2MP to other node(s), except the
node from which the traffic was received. Node Z determines the node from which the traffic was received. Node Z determines the
downstream MP2MP LSR as per section Section 4.2.1.2, and sends a downstream MP2MP LSR as per section Section 4.2.1.2, and sends a
MP2MP Label Map upstream <X, Y, Lu> to node D. Since Z is the root of MP2MP Label Map upstream <X, Y, Lu> to node D. Since Z is the root of
the tree Z will not send a MP2MP downstream map and will not receive the tree Z will not send a MP2MP downstream map and will not receive
a MP2MP upstream map. a MP2MP upstream map.
4.2.1.5.2. Root node is not a leaf 4.2.1.5.2. Root node is not a leaf
Suppose the root node Z receives a MP2MP Label Map dowbstream <X, Y, Suppose the root node Z receives a MP2MP Label Map dowbstream <X, Y,
L> over over interface I from node D. Z checks whether it already has L> from node D associated with interface I. Z checks whether it
forwarding state for downstream <X, Y>. If not, Z creates downstream already has forwarding state for downstream <X, Y>. If not, Z
forwarding state and installs a outgoing label L over interface I. If creates downstream forwarding state and installs a outgoing label L
Z already has forwarding state for downstream <X, Y>, then Z will add over interface I. If Z already has forwarding state for downstream
label L over interface I to the existing state. <X, Y>, then Z will add label L over interface I to the existing
state.
Node Z checks if it has forwarding state for upstream <X, Y, D>. If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu and creates forwarding state to swap Lu not, Z allocates a label Lu and creates forwarding state to swap Lu
with the label swap(s) from the forwarding state downstream <X, Y>, with the label swap(s) from the forwarding state downstream <X, Y>,
except the swap for node D. This allows upstream traffic to go down except the swap for node D. This allows upstream traffic to go down
the MP2MP to other node(s), except the node is was received from. the MP2MP to other node(s), except the node is was received from.
Root node Z determines the downstream MP2MP LSR D as per Root node Z determines the downstream MP2MP LSR D as per
Section 4.2.1.2, and sends a MP2MP Label Map upstream <X, Y, Lu> to Section 4.2.1.2, and sends a MP2MP Label Map upstream <X, Y, Lu> to
it. Since Z is the root of the tree Z will not send a MP2MP it. Since Z is the root of the tree Z will not send a MP2MP
downstream map and will not receive a MP2MP upstream map. downstream map and will not receive a MP2MP upstream map.
skipping to change at page 16, line 25 skipping to change at page 16, line 19
withdraw message is the same as for transit nodes, except that the withdraw message is the same as for transit nodes, except that the
root node would not propagate the Label Withdraw upstream (as it has root node would not propagate the Label Withdraw upstream (as it has
no upstream). no upstream).
4.2.2.4. MP2MP Upstream LSR change 4.2.2.4. MP2MP Upstream LSR change
The procedure for changing the upstream LSR is the same as documented The procedure for changing the upstream LSR is the same as documented
in Section 2.3.2.4, except it is applied to MP2MP FECs, using the in Section 2.3.2.4, except it is applied to MP2MP FECs, using the
procedures described in Section 4.2.1 through Section 4.2.2.3. procedures described in Section 4.2.1 through Section 4.2.2.3.
5. mLDP wildcard FECs 5. Upstream label allocation on Ethernet networks
P2MP, MP2MP Downstream and MP2MP Upstream FECs are examples of mLDP
Wildcard FECs. P2MP, and MP2MP Downstream Wildcard FECs may appear
only in Label Request, Label Withdraw and Label Release messages.
MP2MP Upstream Wildcard FECs may appear only in Label Withdraw and
Label Release messages. A label TLV object MUST not be present in
messages containing an mLDP wildcard FEC.
5.1. Label Request Message
Use of a Label Request Message is defined only for Wildcard versions
of the P2MP, and MP2MP Downstream FEC. An LSR sends a Label Request
Message containing an mLDP Wildcard FEC to requests the
readvertisement of all FECs of the specified address family. The
procedures defined above for various mLDP FEC types are to be
reapplied individually to any received Label Mapping advertisements.
5.2. Label Withdraw Message
An LSR sends a Label Withdraw Message containing an mLDP Wildcard FEC
when it wants to withdraw all the P2MP, MP2MP Upstream or MP2MP
Downstream FECs previously advertised. The same procedures defined
for the non Wildcard case apply except that instead of sending
individual label release messages only a single mLDP wildcard Label
Release message is sent to acknowledge completion of a mLDP wildcard
withdraw.
5.3. Label Release Message
An LSR sends an mLDP wildcard Label Release Message to acknowledge
the completion of processing for a mLDP wildcard withdraw. An LSR
may also send an unsolicited wildcard Label release to indicate to
that LDP neighbor that all previously send label mappings are to be
released. An LSR receiving an Label Release Message for a Wildcard
FEC MUST release all labels it assigned to this LSR for the given FEC
type and removes them from forwarding use.
6. Upstream label allocation on Ethernet networks
On Ethernet networks the upstream LSR will send a copy of the packet On Ethernet networks the upstream LSR will send a copy of the packet
to each receiver individually. If there is more then one receiver on to each receiver individually. If there is more then one receiver on
the Ethernet we don't take full benefit of the multi-access the Ethernet we don't take full benefit of the multi-access
capability of the network. We may optimize the bandwidth consumption capability of the network. We may optimize the bandwidth consumption
on the Ethernet and replication overhead on the upstream LSR by using on the Ethernet and replication overhead on the upstream LSR by using
upstream label allocation [5]. Procedures on how to distribute upstream label allocation [5]. Procedures on how to distribute
upstream labels using LDP is documented in [6]. upstream labels using LDP is documented in [6].
7. Root node redundancy for MP2MP LSPs 6. Root node redundancy for MP2MP LSPs
MP2MP leaf nodes must use the same root node to setup the MP2MP LSP. MP2MP leaf nodes must use the same root node to setup the MP2MP LSP.
Otherwise there will be partitioned MP2MP LSP and traffic sourced by Otherwise there will be partitioned MP2MP LSP and traffic sourced by
some leafs is not received by others. Having a single root node for some leafs is not received by others. Having a single root node for
a MP2MP LSP is a single point of failure, which is not preferred. We a MP2MP LSP is a single point of failure, which is not preferred. We
need a fast and efficient mechanism to recover from a root node need a fast and efficient mechanism to recover from a root node
failure. failure.
7.1. Root node redundancy procedure 6.1. Root node redundancy procedure
It is likely that the root node for a MP2MP LSP is defined It is likely that the root node for a MP2MP LSP is defined
statically. The root node address may be configured on each leaf statically. The root node address may be configured on each leaf
statically or learned using a dynamic protocol. How MP2MP leafs statically or learned using a dynamic protocol. How MP2MP leafs
learn about the root node is out of the scope of this document. A learn about the root node is out of the scope of this document. A
MP2MP LSP is uniquely identified by a opaque value and the root node MP2MP LSP is uniquely identified by a opaque value and the root node
address. Suppose that for the same opaque value we define two root address. Suppose that for the same opaque value we define two root
node addresses and we build a tree to each root using the same opaque node addresses and we build a tree to each root using the same opaque
value. Effectively these will be treated as different MP2MP LSPs in value. Effectively these will be treated as different MP2MP LSPs in
the network. Since all leafs have setup a MP2MP LSP to each one of the network. Since all leafs have setup a MP2MP LSP to each one of
skipping to change at page 18, line 22 skipping to change at page 17, line 25
unicast routing table and select a root that is closest according in unicast routing table and select a root that is closest according in
terms of unicast metric. As soon as the root address of our active terms of unicast metric. As soon as the root address of our active
root disappears from the unicast routing table (or becomes less root disappears from the unicast routing table (or becomes less
attractive) due to root node or link failure we can select a new best attractive) due to root node or link failure we can select a new best
root address and start forwarding to it directly. If multiple root root address and start forwarding to it directly. If multiple root
nodes have the same unicast metric, the highest root node addresses nodes have the same unicast metric, the highest root node addresses
MAY be selected, or we MAY do per session load balancing over the MAY be selected, or we MAY do per session load balancing over the
root nodes. root nodes.
All leafs participating in a MP2MP LSP MUST join to all the available All leafs participating in a MP2MP LSP MUST join to all the available
root nodes for a give opaque value. Since the sending leaf may pick root nodes for a given opaque value. Since the sending leaf may pick
any MP2MP LSP, it must be prepared to receive on it. any MP2MP LSP, it must be prepared to receive on it.
The advantage of pre-building multiple MP2MP LSPs for a single opaque The advantage of pre-building multiple MP2MP LSPs for a single opaque
value is that we can converge from a root node failure as fast as the value is that we can converge from a root node failure as fast as the
unicast routing protocol is able to notify us. There is no need for unicast routing protocol is able to notify us. There is no need for
an additional protocol to advertise to the leaf nodes which root node an additional protocol to advertise to the leaf nodes which root node
is the active root. The root selection is a local leaf policy that is the active root. The root selection is a local leaf policy that
does not need to be coordinated with other leafs. The disadvantage does not need to be coordinated with other leafs. The disadvantage
is that we are using more label resources depending on how many root is that we are using more label resources depending on how many root
nodes are defined. nodes are defined.
8. Make before break 7. Make before break
An upstream LSR is chosen based on the best path to reach the root of An upstream LSR is chosen based on the best path to reach the root of
the MP LSP. When the best path to reach the root changes it needs to the MP LSP. When the best path to reach the root changes it needs to
choose a new upstream LSR. Section 2.3.2.4 and Section 4.2.2.4 choose a new upstream LSR. Section 2.3.2.4 and Section 4.2.2.4
describes these procedures. When the best path to the root changes describes these procedures. When the best path to the root changes
the LSP may be broken and packet forwarding is interrupted, in that the LSP may be broken and packet forwarding is interrupted, in that
case it needs to converge to a new upstream LSR ASAP. There are also case it needs to converge to a new upstream LSR ASAP. There are also
scenarios where the best path changed, but the LSP is still scenarios where the best path changed, but the LSP is still
forwarding packets. That happens when links come up or routing forwarding packets. That happens when links come up or routing
metrics are changed. In that case it would like to build the new LSP metrics are changed. In that case it would like to build the new LSP
before it breaks the old LSP to minimize the traffic interruption. before it breaks the old LSP to minimize the traffic interruption.
The approuch described below deals with both scenarios and does not The approuch described below deals with both scenarios and does not
require LDP to know which of the events above caused the upstream require LDP to know which of the events above caused the upstream
router to change. The approuch below is an optional extention to the router to change. The approuch below is an optional extention to the
MP LSP building procedures described in this draft. MP LSP building procedures described in this draft.
8.1. Protocol event 7.1. Protocol event
An approach is to use additional signaling in LDP. Suppose a An approach is to use additional signaling in LDP. Suppose a
downstream LSR-D is changing to a new upstream LSR-U for FEC-A, this downstream LSR-D is changing to a new upstream LSR-U for FEC-A, this
LSR-U may already be forwarding packets for this FEC-A. Based on the LSR-U may already be forwarding packets for this FEC-A. Based on the
existence of state for FEC-A, LSR-U will send a notification to the existence of state for FEC-A, LSR-U will send a notification to the
LSR-D to initiate the switchover. The assumption is that if our LSR-D to initiate the switchover. The assumption is that if our
upstream LSR-U has state for the FEC-A and it has received a upstream LSR-U has state for the FEC-A and it has received a
notification from its upstream router, then this LSR is forwarding notification from its upstream router, then this LSR is forwarding
packets for this FEC-A and it can send a notification back to packets for this FEC-A and it can send a notification back to
initiate the switchover. You could say there is an explicit initiate the switchover. You could say there is an explicit
skipping to change at page 19, line 35 skipping to change at page 18, line 37
Suppose LSR-D sends a label mapping for FEC-A to LSR-U. LSR-U must Suppose LSR-D sends a label mapping for FEC-A to LSR-U. LSR-U must
only reply with a notification to LSR-D if it is in state #3 as only reply with a notification to LSR-D if it is in state #3 as
described above. If LSR-U is in state 1 or 2, it should remember it described above. If LSR-U is in state 1 or 2, it should remember it
has received a label mapping from LSR-D which is waiting for a has received a label mapping from LSR-D which is waiting for a
notification. As soon as LSR-U received a notification from its notification. As soon as LSR-U received a notification from its
upstream LSR it can move to state #3 and trigger notifications to its upstream LSR it can move to state #3 and trigger notifications to its
downstream LSR's that requested it. More details will be added in downstream LSR's that requested it. More details will be added in
the next revision of the draft. the next revision of the draft.
9. Security Considerations 8. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, as described in [1]. specification, as described in [1].
10. IANA considerations 9. IANA considerations
This document creates a new name space (the LDP MP Opaque Value This document creates a new name space (the LDP MP Opaque Value
Element type) that is to be managed by IANA. Also, this document Element type) that is to be managed by IANA. Also, this document
requires allocation of three new LDP FEC element types: the P2MP requires allocation of three new LDP FEC element types: the P2MP
type, the MP2MP-up and the MP2MP-down types. type, the MP2MP-up and the MP2MP-down types.
11. Acknowledgments 10. Acknowledgments
The authors would like to thank the following individuals for their The authors would like to thank the following individuals for their
review and contribution: Nischal Sheth, Yakov Rekhter, Rahul review and contribution: Nischal Sheth, Yakov Rekhter, Rahul
Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and
George Swallow. George Swallow.
12. Contributing authors 11. Contributing authors
Below is a list of the contributing authors in alphabetical order: Below is a list of the contributing authors in alphabetical order:
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
US US
Email: Shane.Amante@Level3.com Email: Shane.Amante@Level3.com
skipping to change at page 21, line 38 skipping to change at page 20, line 45
Norway Norway
Email: lei.wang@telenor.com Email: lei.wang@telenor.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ice@cisco.com E-mail: ice@cisco.com
13. References 12. References
13.1. Normative References 12.1. Normative References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001. Thomas, "LDP Specification", RFC 3036, January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[4] Roux, J., "Requirements for point-to-multipoint extensions to [4] Roux, J., "Requirements for point-to-multipoint extensions to
the Label Distribution Protocol", the Label Distribution Protocol",
draft-leroux-mpls-mp-ldp-reqs-01 (work in progress), July 2005. draft-leroux-mpls-mp-ldp-reqs-03 (work in progress),
February 2006.
[5] Aggarwal, R., "MPLS Upstream Label Assignment and Context [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context
Specific Label Space", draft-raggarwa-mpls-upstream-label-01 Specific Label Space", draft-raggarwa-mpls-upstream-label-01
(work in progress), October 2005. (work in progress), October 2005.
[6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for
RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work
in progress), July 2005. in progress), July 2005.
13.2. Informative References 12.2. Informative References
[7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05
(work in progress), June 2004. (work in progress), June 2004.
[8] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE [8] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp-02 (work in progress), LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress),
July 2005. August 2006.
[9] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", [9] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
draft-ietf-l3vpn-2547bis-mcast-00 (work in progress), June 2005. draft-ietf-l3vpn-2547bis-mcast-02 (work in progress), June 2006.
Authors' Addresses Authors' Addresses
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: ina@juniper.net Email: ina@juniper.net
skipping to change at page 24, line 5 skipping to change at page 23, line 5
Email: ice@cisco.com Email: ice@cisco.com
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough 01719 Boxborough 01719
US US
Email: rhthomas@cisco.com Email: rhthomas@cisco.com
Intellectual Property Statement Full Copyright Statement
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 an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 29 skipping to change at page 23, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. 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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 39 change blocks. 
152 lines changed or deleted 99 lines changed or added

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