draft-ietf-mpls-ldp-dod-03.txt   draft-ietf-mpls-ldp-dod-04.txt 
Network Working Group T. Beckhaus Network Working Group T. Beckhaus
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational B. Decraene Intended status: Informational B. Decraene
Expires: February 3, 2013 France Telecom Expires: August 7, 2013 France Telecom
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz M. Konstantynowicz
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
August 2, 2012 February 3, 2013
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-03 draft-ietf-mpls-ldp-dod-04
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of using standardized IP/MPLS protocols. One of the key goals of
Seamless MPLS is to meet requirements specific to access, including Seamless MPLS is to meet requirements specific to access, including
high number of devices, their position in network topology and their high number of devices, their position in network topology and their
compute and memory constraints that limit the amount of state access compute and memory constraints that limit the amount of state access
devices can hold.This can be achieved with LDP Downstream-on-Demand devices can hold.This can be achieved with LDP Downstream-on-Demand
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 February 3, 2013. This Internet-Draft will expire on August 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5
2.1. Access Topologies with Static Routing . . . . . . . . . . 6 2.1. Access Topologies with Static Routing . . . . . . . . . . 6
2.2. Access Topologies with Access IGP . . . . . . . . . . . . 9 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 8
3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 11 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10
3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 11 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 10
3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 13 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 12
3.2. Service Provisioning and Activation . . . . . . . . . . . 13 3.2. Service Provisioning and Activation . . . . . . . . . . . 12
3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 3.3. Service Changes and Decommissioning . . . . . . . . . . . 15
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 18
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 19
4.1. LDP Label Distribution Control and Retention Modes . . . . 20 4.1. LDP Label Distribution Control and Retention Modes . . . . 19
4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23
4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 23
4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 25
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 26
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 28 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 29 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28
6.1.1. Access to network packet flow direction . . . . . . . 29 6.1.1. Access to network packet flow direction . . . . . . . 28
6.1.2. Network to access packet flow direction . . . . . . . 29 6.1.2. Network to access packet flow direction . . . . . . . 28
6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29
6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single
IP/MPLS network to scale over core, metro and access parts of a large IP/MPLS network to scale over core, metro and access parts of a large
packet network infrastructure using standardized IP/MPLS protocols. packet network infrastructure using standardized IP/MPLS protocols.
One of the key goals of Seamless MPLS is to meet requirements One of the key goals of Seamless MPLS is to meet requirements
specific to access, including high number of devices, their position specific to access, including high number of devices, their position
in network topology and their compute and memory constraints that in network topology and their compute and memory constraints that
limit the amount of state access devices can hold. limit the amount of state access devices can hold.
In general MPLS routers implement either LDP or RSVP for MPLS label In general MPLS Label Switching Routers implement either LDP or RSVP
distribution. The focus of this document is on LDP, as Seamless MPLS for MPLS label distribution.
design does not include a requirement for general purpose explicit
traffic engineering and bandwidth reservation. This document is The focus of this document is on LDP, as Seamless MPLS design does
focusing on the unicast connectivity only. Multicast connectivity is not include a requirement for general purpose explicit traffic
subject for further study. engineering and bandwidth reservation. Document concentrates on the
unicast connectivity only. Multicast connectivity is subject for
further study.
In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS
protocol optimization is possible due to a relatively simple access protocol optimization is possible due to a relatively simple access
network topologies. Examples of such topologies involving access network topologies. Examples of such topologies involving access
nodes (AN) and aggregation nodes (AGN) include: nodes (AN) and aggregation nodes (AGN) include:
a. A single AN homed to a single AGN. a. A single AN homed to a single AGN.
b. A single AN dual-homed to two AGNs. b. A single AN dual-homed to two AGNs.
skipping to change at page 4, line 51 skipping to change at page 5, line 4
with either static routes or dedicated access IGP. Note that in all with either static routes or dedicated access IGP. Note that in all
of the above topologies AGNs act as the access border routers (access of the above topologies AGNs act as the access border routers (access
ABRs) connecting the access topology to the rest of the network. ABRs) connecting the access topology to the rest of the network.
Hence in many cases it is sufficient for ANs to have a default route Hence in many cases it is sufficient for ANs to have a default route
pointing towards AGNs in order to achieve complete network pointing towards AGNs in order to achieve complete network
connectivity from ANs to the network. connectivity from ANs to the network.
The amount of MPLS forwarding state however requires additional The amount of MPLS forwarding state however requires additional
consideration. In general MPLS routers implement LDP Downstream consideration. In general MPLS routers implement LDP Downstream
Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS
labels for all valid routes in their RIB. This is seen as a very labels for all valid routes in their RIB. This is seen as an
insufficient approach for ANs, as they only require a small subset of inadequate approach for ANs, which requires a small subset of the
the total routes (and associated labels) based on the required total routes (and associated labels) based on the required
connectivity for the provisioned services. And although filters can connectivity for the provisioned services. And although filters can
be applied to those LDP DU labels advertisements, it is not seen as a be applied to those LDP DU labels advertisements, it is not seen as a
suitable tool to facilitate any-to-any AN-driven connectivity between suitable tool to facilitate any-to-any AN-driven connectivity between
access and the rest of the MPLS network. access and the rest of the MPLS network.
This document describes an access node driven "subscription model" This document describes an access node driven "subscription model"
for label distribution in the access. The approach relies on the for label distribution in the access. The approach relies on the
standard LDP Downstream-on-Demand (LDP DoD) label advertisements as standard LDP Downstream-on-Demand (LDP DoD) label advertisements as
specified in [RFC5036]. LDP DoD enables on-demand label distribution specified in [RFC5036]. LDP DoD enables on-demand label distribution
ensuring that only required labels are requested, provided and ensuring that only required labels are requested, provided and
installed. installed.
Note that LDP DoD implementation is not widely available in today's
IP/MPLS devices despite the fact that it has been described in the
LDP specification [RFC5036]. This is due to the fact that the
originally LDP DoD advertisement mode was aimed mainly at ATM and
Frame Relay MPLS implementations, where conserving label space used
on the links was essential for compatibility with ATM and Frame Relay
LSRs.
The following sections describe a set of reference access topologies The following sections describe a set of reference access topologies
considered for LDP DoD usage and their associated IP routing considered for LDP DoD usage and their associated IP routing
configurations, followed by LDP DoD use cases and LDP DoD procedures configurations, followed by LDP DoD use cases and LDP DoD procedures
in the context of Seamless MPLS design. in the context of Seamless MPLS design.
2. Reference Topologies 2. Reference Topologies
LDP DoD use cases are described in the context of a generic reference LDP DoD use cases are described in the context of a generic reference
end-to-end network topology based on Seamless MPLS design end-to-end network topology based on Seamless MPLS design
[I-D.ietf-mpls-seamless-mpls] shown in Figure 1 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1
skipping to change at page 11, line 25 skipping to change at page 10, line 25
IPVPN [RFC4364]. IPVPN [RFC4364].
Described LDP DoD operations apply equally to all reference access Described LDP DoD operations apply equally to all reference access
topologies described in Section 2. Operations that are specific to topologies described in Section 2. Operations that are specific to
certain access topologies are called out explicitly. certain access topologies are called out explicitly.
References to upstream and downstream nodes are made in line with the References to upstream and downstream nodes are made in line with the
definition of upstream and downstream LSR [RFC3031]. definition of upstream and downstream LSR [RFC3031].
This document is focusing on IPv4 LDP DoD procedures. Similar This document is focusing on IPv4 LDP DoD procedures. Similar
procedures are required for IPv6 LDP DoD, however some extension procedures will apply to IPv6 LDP DoD [I-D.ietf-mpls-ldp-ipv6].
specific to IPv6 are likely to apply including LSP mapping, peer
discovery, transport connection establishment. These will be added
in this document once LDP IPv6 standardization is advanced as per
[I-D.ietf-mpls-ldp-ipv6].
3.1. Initial Network Setup 3.1. Initial Network Setup
An access node is commissioned without any services provisioned on An access node is commissioned without any services provisioned on
it. The AN may request labels for loopback addresses of any AN, AGN it. The AN may request labels for loopback addresses of any AN, AGN
or other nodes within Seamless MPLS network for operational and or other nodes within Seamless MPLS network for operational and
management purposes. It is assumed that AGN1x has required IP/MPLS management purposes. It is assumed that AGN1x has required IP/MPLS
configuration for network-side connectivity in line with Seamless configuration for network-side connectivity in line with Seamless
MPLS design [I-D.ietf-mpls-seamless-mpls]. MPLS design [I-D.ietf-mpls-seamless-mpls].
skipping to change at page 12, line 31 skipping to change at page 11, line 27
towards AGN1x. towards AGN1x.
Upstream AN/AGN1x should request labels over LDP DoD session(s) from Upstream AN/AGN1x should request labels over LDP DoD session(s) from
downstream AN/AGN1x for configured static routes if those static downstream AN/AGN1x for configured static routes if those static
routes are configured with LDP DoD request policy and if they are routes are configured with LDP DoD request policy and if they are
pointing to a next-hop selected by routing. It is expected that all pointing to a next-hop selected by routing. It is expected that all
configured /32 and /128 static routes to be used for LDP DoD are configured /32 and /128 static routes to be used for LDP DoD are
configured with such policy on AN/AGN1x. configured with such policy on AN/AGN1x.
Downstream AN/AGN1x should respond to the label request from the Downstream AN/AGN1x should respond to the label request from the
upstream AN/AGN1x with a label mapping (if requested route is present upstream AN/AGN1x with a label mapping if requested route is present
in its RIB, and there is a valid label binding from its downstream), in its RIB, and there is a valid label binding from its downstream or
and must install the advertised label as an incoming label in its it is the egress node. In such case downstream AN/AGN1x must install
label table (LIB) and its forwarding table (LFIB). Upstream AN/AGN1x the advertised label as an incoming label in its label table (LIB)
must also install the received label as an outgoing label in their and its forwarding table (LFIB). Upstream AN/AGN1x must also install
LIB and LFIB. If the downstream AN/AGN1x does have the route present the received label as an outgoing label in their LIB and LFIB. If
in its RIB, but does not have a valid label binding from its the downstream AN/AGN1x does have the route present in its RIB, but
downstream, it should forward the request to its downstream. does not have a valid label binding from its downstream, it should
forward the request to its downstream.
In order to facilitate ECMP and IPFRR LFA local-repair, the upstream In order to facilitate ECMP and IPFRR LFA local-repair, the upstream
AN/AGN1x must also send LDP DoD label requests to alternate next-hops AN/AGN1x must also send LDP DoD label requests to alternate next-hops
per its RIB, and install received labels as alternate entries in its per its RIB, and install received labels as alternate entries in its
LIB and LFIB. LIB and LFIB.
AGN1x node on the network side may use BGP labeled unicast [RFC3107] AGN1x node on the network side may use BGP labeled unicast [RFC3107]
in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls].
In such a case AGN1x will be redistributing its static routes In such a case AGN1x will be redistributing its static routes
pointing to local ANs into BGP labeled unicast to facilitate network- pointing to local ANs into BGP labeled unicast to facilitate network-
skipping to change at page 20, line 47 skipping to change at page 19, line 47
LDP protocol specification [RFC5036] defines two modes for label LDP protocol specification [RFC5036] defines two modes for label
distribution control, following the definitions in MPLS architecture distribution control, following the definitions in MPLS architecture
[RFC3031]: [RFC3031]:
o Independent mode - an LSR recognizes a particular FEC and makes a o Independent mode - an LSR recognizes a particular FEC and makes a
decision to bind a label to the FEC independently from decision to bind a label to the FEC independently from
distributing that label binding to its label distribution peers. distributing that label binding to its label distribution peers.
A new FEC is recognized whenever a new route becomes valid on the A new FEC is recognized whenever a new route becomes valid on the
LSR. LSR.
o Ordered mode - an LSR binds a label to a particular FEC if it is o Ordered mode - an LSR needs to bind a label to a particular FEC if
the egress router for that FEC or if it has already received a it knows how to forward packets for that FEC ( i.e. it has a route
label binding for that FEC from its next-hop LSR for that FEC. corresponding to that FEC ) and if it has already received at
least one label request message from an upstream LSR.
Using independent label distribution control with LDP DoD and access Using independent label distribution control with LDP DoD and access
static routing would prevent the access LSRs from propagating label static routing would prevent the access LSRs from propagating label
binding failure along the access topology, making it impossible for binding failure along the access topology, making it impossible for
upstream LSR to be notified about the downstream failure and for an upstream LSR to be notified about the downstream failure and for an
application using the LSP to switchover to an alternate path, even if application using the LSP to switchover to an alternate path, even if
such a path exists. such a path exists.
LDP protocol specification [RFC5036] defines two modes for label LDP protocol specification [RFC5036] defines two modes for label
retention, following the definitions in MPLS architecture [RFC3031]: retention, following the definitions in MPLS architecture [RFC3031]:
skipping to change at page 31, line 48 skipping to change at page 30, line 48
o different crypto keys for use in authentication procedures for o different crypto keys for use in authentication procedures for
these locations. these locations.
o stricter network protection mechanisms including DoS protection, o stricter network protection mechanisms including DoS protection,
interface and session flap dampening. interface and session flap dampening.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, Geraldine Calvignac and Ina Minei for their suggestions and Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin
review. for their suggestions and review.
8. References 8. References
8.1. Normative References 8.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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
skipping to change at page 32, line 25 skipping to change at page 31, line 25
8.2. Informative References 8.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Asati, R., Manral, V., Papneja, R., and C. Pignataro, Asati, R., Manral, V., Papneja, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07
(work in progress), June 2012. (work in progress), June 2012.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-01 (work in progress), draft-ietf-mpls-seamless-mpls-02 (work in progress),
March 2012. October 2012.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
 End of changes. 14 change blocks. 
80 lines changed or deleted 72 lines changed or added

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