< draft-ietf-bess-rfc7432bis-03.txt   draft-ietf-bess-rfc7432bis-04.txt >
BESS Working Group A. Sajassi BESS Working Group A. Sajassi
Internet-Draft LA. Burdet, Ed. Internet-Draft LA. Burdet, Ed.
Intended status: Standards Track Cisco Obsoletes: 7432 (if approved) Cisco
Expires: 1 September 2022 J. Drake Updates: 8214 (if approved) J. Drake
Juniper Intended status: Standards Track Juniper
J. Rabadan Expires: 8 September 2022 J. Rabadan
Nokia Nokia
28 February 2022 7 March 2022
BGP MPLS-Based Ethernet VPN BGP MPLS-Based Ethernet VPN
draft-ietf-bess-rfc7432bis-03 draft-ietf-bess-rfc7432bis-04
Abstract Abstract
This document describes procedures for BGP MPLS-based Ethernet VPNs This document describes procedures for BGP MPLS-based Ethernet VPNs
(EVPN). The procedures described here meet the requirements (EVPN). The procedures described here meet the requirements
specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
The complete and detailed set of all changes between this version and The complete and detailed set of all changes between this version and
RFC7432 may be found as an Annotated Diff (rfcdiff) here RFC7432 may be found as an Annotated Diff (rfcdiff) here
(https://tools.ietf.org/rfcdiff?url1=https://www.rfc- (https://tools.ietf.org/rfcdiff?url1=https://www.rfc-
editor.org/rfc/rfc7432.txt&url2=https://www.ietf.org/archive/id/ editor.org/rfc/rfc7432.txt&url2=https://www.ietf.org/archive/id/
draft-ietf-bess-rfc7432bis-03.txt). draft-ietf-bess-rfc7432bis-04.txt).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on 1 September 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 9 skipping to change at page 4, line 9
16. Multicast and Broadcast . . . . . . . . . . . . . . . . . . . 57 16. Multicast and Broadcast . . . . . . . . . . . . . . . . . . . 57
16.1. Ingress Replication . . . . . . . . . . . . . . . . . . 57 16.1. Ingress Replication . . . . . . . . . . . . . . . . . . 57
16.2. P2MP or MP2MP LSPs . . . . . . . . . . . . . . . . . . . 57 16.2. P2MP or MP2MP LSPs . . . . . . . . . . . . . . . . . . . 57
16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . 57 16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . 57
17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 58 17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 58
17.1. Transit Link and Node Failures between PEs . . . . . . . 58 17.1. Transit Link and Node Failures between PEs . . . . . . . 58
17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . 58 17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . 58
17.3. PE-to-CE Network Failures . . . . . . . . . . . . . . . 58 17.3. PE-to-CE Network Failures . . . . . . . . . . . . . . . 58
18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . 59 18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . 59
18.1. Flow Label . . . . . . . . . . . . . . . . . . . . . . . 60 18.1. Flow Label . . . . . . . . . . . . . . . . . . . . . . . 60
19. Use of Domain-wide Common Block (DCB) Labels . . . . . . . . 60 19. Use of Domain-wide Common Block (DCB) Labels . . . . . . . . 61
20. Security Considerations . . . . . . . . . . . . . . . . . . . 61 20. Security Considerations . . . . . . . . . . . . . . . . . . . 61
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
22.1. Normative References . . . . . . . . . . . . . . . . . . 64 22.1. Normative References . . . . . . . . . . . . . . . . . . 64
22.2. Informative References . . . . . . . . . . . . . . . . . 65 22.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. Acknowledgments for This Document (2021) . . . . . . 67 Appendix A. Acknowledgments for This Document (2021) . . . . . . 67
Appendix B. Contributors for This Document (2021) . . . . . . . 67 Appendix B. Contributors for This Document (2021) . . . . . . . 67
Appendix C. Acknowledgments from the First Edition (2015) . . . 68 Appendix C. Acknowledgments from the First Edition (2015) . . . 68
C.1. Contributors from the First Edition (2015) . . . . . . . 68 C.1. Contributors from the First Edition (2015) . . . . . . . 68
C.2. Authors from the First Edition (2015) . . . . . . . . . . 68 C.2. Authors from the First Edition (2015) . . . . . . . . . . 68
skipping to change at page 14, line 14 skipping to change at page 14, line 14
Broadcast, unknown unicast, or multicast (BUM) traffic is sent only Broadcast, unknown unicast, or multicast (BUM) traffic is sent only
to the CEs in a given broadcast domain; however, the broadcast to the CEs in a given broadcast domain; however, the broadcast
domains within an EVI either MAY each have their own P-Tunnel or MAY domains within an EVI either MAY each have their own P-Tunnel or MAY
share P-Tunnels -- e.g., all of the broadcast domains in an EVI MAY share P-Tunnels -- e.g., all of the broadcast domains in an EVI MAY
share a single P-Tunnel. share a single P-Tunnel.
In the case where a single VLAN is represented by a single VID and In the case where a single VLAN is represented by a single VID and
thus no VID translation is required, an MPLS-encapsulated packet MUST thus no VID translation is required, an MPLS-encapsulated packet MUST
carry that VID. The Ethernet Tag ID in all EVPN routes MUST be set carry that VID. The Ethernet Tag ID in all EVPN routes MUST be set
to that VID. The advertising PE MAY advertise the MPLS Label1 in the to that VID. The advertising PE MAY advertise the MPLS Label in the
MAC/IP Advertisement route representing ONLY the EVI or representing Ethernet A-D per EVI and MPLS Label1 in the MAC/IP Advertisement
both the Ethernet Tag ID and the EVI. This decision is only a local routes representing ONLY the EVI or representing both the Ethernet
matter by the advertising PE (which is also the disposition PE) and Tag ID and the EVI. This decision is only a local matter by the
doesn't affect any other PEs. advertising PE (which is also the disposition PE) and doesn't affect
any other PEs.
In the case where a single VLAN is represented by different VIDs on In the case where a single VLAN is represented by different VIDs on
different CEs and thus VID translation is required, a normalized different CEs and thus VID translation is required, a normalized
Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes. Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes.
Furthermore, the advertising PE advertises the MPLS Label1 in the Furthermore, the advertising PE advertises the MPLS Label1 in the
MAC/IP Advertisement route representing both the Ethernet Tag ID and MAC/IP Advertisement route representing both the Ethernet Tag ID and
the EVI, so that upon receiving an MPLS-encapsulated packet, it can the EVI, so that upon receiving an MPLS-encapsulated packet, it can
identify the corresponding bridge table from the MPLS EVPN label and identify the corresponding bridge table from the MPLS EVPN label and
perform Ethernet Tag ID translation ONLY at the disposition PE -- perform Ethernet Tag ID translation ONLY at the disposition PE --
i.e., the Ethernet frames transported over the MPLS/IP network MUST i.e., the Ethernet frames transported over the MPLS/IP network MUST
skipping to change at page 15, line 36 skipping to change at page 15, line 36
| | | |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 1: EVPN PE Model Figure 1: EVPN PE Model
A tenant configured for an EVPN service instance (i.e, EVI) on a PE, A tenant configured for an EVPN service instance (i.e, EVI) on a PE,
is instantiated by a single MAC Virtual Routing and Forwarding table is instantiated by a single MAC Virtual Routing and Forwarding table
(MAC-VRF) on that PE. A MAC-VRF consists of one or more Bridge (MAC-VRF) on that PE. A MAC-VRF consists of one or more Bridge
Tables (BTs) where each BT corresponds to a VLAN (broadcast domain - Tables (BTs) where each BT corresponds to a VLAN (broadcast domain -
BD). If a service interface for an EVPN PE is configured in VLAN- BD). If a service interface for an EVPN PE is configured in VLAN-
Based mode (i.e., section 6.1), then there is only a single BT per Based mode (i.e., Section 6.1), then there is only a single BT per
MAC-VRF (per EVI) - i.e., there is only one tenant VLAN per EVI. MAC-VRF (per EVI) - i.e., there is only one tenant VLAN per EVI.
However, if a service interface for an EVPN PE is configured in VLAN- However, if a service interface for an EVPN PE is configured in VLAN-
Aware Bundle mode (i.e., section 6.3), then there are several BTs per Aware Bundle mode (i.e., Section 6.3), then there are several BTs per
MAC-VRF (per EVI) - i.e., there are several tenant VLANs per EVI. MAC-VRF (per EVI) - i.e., there are several tenant VLANs per EVI.
The relationship among these terms can be summarized as follow: The relationship among these terms can be summarized as follow:
* An EVI consists of one or more BDs and a MAC-VRF consists of one * An EVI consists of one or more BDs and a MAC-VRF consists of one
or more BTs, one for each BD. A BD is identified by an Ethernet or more BTs, one for each BD. A BD is identified by an Ethernet
Tag ID which is typically represented by a single VLAN ID (VID); Tag ID which is typically represented by a single VLAN ID (VID);
however, it can be represented by multiple VIDs (i.e., Shared VLAN however, it can be represented by multiple VIDs (i.e., Shared VLAN
Learning (SVL) mode in 802.1Q). Learning (SVL) mode in 802.1Q).
* In VLAN-based mode, there is one EVI per VLAN and thus one BD/BT * In VLAN-based mode, there is one EVI per VLAN and thus one BD/BT
skipping to change at page 20, line 34 skipping to change at page 20, line 34
follows: follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | ESI Label | | Reserved=0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document creates an IANA registry called "EVPN ESI Multihoming This document creates an IANA registry called "EVPN ESI Multihoming
Attributes" (Section 21, where the following bits in Flags octet are Attributes" (Section 21 for the Flags octet, where the following
initially defined: field "Multihomed site redundancy mode (RED)" field is defined with
initial bit allocations:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |RED| (MBZ = MUST Be Zero) | MBZ |RED| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Name Meaning Name Meaning
--------------------------------------------------------------- ---------------------------------------------------------------
RED Multihomed site redundancy mode RED Multihomed site redundancy mode
skipping to change at page 23, line 48 skipping to change at page 23, line 48
enabled. enabled.
Usage and applicability of this Extended community to Bridging is Usage and applicability of this Extended community to Bridging is
clarified here. clarified here.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |RSV|RSV|F|C|P|B| (MBZ = MUST Be Zero) | MBZ |RSV|RSV|F|C|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bits in Control Flags from [RFC8214] are listed here The following bits in Control Flags are defined in [RFC8214]:
for completeness only:
Name Meaning Name Meaning
--------------------------------------------------------------- ---------------------------------------------------------------
P If set to 1 in multihoming Single-Active scenarios, P If set to 1 in multihoming Single-Active scenarios,
this flag indicates that the advertising PE is the this flag indicates that the advertising PE is the
primary PE. MUST be set to 1 for multihoming primary PE. MUST be set to 1 for multihoming
All-Active scenarios by all active PE(s). All-Active scenarios by all active PE(s).
B If set to 1 in multihoming Single-Active scenarios, B If set to 1 in multihoming Single-Active scenarios,
this flag indicates that the advertising PE is the this flag indicates that the advertising PE is the
backup PE. backup PE.
C If set to 1, a control word [RFC4448] MUST be present C If set to 1, a control word [RFC4448] MUST be present
when sending EVPN packets to this PE. It is when sending EVPN packets to this PE. It is
recommended that the control word be included in the recommended that the control word be included in the
absence of an entropy label [RFC6790].</t> absence of an entropy label [RFC6790].</t>
The bits in Control Flags are extended by the following defined bits: The bits in Control Flags are extended, and [RFC8214] updated, by the
following additional bits:
Name Meaning Name Meaning
--------------------------------------------------------------- ---------------------------------------------------------------
F If set to 1, a Flow Label MUST be present F If set to 1, a Flow Label SHOULD be present
when sending EVPN packets to this PE. when sending EVPN packets to this PE.
If set to 0, a Flow Label MUST NOT be present If set to 0, a Flow Label MUST NOT be present
when sending EVPN packets to this PE. when sending EVPN packets to this PE.
For procedures and usage of this extended community, with respect to For procedures and usage of this extended community, with respect to
Control Word and Flow Label, please see Section 18. ("Frame Control Word and Flow Label, please see Section 18. ("Frame
Ordering"). Ordering").
For procedures and usage of this extended community, with respect to For procedures and usage of this extended community, with respect to
Primary-Backup bits, please see Section 8.5. ("Designated Forwarder Primary-Backup bits, please see Section 8.5. ("Designated Forwarder
skipping to change at page 36, line 13 skipping to change at page 36, line 13
segment. segment.
3. When the timer expires, each PE builds an ordered list of the IP 3. When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet segment addresses of all the PE nodes connected to the Ethernet segment
(including itself), in increasing numeric value. Each IP address (including itself), in increasing numeric value. Each IP address
in this list is extracted from the "IP Address length" and in this list is extracted from the "IP Address length" and
"Originating Router's IP address" fields of the advertised "Originating Router's IP address" fields of the advertised
Ethernet Segment route. Every PE is then given an ordinal Ethernet Segment route. Every PE is then given an ordinal
indicating its position in the ordered list, starting with 0 as indicating its position in the ordered list, starting with 0 as
the ordinal for the PE with the lowest IP address length and the ordinal for the PE with the lowest IP address length and
numeric value tuple. The ordinals are used to determine which PE numeric value tuple. The tuple list is ordered by the IP address
node will be the DF for a given EVPN instance on the Ethernet length first and IP address value second. The ordinals are used
segment, using the following rule: to determine which PE node will be the DF for a given EVPN
instance on the Ethernet segment, using the following rule:
Assuming a redundancy group of N PE nodes, the PE with ordinal i Assuming a redundancy group of N PE nodes, the PE with ordinal i
is the DF for an <ES, EVI> when (V mod N) = i, where V is the is the DF for an <ES, EVI> when (V mod N) = i, where V is the
Ethernet tag for that EVI. For VLAN-Aware Bundle service, then Ethernet tag for that EVI. For VLAN-Aware Bundle service, then
the numerically lowest Ethernet tag in that EVI MUST be used in the numerically lowest Ethernet tag in that EVI MUST be used in
the modulo function. the modulo function.
It should be noted that using the "Originating Router's IP It should be noted that using the "Originating Router's IP
address" field in the Ethernet Segment route to get the PE IP address" field in the Ethernet Segment route to get the PE IP
address needed for the ordered list allows for a CE to be address needed for the ordered list allows for a CE to be
multihomed across different ASes if such a need ever arises. multihomed across different ASes if such a need ever arises.
skipping to change at page 60, line 8 skipping to change at page 60, line 8
* When sending EVPN-encapsulated packets over a P2MP LSP (e.g., * When sending EVPN-encapsulated packets over a P2MP LSP (e.g.,
using mLDP signaling), then the control word SHOULD be used. using mLDP signaling), then the control word SHOULD be used.
* If a network uses entropy labels per [RFC6790], then the control * If a network uses entropy labels per [RFC6790], then the control
word SHOULD NOT be used when sending EVPN-encapsulated packets word SHOULD NOT be used when sending EVPN-encapsulated packets
over an MP2P LSP. over an MP2P LSP.
18.1. Flow Label 18.1. Flow Label
Flow label is used to add entropy to divisible flows, and creates Flow label is used to add entropy to divisible flows, and creates
ECMP load-balancing in the network. The Flow Label MAY be used in ECMP load-balancing in the network. The Flow label MAY be used in
EVPN networks to achieve better load-balancing in the network, when EVPN networks to achieve better load-balancing in the network, when
transit nodes perform deep packet inspection for ECMP hashing. The transit nodes perform deep packet inspection for ECMP hashing. The
following rules apply: following rules apply:
* When F-bit is set to 1, the PE announces the capability of both * When F-bit is set to 1, the PE announces the capability of both
sending and receiving flow label for known unicast. If the PE is sending and receiving flow label for known unicast.
capable of supporting Flow Label, then :
If the PE is capable itself of supporting Flow Label, then:
- upon receiving the F-bit set (F=1) from a remote PE, it MUST - upon receiving the F-bit set (F=1) from a remote PE, it MUST
send known unicast packets to that PE with Flow labels; send known unicast packets to that PE with Flow labels;
- alternately, upon receiving the F-bit unset (F=0) from a - alternately, upon receiving the F-bit unset (F=0) from a
remote PE, it MUST NOT send known unicast packets to that PE remote PE, it MUST NOT send known unicast packets to that PE
with Flow labels. with Flow labels.
Receiving the F-bit set (F=1) from a remote PE has no effect when
the PE itself does not support Flow label.
* The Flow Label MUST NOT be used for EVPN-encapsulated BUM packets. * The Flow Label MUST NOT be used for EVPN-encapsulated BUM packets.
* An ingress PE will push the Flow Label at the bottom of the stack * An ingress PE will push the Flow Label at the bottom of the stack
of the EVPN-encapsulated known unicast packets sent to an egress of the EVPN-encapsulated known unicast packets sent to an egress
PE that previously signaled F-bit set to 1. PE that previously signaled F-bit set to 1.
* If a PE receives a unicast packet with two labels, then it can * If a PE receives a unicast packet with two labels, then it can
differentiate between [VPN label + ESI label] and [VPN label + differentiate between [VPN label + ESI label] and [VPN label +
Flow label] and there should be no ambiguity between ESI and Flow Flow label] and there should be no ambiguity between ESI and Flow
labels even if they overlap. The reason for this is that the labels even if they overlap. The reason for this is that the
skipping to change at page 60, line 48 skipping to change at page 61, line 5
the VPN label is for known unicast, then the next label MUST be a the VPN label is for known unicast, then the next label MUST be a
flow label and if the VPN label is for BUM traffic, then the next flow label and if the VPN label is for BUM traffic, then the next
label MUST be an ESI label because BUM packets are not sent with label MUST be an ESI label because BUM packets are not sent with
Flow labels. Flow labels.
* When sending EVPN-encapsulated packets over a P2MP LSP (either * When sending EVPN-encapsulated packets over a P2MP LSP (either
RSVP-TE or mLDP), flow label SHOULD NOT be used. This is RSVP-TE or mLDP), flow label SHOULD NOT be used. This is
independant of any F-bit signalling in the L2-Attr Extended independant of any F-bit signalling in the L2-Attr Extended
Community which would still apply to unicast. Community which would still apply to unicast.
* This document updates the procedures in [RFC8214] to include
optional use of the F-bit defined in Section 7.11 thus adding
support for flow-aware transport of EVPN-VPWS signaled
pseudowires.
19. Use of Domain-wide Common Block (DCB) Labels 19. Use of Domain-wide Common Block (DCB) Labels
The use of DCB labels as in The use of DCB labels as in
[I-D.ietf-bess-mvpn-evpn-aggregation-label] is RECOMMENDED in the [I-D.ietf-bess-mvpn-evpn-aggregation-label] is RECOMMENDED in the
following cases: following cases:
* Aggregate P-multicast trees: A P-multicast tree MAY aggregate the * Aggregate P-multicast trees: A P-multicast tree MAY aggregate the
traffic of two or more BDs on a given ingress PE. When traffic of two or more BDs on a given ingress PE. When
aggregation is needed, DCB Labels aggregation is needed, DCB Labels
[I-D.ietf-bess-mvpn-evpn-aggregation-label] MAY be used in the [I-D.ietf-bess-mvpn-evpn-aggregation-label] MAY be used in the
 End of changes. 18 change blocks. 
28 lines changed or deleted 40 lines changed or added

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