< draft-ietf-bess-evpn-bum-procedure-updates-04.txt   draft-ietf-bess-evpn-bum-procedure-updates-05.txt >
BESS Z. Zhang BESS Z. Zhang
Internet-Draft W. Lin Internet-Draft W. Lin
Updates: 7432 (if approved) Juniper Networks Updates: 7432 (if approved) Juniper Networks
Intended status: Standards Track J. Rabadan Intended status: Standards Track J. Rabadan
Expires: December 29, 2018 Nokia Expires: June 16, 2019 Nokia
K. Patel K. Patel
Arrcus Arrcus
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
June 27, 2018 December 13, 2018
Updates on EVPN BUM Procedures Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-04 draft-ietf-bess-evpn-bum-procedure-updates-05
Abstract Abstract
This document specifies procedure updates for broadcast, unknown This document specifies procedure updates for broadcast, unknown
unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
including selective multicast, and provider tunnel segmentation. including selective multicast, and provider tunnel segmentation.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 29, 2018. This Internet-Draft will expire on June 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Reasons for Tunnel Segmentation . . . . . . . . . . . . . 4 2.1. Reasons for Tunnel Segmentation . . . . . . . . . . . . . 4
3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 5 3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 5
3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 6 3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 6
3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 6 3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 6
3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 7
4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 8
5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 8
5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 8 5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 9
5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 9 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 10
5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 11 5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 12
6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 12 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 12
6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 12 6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 12
6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 13 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14
6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 14 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15
6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 14 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 15
7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 15 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Terminology 1. Terminology
To be added It is expected that audience is familiar with EVPN and MVPN concepts
and terminologies. For convenience, the following terms are briefly
explained.
o PMSI: P-Multicast Service Interface - a conceptual interface for a
PE to send customer multicast traffic to all or some PEs in the
same VPN.
o I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
o Leaf A-D routes: For explicit leaf tracking purpose. Triggered by
S-PMSI A-D routes and targeted at triggering route's originator.
o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The
EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.
o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The
EVPN equivalent of MVPN Leaf A-D route but unsolicited and
untargeted.
2. Introduction 2. Introduction
RFC 7432 specifies procedures to handle broadcast, unknown unicast, RFC 7432 specifies procedures to handle broadcast, unknown unicast,
and multicast (BUM) traffic in Section 11, 12 and 16, using Inclusive and multicast (BUM) traffic in Section 11, 12 and 16, using Inclusive
Multicast Ethernet Tag Route. A lot of details are referred to RFC Multicast Ethernet Tag Route. A lot of details are referred to RFC
7117 (VPLS Multicast). In particular, selective multicast is briefly 7117 (VPLS Multicast). In particular, selective multicast is briefly
mentioned for Ingress Replication but referred to RFC 7117. mentioned for Ingress Replication but referred to RFC 7117.
RFC 7117 specifies procedures for using both inclusive tunnels and RFC 7117 specifies procedures for using both inclusive tunnels and
skipping to change at page 5, line 36 skipping to change at page 6, line 11
+-----------------------------------+ +-----------------------------------+
So far eight types have been defined: So far eight types have been defined:
+ 1 - Ethernet Auto-Discovery (A-D) route + 1 - Ethernet Auto-Discovery (A-D) route
+ 2 - MAC/IP Advertisement route + 2 - MAC/IP Advertisement route
+ 3 - Inclusive Multicast Ethernet Tag route + 3 - Inclusive Multicast Ethernet Tag route
+ 4 - Ethernet Segment route + 4 - Ethernet Segment route
+ 5 - IP Prefix Route + 5 - IP Prefix Route
+ 6 - Selective Multicast Ethernet Tag Route + 6 - Selective Multicast Ethernet Tag Route
+ 7 - IGMP Join Synch Route + 7 - Multicast Join Synch Route
+ 8 - IGMP Leave Synch Route + 8 - Multicast Leave Synch Route
This document defines three additional route types: This document defines three additional route types:
+ 9 - Per-Region I-PMSI A-D route + 9 - Per-Region I-PMSI A-D route
+ 10 - S-PMSI A-D route + 10 - S-PMSI A-D route
+ 11 - Leaf A-D route + 11 - Leaf A-D route
The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
starts with a type 1 RD, whose Administrative sub-field MUST match starts with a type 1 RD, whose Administrative sub-field MUST match
that of the RD in all the EVPN routes from the same advertising that of the RD in all the EVPN routes from the same advertising
skipping to change at page 8, line 18 skipping to change at page 8, line 42
with Leaf A-D routes if the Leaf Information Requested flag is set in with Leaf A-D routes if the Leaf Information Requested flag is set in
the S-PMSI A-D route's PTA (so that the source NVE can include them the S-PMSI A-D route's PTA (so that the source NVE can include them
as tunnel leaves). as tunnel leaves).
An optimization to the [RFC7117] procedures may be applied. Even if An optimization to the [RFC7117] procedures may be applied. Even if
a source NVE sets the LIR bit to request Leaf A-D routes, an egress a source NVE sets the LIR bit to request Leaf A-D routes, an egress
NVE may omit the Leaf A-D route if it already advertises a NVE may omit the Leaf A-D route if it already advertises a
corresponding SMET route, and the source NVE will use that in lieu of corresponding SMET route, and the source NVE will use that in lieu of
the Leaf A-D route. the Leaf A-D route.
5. Inter-AS Segmentation The optional optimizations specified for MVPN in
[I-D.ietf-bess-mvpn-expl-track] are also applicable to EVPN when the
S-PMSI/Leaf A-D routes procedures are used for EVPN selective
multicast forwarding.
5. Inter-AS Segmentation
5.1. Changes to Section 7.2.2 of RFC 7117 5.1. Changes to Section 7.2.2 of RFC 7117
The first paragraph of Section 7.2.2.2 of RFC 7117 says: The first paragraph of Section 7.2.2.2 of RFC 7117 says:
"... The best route procedures ensure that if multiple "... The best route procedures ensure that if multiple
ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
neighbors, only one of these ASBRs propagates this route in Internal neighbors, only one of these ASBRs propagates this route in Internal
BGP (IBGP). This ASBR becomes the root of the intra-AS segment of BGP (IBGP). This ASBR becomes the root of the intra-AS segment of
the inter-AS tree and ensures that this is the only ASBR that accepts the inter-AS tree and ensures that this is the only ASBR that accepts
traffic into this AS from the inter-AS tree." traffic into this AS from the inter-AS tree."
skipping to change at page 8, line 49 skipping to change at page 9, line 33
at another ASBR. This is the same as the procedures for S-PMSI in at another ASBR. This is the same as the procedures for S-PMSI in
RFC 7117 itself. RFC 7117 itself.
The following text at the end of the second bullet: The following text at the end of the second bullet:
"................................................... If, in order "................................................... If, in order
to instantiate the segment, the ASBR needs to know the leaves of to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR obtains this information from the A-D the tree, then the ASBR obtains this information from the A-D
routes received from other PEs/ASBRs in the ASBR's own AS." routes received from other PEs/ASBRs in the ASBR's own AS."
is changed to the following: is changed to the following when applied to EVPN:
"................................................... If, in order "................................................... If, in order
to instantiate the segment, the ASBR needs to know the leaves of to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to
trigger Leaf A-D routes from egress PEs and downstream ASBRs. trigger Leaf A-D routes from egress PEs and downstream ASBRs.
It MUST be (auto-)configured with an import RT, which controls It MUST be (auto-)configured with an import RT, which controls
acceptance of leaf A-D routes by the ASBR." acceptance of leaf A-D routes by the ASBR."
Accordingly, the following paragraph in Section 7.2.2.4: Accordingly, the following paragraph in Section 7.2.2.4:
"If the received Inter-AS A-D route carries the PMSI Tunnel attribute "If the received Inter-AS A-D route carries the PMSI Tunnel attribute
with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
that originated the route MUST establish an RSVP-TE P2MP LSP with the that originated the route MUST establish an RSVP-TE P2MP LSP with the
local PE/ASBR as a leaf. This LSP MAY have been established before local PE/ASBR as a leaf. This LSP MAY have been established before
the local PE/ASBR receives the route, or it MAY be established after the local PE/ASBR receives the route, or it MAY be established after
the local PE receives the route." the local PE receives the route."
is changed to the following: is changed to the following when applied to EVPN:
"If the received Inter-AS A-D route has the LIR flag set in its PTA, "If the received Inter-AS A-D route has the LIR flag set in its PTA,
then a receiving PE must originate a corresponding Leaf A-D route, then a receiving PE must originate a corresponding Leaf A-D route,
and a receiving ASBR must originate a corresponding Leaf A-D route and a receiving ASBR must originate a corresponding Leaf A-D route
if and only if it received and imported one or more corresponding Leaf if and only if it received and imported one or more corresponding Leaf
A-D routes from its downstream IBGP or EBGP peers, or it has non-null A-D routes from its downstream IBGP or EBGP peers, or it has non-null
downstream forwarding state for the PIM/mLDP tunnel that instantiates downstream forwarding state for the PIM/mLDP tunnel that instantiates
its downstream intra-AS segment. The ASBR that (re-)advertised the its downstream intra-AS segment. The ASBR that (re-)advertised the
Inter-AS A-D route then establishes a tunnel to the leaves discovered Inter-AS A-D route then establishes a tunnel to the leaves discovered
by the Leaf A-D routes." by the Leaf A-D routes."
skipping to change at page 11, line 22 skipping to change at page 12, line 5
o In an ingress/upstream AS, if and only if an ASBR has active o In an ingress/upstream AS, if and only if an ASBR has active
downstream receivers (PEs and ASBRs), which are learned either downstream receivers (PEs and ASBRs), which are learned either
explicitly via Leaf AD routes or implicitly via PIM join or mLDP explicitly via Leaf AD routes or implicitly via PIM join or mLDP
label mapping, the ASBR originates a per-PE I-PMSI A-D route label mapping, the ASBR originates a per-PE I-PMSI A-D route
(i.e., regular Inclusive Multicast Ethernet Tag route) into the (i.e., regular Inclusive Multicast Ethernet Tag route) into the
local AS, and stitches incoming per-PE I-PMSI tunnels into its local AS, and stitches incoming per-PE I-PMSI tunnels into its
per-region I-PMSI tunnel. With this, it gets traffic from local per-region I-PMSI tunnel. With this, it gets traffic from local
PEs and send to other ASes via the tunnel announced in its per- PEs and send to other ASes via the tunnel announced in its per-
region I-PMSI A-D route. region I-PMSI A-D route.
Note that, even if there is no backward compatibility issue, the Note that, even if there is no backward compatibility issue, the use
above procedures have the benefit of keeping all per-PE I-PMSI A-D of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D
routes in their local ASes, greatly reducing the flooding of the routes in their local ASes, greatly reducing the flooding of the
routes and their corresponding Leaf A-D routes (when needed), and the routes and their corresponding Leaf A-D routes (when needed), and the
number of inter-as tunnels. number of inter-as tunnels.
5.3.1. Designated ASBR Election 5.3.1. Designated ASBR Election
When an ASBR re-advertises a per-region I-PMSI A-D route into an AS When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
in which a designated ASBR needs to be used to forward traffic to the in which a designated ASBR needs to be used to forward traffic to the
legacy PEs in the AS, it SHOULD include a DF Election EC. The EC and legacy PEs in the AS, it SHOULD include a DF Election EC. The EC and
its use is specified in [I-D.ietf-bess-evpn-df-election-framework]. its use is specified in [I-D.ietf-bess-evpn-df-election-framework].
skipping to change at page 16, line 29 skipping to change at page 17, line 13
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-bess-evpn-df-election-framework] [I-D.ietf-bess-evpn-df-election-framework]
Rabadan, J., satyamoh@cisco.com, s., Sajassi, A., Drake, Rabadan, J., satyamoh@cisco.com, s., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for EVPN J., Nagaraj, K., and S. Sathappan, "Framework for EVPN
Designated Forwarder Election Extensibility", draft-ietf- Designated Forwarder Election Extensibility", draft-ietf-
bess-evpn-df-election-framework-03 (work in progress), May bess-evpn-df-election-framework-06 (work in progress),
2018. December 2018.
[I-D.ietf-bess-evpn-igmp-mld-proxy] [I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J.,
and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-
bess-evpn-igmp-mld-proxy-02 (work in progress), June 2018. bess-evpn-igmp-mld-proxy-02 (work in progress), June 2018.
[I-D.ietf-bess-mvpn-expl-track]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast
VPN", draft-ietf-bess-mvpn-expl-track-13 (work in
progress), November 2018.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
C. Kodeboniya, "Multicast in Virtual Private LAN Service C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
<https://www.rfc-editor.org/info/rfc7117>. <https://www.rfc-editor.org/info/rfc7117>.
skipping to change at page 17, line 18 skipping to change at page 18, line 7
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988, Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016, DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>. <https://www.rfc-editor.org/info/rfc7988>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-bess-evpn-overlay]
Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro,
J., and W. Henderickx, "A Network Virtualization Overlay
Solution using EVPN", draft-ietf-bess-evpn-overlay-12
(work in progress), February 2018.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-08 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), September 2017. progress), September 2017.
[I-D.zzhang-bier-evpn] [I-D.ietf-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", draft-zzhang-bier-evpn-00 (work in "EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in
progress), June 2017. progress), April 2018.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
 End of changes. 21 change blocks. 
38 lines changed or deleted 62 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/