draft-ietf-bess-ir-03.txt   draft-ietf-bess-ir-04.txt 
BESS Working Group E. Rosen, Ed. BESS Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 6513,6514 (if approved) K. Subramanian Updates: 6513,6514 (if approved) K. Subramanian
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: October 13, 2016 Z. Zhang Expires: February 6, 2017 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
April 11, 2016 August 5, 2016
Ingress Replication Tunnels in Multicast VPN Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-03 draft-ietf-bess-ir-04
Abstract Abstract
RFCs 6513, 6514, and other RFCs describe procedures by which a RFCs 6513, 6514, and other RFCs describe procedures by which a
Service Provider may offer Multicast VPN service to its customers. Service Provider may offer Multicast VPN service to its customers.
These procedures create point-to-multipoint (P2MP) or multipoint-to- These procedures create point-to-multipoint (P2MP) or multipoint-to-
multipoint trees across the Service Provider's backbone. One type of multipoint trees across the Service Provider's backbone. One type of
P2MP tree that may be used is known as an "Ingress Replication (IR) P2MP tree that may be used is known as an "Ingress Replication (IR)
tunnel". In an IR tunnel, a parent node need not be "directly tunnel". In an IR tunnel, a parent node need not be "directly
connected" to its child nodes. When a parent node has to send a connected" to its child nodes. When a parent node has to send a
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 13, 2016. This Internet-Draft will expire on February 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 27 skipping to change at page 2, line 27
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
2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5 2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
3. How are IR P-tunnels Identified? . . . . . . . . . . . . . . 7 3. How are IR P-tunnels Identified? . . . . . . . . . . . . . . 7
4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 9 4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 9
4.1. Advertised IR P-tunnels . . . . . . . . . . . . . . . . . 9 4.1. Advertised IR P-tunnels . . . . . . . . . . . . . . . . . 9
4.1.1. If the 'Leaf Info Required Bit' is Set . . . . . . . 9 4.1.1. If the 'Leaf Info Required Bit' is Set . . . . . . . 10
4.1.2. If the 'Leaf Info Required Bit' is Not Set . . . . . 10 4.1.2. If the 'Leaf Info Required Bit' is Not Set . . . . . 10
4.2. Unadvertised IR P-tunnels . . . . . . . . . . . . . . . . 11 4.2. Unadvertised IR P-tunnels . . . . . . . . . . . . . . . . 11
5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11 5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11
6. A Note on IR P-tunnels and 'Discarding Packets from the Wrong 6. A Note on IR P-tunnels and 'Discarding Packets from the Wrong
PE' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 PE' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 13 7. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 13
7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14 7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 15 7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 16
7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17 7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
8. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 17 8. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 17
9. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 18 9. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 18
10. Use of Timers when Switching UMH . . . . . . . . . . . . . . 19 10. Use of Timers when Switching UMH . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 21
skipping to change at page 5, line 8 skipping to change at page 5, line 8
This document also discusses the MPLS label allocation policies that This document also discusses the MPLS label allocation policies that
need to be supported when binding MPLS labels to IR P-tunnels, and need to be supported when binding MPLS labels to IR P-tunnels, and
the timer policies that need to be supported when switching a the timer policies that need to be supported when switching a
customer multicast flow from one IR P-tunnel to another. These are customer multicast flow from one IR P-tunnel to another. These are
procedures that are not clearly specified in [RFC6513] or [RFC6514]. procedures that are not clearly specified in [RFC6513] or [RFC6514].
As the material in this document must be understood in order to As the material in this document must be understood in order to
properly implement IR P-tunnels, this document is considered to properly implement IR P-tunnels, this document is considered to
update [RFC6513] and [RFC6514]. update [RFC6513] and [RFC6514].
This document also discusses the application of "seamless multicast" This document also discusses the application of "seamless multicast"
[RFC7524] and "extranet" [MVPN-XNET] procedures to IR P-tunnels. [RFC7524] and "extranet" [RFC7900] procedures to IR P-tunnels.
This draft does not discuss the use of IR P-tunnels to support a VPN This draft does not discuss the use of IR P-tunnels to support a VPN
customer's use of Bidirectional Protocol Independent Multicast customer's use of Bidirectional Protocol Independent Multicast
(BIDIR-PIM). [RFC7740] explains how to adapt the procedures of (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of
[RFC6513], [RFC6514], and [RFC7582] so that a customer's use of [RFC6513], [RFC6514], and [RFC7582] so that a customer's use of
BIDIR-PIM can be supported by IR P-tunnels. BIDIR-PIM can be supported by IR P-tunnels.
In the event of any conflict between this document and either
[RFC6513] or [RFC6514], this document takes precedence.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are "OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119]. to be interpreted as described in [RFC2119].
2. What is an IR P-tunnel? 2. What is an IR P-tunnel?
An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that
support the MVPN procedures of [RFC6514] and related RFCs. In support the MVPN procedures of [RFC6514] and related RFCs. In
general, the nodes of an IR P-tunnel are either Provider Edge (PE) general, the nodes of an IR P-tunnel are either Provider Edge (PE)
skipping to change at page 7, line 4 skipping to change at page 7, line 9
required is that when the data packets arrive at R2, R2 will see the required is that when the data packets arrive at R2, R2 will see the
"P-tunnel label" at the top of the packets' label stack; R2's further "P-tunnel label" at the top of the packets' label stack; R2's further
processing of the packets will depend upon that label. Note that the processing of the packets will depend upon that label. Note that the
same unicast tunnel between R1 and R2 may also be carrying unicast same unicast tunnel between R1 and R2 may also be carrying unicast
data packets. data packets.
Typically the unicast tunnels are the Label Switched Paths (LSPs) Typically the unicast tunnels are the Label Switched Paths (LSPs)
that already exist to carry unicast traffic; either MP2P LSPs created that already exist to carry unicast traffic; either MP2P LSPs created
by LDP (Label Distribution Protocol, [RFC5036]) or P2P LSPs created by LDP (Label Distribution Protocol, [RFC5036]) or P2P LSPs created
by RSVP-TE (Resource Reservation Protocol - Traffic Engineering, by RSVP-TE (Resource Reservation Protocol - Traffic Engineering,
[RFC3209]). However, any other kind of unicast tunnel may be used. [RFC3209]). However, any other kind of unicast tunnel may be used.
A unicast tunnel may have an arbitrary number of intermediate A unicast tunnel may have an arbitrary number of intermediate
routers; those routers do not maintain any multicast state for the IR routers; those routers do not maintain any multicast state for the IR
P-tunnel, and in general are not even aware of its existence. P-tunnel, and in general are not even aware of its existence.
As with all other P-tunnel types, IR P-tunnels may be used as As with all other P-tunnel types, an IR P-tunnel may be used to
Inclusive P-tunnels or as Selective P-tunnels. instantiate either an Inclusive PMSI or a Selective PMSI. See
Section 3.2 of [RFC6513] for an explanation of those concepts.
3. How are IR P-tunnels Identified? 3. How are IR P-tunnels Identified?
There are four MVPN BGP route types in which P-tunnels can be There are four MVPN BGP route types in which P-tunnels can be
identified: Intra-AS I-PMSI A-D (Intra Autonomous System Inclusive identified: Intra-AS I-PMSI A-D (Intra Autonomous System Inclusive
PMSI A-D) routes, Inter-AS I-PMSI A-D routes, S-PMSI (Selective PMSI) PMSI A-D) routes, Inter-AS I-PMSI A-D routes, S-PMSI (Selective PMSI)
A-D routes, and Leaf A-D routes. (These route types are all defined A-D routes, and Leaf A-D routes. (These route types are all defined
in [RFC6514]). in [RFC6514]).
Whenever it is necessary to identify a P-tunnel in a route of one of Whenever it is necessary to identify a P-tunnel in a route of one of
skipping to change at page 13, line 11 skipping to change at page 13, line 21
o When segmented P-tunnels are being used, the IP source address o When segmented P-tunnels are being used, the IP source address
field of the encapsulating IP header might not contain the address field of the encapsulating IP header might not contain the address
of the ingress PE. of the ingress PE.
o Even if the IP source address field of the encapsulating IP header o Even if the IP source address field of the encapsulating IP header
does identify the ingress PE, there is no guarantee that the IP does identify the ingress PE, there is no guarantee that the IP
source address in that header is the same as the IP address used source address in that header is the same as the IP address used
by the ingress PE for the MVPN signaling procedures. by the ingress PE for the MVPN signaling procedures.
o To apply the procedures of Section 9.1.1 of [RFC6513] when o To apply the procedures of Section 9.1.1 of [RFC6513] when
extranet functionality [MVPN-XNET] is supported, it is necessary extranet functionality [RFC7900] is supported, it is necessary to
to infer a packet's ingress VRF (Virtual Routing and Forwarding infer a packet's ingress VRF (Virtual Routing and Forwarding
table), not merely its ingress PE. This can be inferred from the table), not merely its ingress PE. This can be inferred from the
P-tunnel label (assuming that the label is allocated following the P-tunnel label (assuming that the label is allocated following the
procedures of Section 7), but can not be inferred from the IP procedures of Section 7), but can not be inferred from the IP
source address of the encapsulating IP header. source address of the encapsulating IP header.
We therefore assume in this document that if the procedures of We therefore assume in this document that if the procedures of
Section 9.1.1 of [RFC6513] are to be applied to packets traveling Section 9.1.1 of [RFC6513] are to be applied to packets traveling
through IR P-tunnels, those procedures will be based on the P-tunnel through IR P-tunnels, those procedures will be based on the P-tunnel
label, even if the IR P-tunnel is using IP unicast tunnels. label, even if the IR P-tunnel is using IP unicast tunnels.
skipping to change at page 15, line 29 skipping to change at page 15, line 40
node not forward duplicate data, whenever the egress node changes the node not forward duplicate data, whenever the egress node changes the
RT that it attaches to a Leaf A-D route, it MUST also change the RT that it attaches to a Leaf A-D route, it MUST also change the
"MPLS Label" specified in the Leaf A-D route's PTA. This allows the "MPLS Label" specified in the Leaf A-D route's PTA. This allows the
egress router to distinguish between packets arriving on a given egress router to distinguish between packets arriving on a given
P-tunnel from the old parent and packets arriving on that same P-tunnel from the old parent and packets arriving on that same
P-tunnel from the new parent. At any given time, a router MUST P-tunnel from the new parent. At any given time, a router MUST
consider itself to have only a single parent node on a given consider itself to have only a single parent node on a given
P-tunnel, and MUST discard traffic that arrives on that P-tunnel from P-tunnel, and MUST discard traffic that arrives on that P-tunnel from
a different parent node. a different parent node.
If extranet functionality [MVPN-XNET] is not implemented in a If extranet functionality [RFC7900] is not implemented in a
particular egress PE, or if an egress PE is provisioned with the particular egress PE, or if an egress PE is provisioned with the
knowledge that extranet functionality is not needed, the PE may adopt knowledge that extranet functionality is not needed, the PE may adopt
the policy of assigning a label that is unique for the ordered triple the policy of assigning a label that is unique for the ordered triple
<root, parent node, egress VRF>. This will enable the egress PE to <root, parent node, egress VRF>. This will enable the egress PE to
apply the duplicate prevention procedures discussed above, and to apply the duplicate prevention procedures discussed above, and to
determine the VRF to which an arriving packet must be directed. determine the VRF to which an arriving packet must be directed.
However, this policy is not sufficient to support the "Discard However, this policy is not sufficient to support the "Discard
Packets from the Wrong P-tunnel" procedures that are specified in Packets from the Wrong P-tunnel" procedures that are specified in
[MVPN-XNET]. To support those procedures, the labels specified in [RFC7900]. To support those procedures, the labels specified in the
the PTA of Leaf A-D routes originated by a given egress PE MUST be PTA of Leaf A-D routes originated by a given egress PE MUST be unique
unique for the ordered triple <root, root RD, parent node>, where the for the ordered triple <root, root RD, parent node>, where the "root
"root RD" is taken from the RD field of the IR P-tunnel identifier. RD" is taken from the RD field of the IR P-tunnel identifier. (All
(All forms of IR P-tunnel identifier contain an embedded "RD" field.) forms of IR P-tunnel identifier contain an embedded "RD" field.)
This policy is also sufficient for supporting non-extranet cases, but This policy is also sufficient for supporting non-extranet cases, but
in some cases may result in the use of more labels than the policy of in some cases may result in the use of more labels than the policy of
the previous paragraph. the previous paragraph.
7.2. Leaf A-D Route Originated by an Intermediate Node 7.2. Leaf A-D Route Originated by an Intermediate Node
When a P-tunnel is segmented, there will be "intermediate nodes", When a P-tunnel is segmented, there will be "intermediate nodes",
i.e., nodes that have a parent and also have children on the i.e., nodes that have a parent and also have children on the
P-tunnel. Each intermediate node is a leaf node of an "upstream P-tunnel. Each intermediate node is a leaf node of an "upstream
segment" and a parent node of one or more "downstream segments". The segment" and a root node of one or more "downstream segments". The
intermediate node needs to set up its forwarding state so that data intermediate node needs to set up its forwarding state so that data
it receives on the upstream segment gets transmitted on the proper it receives on the upstream segment gets transmitted on the proper
downstream segments. downstream segments.
If the upstream segment is instantiated by IR, the intermediate node If the upstream segment is instantiated by IR, the intermediate node
will need to originate a Leaf A-D route to join that segment, and will need to originate a Leaf A-D route to join that segment, and
will need to allocate a downstream-assigned MPLS label to advertise will need to allocate a downstream-assigned MPLS label to advertise
in the MPLS label field of the Leaf A-D route's PTA. Section 7.1 in the MPLS label field of the Leaf A-D route's PTA. Section 7.1
specifies constraints on the label allocation policy for egress PEs; specifies constraints on the label allocation policy for egress PEs;
this section specifies constraints on the label allocation policy for this section specifies constraints on the label allocation policy for
skipping to change at page 18, line 46 skipping to change at page 19, line 9
indicates that it is identifying a P-tunnel advertised in an indicates that it is identifying a P-tunnel advertised in an
S-PMSI A-D route, S-PMSI A-D route,
* R1 has neither originated nor installed any such S-PMSI A-D * R1 has neither originated nor installed any such S-PMSI A-D
route. route.
If at some later time, R1 installs the corresponding S-PMSI A-D If at some later time, R1 installs the corresponding S-PMSI A-D
route, and the Leaf A-D route is still installed, and the Leaf A-D route, and the Leaf A-D route is still installed, and the Leaf A-D
route's RT still identifies R1, then R1 MUST follow the same route's RT still identifies R1, then R1 MUST follow the same
procedures it would have followed if the S-PMSI A-D route had been procedures it would have followed if the S-PMSI A-D route had been
installed before the Leaf A-D route was installed. (I.e., installed before the Leaf A-D route was installed. Implementers must
implementers must not assume that events occur in the "usual" or not assume that events occur in the "usual" or "expected" order.
"expected" order.)
10. Use of Timers when Switching UMH 10. Use of Timers when Switching UMH
Consider a child node that has joined a particular IR P-tunnel via a Consider a child node that has joined a particular IR P-tunnel via a
particular UMH. To do so, it will have originated a Leaf A-D route particular UMH. To do so, it will have originated a Leaf A-D route
with an RT that identifies the UMH. Suppose the child node now with an RT that identifies the UMH. Suppose the child node now
determines (for whatever reason) that it needs to change its UMH for determines (for whatever reason) that it needs to change its UMH for
that P-tunnel. It does this by: that P-tunnel. It does this by:
o modifying the RT of the Leaf A-D route, so that the RT now o modifying the RT of the Leaf A-D route, so that the RT now
skipping to change at page 21, line 17 skipping to change at page 21, line 26
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515, Addresses in BGP Updates for Multicast VPN", RFC 6515,
DOI 10.17487/RFC6515, February 2012, DOI 10.17487/RFC6515, February 2012,
<http://www.rfc-editor.org/info/rfc6515>. <http://www.rfc-editor.org/info/rfc6515>.
14.2. Informative References 14.2. Informative References
[MVPN-XNET]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
draft draft-ietf-bess-mvpn-extranet-06, January 2016.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
skipping to change at page 22, line 17 skipping to change at page 22, line 22
VPN (BGP-MVPN) Procedures", RFC 7716, VPN (BGP-MVPN) Procedures", RFC 7716,
DOI 10.17487/RFC7716, December 2015, DOI 10.17487/RFC7716, December 2015,
<http://www.rfc-editor.org/info/rfc7716>. <http://www.rfc-editor.org/info/rfc7716>.
[RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating [RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating
Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider
Tunnels with Ingress Replication", RFC 7740, Tunnels with Ingress Replication", RFC 7740,
DOI 10.17487/RFC7740, January 2016, DOI 10.17487/RFC7740, January 2016,
<http://www.rfc-editor.org/info/rfc7740>. <http://www.rfc-editor.org/info/rfc7740>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
RFC 7900, DOI 10.17487/RFC7900, June 2016,
<http://www.rfc-editor.org/info/rfc7900>.
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 17 change blocks. 
27 lines changed or deleted 29 lines changed or added

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