draft-ietf-bess-bgp-vpls-control-flags-06.txt   draft-ietf-bess-bgp-vpls-control-flags-07.txt 
BESS Working Group R. Singh BESS Working Group R. Singh
INTERNET-DRAFT K. Kompella INTERNET-DRAFT K. Kompella
Intended Status: Proposed Standard Juniper Networks Intended Status: Proposed Standard Juniper Networks
Updates: 4761 (if approved) S. Palislamovic Updates: 4761 (if approved) S. Palislamovic
Alcatel-Lucent Nokia
Expires: February 18, 2019 August 17, 2018 Expires: September 6, 2019 March 5, 2019
Updated processing of control flags for BGP VPLS Updated processing of Control Flags for BGP VPLS
draft-ietf-bess-bgp-vpls-control-flags-06 draft-ietf-bess-bgp-vpls-control-flags-07
Abstract Abstract
This document updates the meaning of the "control flags" fields This document updates the meaning of the Control Flags field in the
inside the "layer2 info extended community" used for BGP-VPLS NLRI as Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in
defined in RFC4761. If approved, this document updates RFC4761. RFC4761. This document updates RFC4761.
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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Updated meaning of control flags in the layer2 info extended 3 Updated meaning of Control Flags in the Layer2 Info Extended
community . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 4 3.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 4
3.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 4 3.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 4
4 Using p2mp LSP as transport for BGP VPLS . . . . . . . . . . . 5 4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 Treatment of C and S bits in multi-homing scenarios . . . . . . 5 5 Treatment of C and S bits in multi-homing scenarios . . . . . . 5
5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5 5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5
5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6 5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6
6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7
9.2 Informative References . . . . . . . . . . . . . . . . . . . 7 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction 1 Introduction
"Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling" ([RFC4761]) describes the concepts and signaling for using Signaling" ([RFC4761]) describes the concepts and signaling for using
BGP (Border Gateway Protocol) to setup a VPLS (virtual private LAN Border Gateway Protocol (BGP) to setup a VPLS. It specifies the BGP
service). It specifies the BGP VPLS NLRI (network layer reachability VPLS Network Layer Reachability Information (NLRI) by which a PE may
information) by which a PE may require other PEs in the same VPLS to require other PEs in the same VPLS to include (or not) the control-
include (or not) control-word and sequencing information in VPLS word and sequencing information in VPLS frames sent to this PE.
frames sent to this PE.
The use of control word (CW) helps prevent mis-ordering of IPv4 or The use of the Control Word (CW) helps prevent mis-ordering of IPv4
IPv6 PW traffic over ECMP (equal cost multi-path) paths or LAG (link or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP)
aggregation group) bundles. [RFC4385] describes the format for paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes
control-word that may be used over point-2-point PWs (pseudowires) the format for CW that may be used over Point-to-Point PWs and over a
and over a VPLS. It along with [RFC3985] also describes sequencing of VPLS. Along with [RFC3985], the document also describes sequence
frames. number usage for VPLS frames.
However, [RFC4761] does not specify the behavior of PEs in a mixed However, [RFC4761] does not specify the behavior of PEs in a mixed
environment where some PEs support control-word/sequencing and others environment where some PEs support Control Word/sequencing and others
do not. do not.
1.1 Terminology 1.1 Terminology
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2 Problem 2 Problem
[RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises
the behavior expected from the multiple PEs participating in the same the behavior expected by the multiple PEs participating in the same
VPLS. The NLRI indicates the VPLS label that the various PE routers, VPLS. The NLRI indicates the VPLS label that the various PE routers,
which are referred to in the NLRI, should use when forwarding VPLS which are referred to in the NLRI, should use when forwarding VPLS
traffic to this PE. Additionally, by using the "control flags" this traffic to this PE. Additionally, by using the Control Flags this PE
PE specifies whether the other PEs (in the same VPLS) should use specifies whether the other PEs (in the same VPLS) should use Control
control-word or sequenced-delivery for frames forwarded to this PE. Word or sequenced-delivery for frames forwarded to this PE. These are
These are respectively indicated by the C and the S bits in the respectively indicated by the C and the S bits in the Control Flags
"control flags" as specified in section 3.2.4 in [RFC4761]. as specified in section 3.2.4 in [RFC4761].
[RFC4761] requires that if the advertising PE sets the C and S bits, [RFC4761] requires that if the advertising PE sets the C and S bits,
when forwarding VPLS traffic to the PE, the receiving PE MUST insert the receiving PE MUST, respectively, insert control word (CW) and
control word (CW) and by including sequence numbers respectively. include sequence numbers when forwarding VPLS traffic to the
advertising PE.
However, in a BGP VPLS deployment there would often be cases where a However, in a BGP VPLS deployment there would often be cases where a
PE receiving the VPLS BGP NLRI may not have the ability to insert a PE receiving the VPLS BGP NLRI may not have the ability to insert a
CW or include sequencing information inside PW frames. Thus, the CW or include sequencing information inside PW frames. Thus, the
behavior of processing CW and sequencing needs to be further behavior of processing CW and sequencing needs to be further
specified. specified.
This document updates the meaning of the control flags in layer2 This document updates the meaning of the Control Flags in layer2
extended community in the BGP VPLS NLRI. It also specifies the extended community in the BGP VPLS NLRI. It also specifies the
forwarding behavior for a mixed-mode environment where not every PE forwarding behavior for a mixed-mode environment where not every PE
in a VPLS has the ability or the configuration to honor the control in a VPLS has the ability or the configuration to honor the control
flags received from the PE advertising the BGP NLRI. flags received from the PE advertising the BGP NLRI.
3 Updated meaning of control flags in the layer2 info extended 3 Updated meaning of Control Flags in the Layer2 Info Extended
community Community
Current specification does not allow for the CW setting to be The current specification does not allow for the CW setting to be
negotiated. Rather, if a PE sets the C-bit, it expects to receive negotiated. In a typical implementation, if a PE sets the C-bit, it
VPLS frames with a control word, and will send frames the same way. expects to receive VPLS frames with a control word, and will send
If the PEs at both ends of a pseudowire do not agree on the setting frames the same way. If the PEs at the two ends of a pseudowire do
of the C-bit, the PW does not come up. The expected behavior is not agree on the setting of the C-bit, the PW does not come up. The
similar for the S-bit. behavior is similar for the S-bit.
This memo updates the meaning of the C-bit and the S-bit in the This memo updates the meaning of the C-bit and the S-bit in the
control flags. control flags.
3.1 Control word (C-bit) 3.1 Control word (C-bit)
If a PE sets the C-bit in its NLRI, it means that the PE has ability If a PE sets the C-bit in its NLRI, it means that the PE has ability
to send and receive frames with a control word. If the PEs at both to send and receive frames with a control word. If the PEs at both
ends of a PW set the C-bit, control words MUST be used in both ends of a PW set the C-bit, control words MUST be used in both
directions of the PW. If both PEs send a C-bit of 0, control words directions of the PW. If both PEs send a C-bit of 0, Control Words
MUST NOT be used on the PW. These two cases behave as before. MUST NOT be used on the PW. These two cases behave as before.
However, if the PEs don't agree on the setting of the C-bit, control However, if the PEs don't agree on the setting of the C-bit, control
words MUST NOT be used on that PW but the PW MUST NOT be prevented words MUST NOT be used in either direction on that PW but the PW MUST
from coming up due to this mismatch. So, the PW MUST still come up. NOT be prevented from coming up due to this mismatch. So, the PW MUST
This behavior is new; the old behavior was that the PW doesn't come still come up but not use control word in either direction. This
up. behavior is changed from the behavior described in [RFC4761] where
the PW does not come up.
3.2 Sequence flag (S-bit) 3.2 Sequence flag (S-bit)
Current BGP VPLS specification do not allow for S-bit setting to be Current BGP VPLS specification do not allow for S-bit setting to be
negotiated either. If the PE sets the S-bit, it expects to receive negotiated either. In typical implementations, if the PE sets the S-
VPLS frames with sequence numbers, and will send the frames with bit, it expects to receive VPLS frames with seqence numbers, and will
sequence numbers as well. This memo further specifies the existing send outgoing frames with sequence numbers as well. This memo
behavior. If the PEs on the both ends of the PW set the S-bit, then further specifies the expected behavior. If the PEs on the both ends
both PEs MUST include the PW sequence numbers. If the PEs at both of the PW set the S-bit, then both PEs MUST include the PW sequence
ends of the PW do not agree on the setting of the S-bit, the PW numbers. If the PEs at both ends of the PW do not agree on the
SHOULD NOT come up at all. setting of the S-bit, the PW SHOULD NOT come up.
4 Using p2mp LSP as transport for BGP VPLS 4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP VPLS
BGP VPLS can be used over point-2-point LSPs acting as transport BGP VPLS can be used over point-2-point LSPs acting as transport
between the VPLS PEs. Alternately, BGP VPLS may also be used over between the VPLS PEs. Alternately, BGP VPLS may also be used over
p2mp (point to multipoint) LSPs (label switched path) with the source P2MP Label Switched Path (LSPs) with the source of the P2MP LSP
of the p2mp LSP rooted at the PE advertising the VPLS BGP NLRI. rooted at the PE advertising the VPLS BGP NLRI.
In a network that uses p2mp LSPs as transport for BGP VPLS, in a In a network that uses P2MP LSPs as transport for a VPLS,there may be
given VPLS there may be some PEs that support control-word while some PEs that support CW while others may not. Similarly, for the
others do not. Similarly, for sequencing of frames. sequencing of VPLS frames.
In such a setup, a source PE that supports control-word should setup In such a setup, a source PE that supports CW should setup two
2 different p2mp LSPs such that: different P2MP LSPs such that:
- one p2mp LSP will carry CW-marked frames to those PEs that - One P2MP LSP will transport CW-marked frames to those PEs
advertised C-bit as 1, and that advertised the C-bit as 1.
- the other p2mp LSP will carry frames without CW to those PEs - The other P2MP LSP will transport frames without CW to those
that advertised C-bit as 0. PEs that advertised C-bit as 0.
Using 2 different p2mp LSPs to deliver frames with and without CW Using two different P2MP LSPs to deliver frames with and without
to different PEs ensures that this PE honors the C-bit advertised the CW to different PEs ensures that a P2MP root PE honors the C-
by the other PEs. bit advertised by the other P2MP PEs.
However, the set of leaves on the 2 p2mp LSPs (rooted at the given However, the set of leaves on the two P2MP LSPs (rooted at the
PE) MUST NOT contain any PEs that advertised a value for S-bit given PE) MUST NOT contain any PEs that advertised a value for the
different from what this PE itself is advertising. PEs that S-bit different from what the root PE itself is advertising. PEs
advertised their S-bit value differently (from what this PE that advertised their S-bit value differently (from what the P2MP
advertised) will not be on either of the p2mp LSPs. It is ensured root PE advertised) will not be on either of the P2MP LSPs. This
that this PE is sending VPLS frames only to those PEs that agree ensures that the P2MP root PE is sending VPLS frames only to those
with this PE on the setting of S-bit. PEs that agree on the setting of S-bit.
The ingress router for the P2MP LSP should send separate NLRIs for
the cases of using control-word and for not using control-word.
5 Treatment of C and S bits in multi-homing scenarios 5 Treatment of C and S bits in multi-homing scenarios
5.1 Control word (C-bit) 5.1 Control word (C-bit)
In multi-homed environment, different PEs may effectively represent In multi-homed environment, different PEs may effectively represent
the same service destination end point. It could be assumed that the same service destination end-point. It could be assumed that
the end-to-end PW establishment process should follow the same the end-to-end PW establishment process should follow the same
rules when it comes to control word requirement, meaning setting rules when it comes to control word requirement, meaning setting
the C-bit would be enforced equally toward both primary and backup the C-bit would be enforced equally toward both primary and backup
designated forwarder together. designated forwarders.
However, in the multi-homing case each PW SHOULD be evaluated However, in the multi-homing case each PW SHOULD be evaluated
independently. Assuming the below specified network topology, there independently. Assuming the below specified network topology, there
could be the case where PW between PE2 and PE1 could have control could be the case where PW between PE2 and PE1 could have CW
word signaled via extended community and would be used in the VPLS signaled via extended community and would be used in the VPLS
frame, while PE2 to PE4 PW would not insert the control word in the frame, while PE2 to PE4 PW would not insert the CW in the VPLS
VPLS frame due to C-bit mismatch. The rest of PEs multi-homing frame due to C-bit mismatch. The rest of PEs multi-homing behavior
behavior should simply follow the rules specified in draft-ietf- should simply follow the rules specified in [VPLS-MULTIHOMING].
bess-vpls-multihoming-00.
5.2 Sequence flag (S-bit) 5.2 Sequence flag (S-bit)
In multi-homed environment, different PEs may effectively represent In multi-homed environment, different PEs may effectively represent
the same service destination end point. In this case, the rules for the same service destination end-point. In this case, the rules for
end-to-end PW establishment SHOULD follow the same rules when it end-to-end PW establishment SHOULD follow the same behavior as
comes to sequence bit requirements. Consider the case below with listed in section 3.2 when it comes to sequence bit requirements.
CE5 being multi-homed to PE4 and PE1. The PW behavior is similar Consider the case below with CE5 being multi-homed to PE4 and PE1.
to the C-word scenario so that the insertion of S-bit evaluation The PW behavior is similar to the CW scenario so that the insertion
SHOULD be independent per PW. However, because S-bit mismatch of S-bit evaluation SHOULD be independent per PW. However, because
between two end-point PEs yields in no PW establishment, in the S-bit mismatch between two end-point PEs results in no PW
case where PE4 doesn't support S-bit, only one PW would be establishment, in the case where PE4 doesn't support S-bit, only
established, between PE1 and PE2. Thus, even though CE5 is one PW would be established, between PE1 and PE2. Thus, even
physically multi-homed, due to PE4's lack of support for S-bit, and though CE5 is physically multi-homed, due to PE4's lack of support
no PW between PE1 and PE4, CE5 would not be multi-homed any more. for S-bit, and no PW between PE1 and PE4, CE5 would not be multi-
homed.
6 Illustrative diagram 6 Illustrative diagram
----- -----
/ A1 \ / A1 \
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ ----- \ / \ / \___/ | \ -----
---- ---PE2 | \ ---- ---PE2 | \
skipping to change at page 6, line 47 skipping to change at page 7, line 4
---- / | ---- ---- / | ----
/ \/ \ / \ CE = Customer Edge Device / \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router | A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / \ / \ /
---- ---- A<n> = Customer site n ---- ---- A<n> = Customer site n
Figure 1: Example of a VPLS Figure 1: Example of a VPLS
In the above topology, let there be a VPLS configured with the PEs as In the above topology, let there be a VPLS configured with the PEs as
displayed. Let PE1 be the PE under consideration that is CW enabled. displayed. Let PE1 be the PE under consideration that is CW enabled.
Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1 Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1
will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1. will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1.
PE2 and PE3 on learning of NLRI from PE1, shall include the control PE2 and PE3 on learning of NLRI from PE1, will include the CW in VPLS
word in VPLS frames being forwarded to PE1. However, PE4 which does frames being forwarded to PE1. However, PE4 which does not have the
not have the ability to include control-word. ability to include CW, will not.
As per [RFC4761], PE1 would have an expectation that all other PEs As per [RFC4761], PE1 would have an expectation that all other PEs
forward traffic to it by including CW. That expectation cannot be met forward traffic to it by including CW. That expectation cannot be met
by PE4 in this example. Thus, as per [RFC4761] the PW between PE1 and by PE4 in this example. Thus, as per [RFC4761], the PW between PE1
PE4 does not come up. and PE4 does not come up.
However, this document addresses how to support the mixed-CW However, this document addresses how to support the mixed-CW
environment as above. PE1 will bring up the PW with PE4 despite the environment as above. PE1 will bring up the PW with PE4 despite the
CW mismatch. Additionally, it will setup its data-plane such that it CW mismatch. Additionally, it will setup its data-plane such that it
will strip the control-word only for those VPLS frames that are will strip the CW only for those VPLS frames that are received from
received from PEs that are themselves indicating their desire to PEs that have indicated their desire to receive CW marked frames. So,
receive CW marked frames. So, PE1 will setup its data plane to strip- PE1 will setup its data plane to strip the CW only for VPLs frames
off the CW only for VPLs frames received from PEs PE2 and PE3. PE1 received from PE2 and PE3. PE1 will setup its data-plane to not strip
will setup its data plane to not strip CW from frames received from the CW from frames received from PE4.
PE4.
7 Security Considerations 7 Security Considerations
This document updates the behavior specified in [RFC4761]. The This document updates the behavior specified in [RFC4761]. The
security considerations listed in [RFC4761] apply. However, there are security considerations listed in [RFC4761] apply. However, there are
no new security considerations due to the text of this document. no new security considerations due to the behavior changes in this
document.
8 IANA Considerations 8 IANA Considerations
This document does not make any requests from IANA. This document does not make any requests from IANA.
9 References 9 References
9.1 Normative References 9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling, (VPLS) Using BGP for Auto-Discovery and Signaling,
RFC 4761, January 2007. RFC 4761, January 2007.
[RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, [RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson,
Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, Pseudowire Emulation Edge-to-Edge (PWE3) Control Word,
RFC 4385, February 2006. RFC 4385, February 2006.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017.
9.2 Informative References 9.2 Informative References
[RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation [RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005.
[VPLS-MULTIHOMING] Kothari, B., et al, BGP based Multi-homing in
Virtual Private LAN Service,
draft-ietf-bess-vpls-multihoming-02, September 2018.
Authors' Addresses Authors' Addresses
Ravi Singh Ravi Singh
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
EMail: ravis@juniper.net EMail: ravis@juniper.net
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
EMail: kireeti@juniper.net EMail: kireeti@juniper.net
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Nokia
EMail: senad.palislamovic@alcatel-lucent.com EMail: senad@nuagenetworks.net
 End of changes. 39 change blocks. 
109 lines changed or deleted 125 lines changed or added

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