draft-ietf-mpls-ldp-dod-08.txt   draft-ietf-mpls-ldp-dod-09.txt 
Network Working Group T. Beckhaus, Ed. Network Working Group T. Beckhaus, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track B. Decraene Intended status: Standards Track B. Decraene
Expires: November 14, 2013 France Telecom Expires: January 14, 2014 Orange
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
May 13, 2013 July 13, 2013
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-08 draft-ietf-mpls-ldp-dod-09
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 10 skipping to change at page 2, line 10
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 November 14, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Topologies . . . . . . . . . . . . . . . . . . . . 4 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . 4
2.1. Access Topologies with Static Routing . . . . . . . . . . 5 2.1. Access Topologies with Static Routing . . . . . . . . . . 5
2.2. Access Topologies with Access IGP . . . . . . . . . . . . 8 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 7
3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 9
3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 10 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 9
3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11
3.2. Service Provisioning and Activation . . . . . . . . . . . 12 3.2. Service Provisioning and Activation . . . . . . . . . . . 11
3.3. Service Changes and Decommissioning . . . . . . . . . . . 15 3.3. Service Changes and Decommissioning . . . . . . . . . . . 14
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 14
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 15
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 15
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 15
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 16
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 18 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 17
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 19 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 18
4.1. LDP Label Distribution Control and Retention Modes . . . 19 4.1. LDP Label Distribution Control and Retention Modes . . . 19
4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21 4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 20
4.3. Label Request Procedures . . . . . . . . . . . . . . . . 22 4.3. Label Request Procedures . . . . . . . . . . . . . . . . 21
4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 22 4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 21
4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 22
4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23 4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23
4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 25 4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 24
4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 25 4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 24
5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 25 5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 27 6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . 28 7.1. LDP DoD Native Security Properties . . . . . . . . . . . 27
7.1.1. Access to network packet flow direction . . . . . . . 28 7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 28
7.1.2. Network to access packet flow direction . . . . . . . 28 7.3. Control Plane Security . . . . . . . . . . . . . . . . . 29
7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Control Plane Security . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.4. Network Node Security . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 32
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.
skipping to change at page 10, line 29 skipping to change at page 9, line 36
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].
LDP DoD procedures follow the LDP specification [RFC5036], and are LDP DoD procedures follow the LDP specification [RFC5036], and are
equally applicable to LDP IPv4 and IPv6 address families. For equally applicable to LDP IPv4 and IPv6 address families. For
simplicity examples are provided for LDP IPv4 address family only. simplicity examples are provided for LDP IPv4 address family only.
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 can 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].
LDP sessions are configured between adjacent ANs and AGN1x using LDP sessions are configured between adjacent ANs and AGN1x using
their respective loopback addresses. their respective loopback addresses.
3.1.1. AN with Static Routing 3.1.1. AN with Static Routing
If access static routing is used, ANs are provisioned with the If access static routing is used, ANs are provisioned with the
following static IP routing entries (topology references from following static IP routing entries (topology references from
Section 2 are listed in square brackets): Section 2 are listed in square brackets):
a. [I1, V, U2] - Static default route 0/0 pointing to links a. [I1, V, U2] - Static default route 0/0 pointing to links
connected to AGN1x. Requires support for Inter-area LDP connected to AGN1x. Requires support for Inter-area LDP
[RFC5283]. [RFC5283].
b. [U2] - Static /32 routes pointing to the other AN. Lower b. [U2] - Static /32 routes pointing to the other AN. Lower
preference static default route 0/0 pointing to links connected preference static default route 0/0 pointing to links connected
to the other AN. Requires support for Inter-area LDP [RFC5283]. to the other AN. Requires support for Inter-area LDP [RFC5283].
c. [I, Y] - Static default route 0/0 pointing to links leading c. [I, Y] - Static default route 0/0 pointing to links leading
towards AGN1x. Requires support for Inter-area LDP [RFC5283]. towards AGN1x. Requires support for Inter-area LDP [RFC5283].
d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing
to links towards those ANs. to links towards those ANs.
e. [I1, V, U2] - Optional - Static /32 routes for specific nodes e. [I1, V, U2] - Optional - Static /32 routes for specific nodes
within Seamless MPLS network, pointing to links connected to within Seamless MPLS network, pointing to links connected to
AGN1x. AGN1x.
f. [I, Y] - Optional - Static /32 routes for specific nodes within f. [I, Y] - Optional - Static /32 routes for specific nodes within
the Seamless MPLS network, pointing to links leading towards the Seamless MPLS network, pointing to links leading towards
AGN1x. AGN1x.
Upstream AN/AGN1x should request labels over LDP DoD session(s) from Upstream AN/AGN1x requests 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 static routes to be used for LDP DoD are configured configured /32 static routes to be used for LDP DoD are configured
with such policy on AN/AGN1x. with such policy on AN/AGN1x.
Downstream AN/AGN1x should respond to the Label Request from the Downstream AN/AGN1x responds to the Label Request from the upstream
upstream AN/AGN1x with a Label Mapping if requested route is present AN/AGN1x with a Label Mapping if requested route is present in its
in its RIB, and there is a valid label binding from its downstream or RIB, and there is a valid label binding from its downstream or it is
it is the egress node. In such case downstream AN/AGN1x must install the egress node. In such case downstream AN/AGN1x installs the
the advertised label as an incoming label in its label table (LIB) advertised label as an incoming label in its label table (LIB) and
and its forwarding table (LFIB). Upstream AN/AGN1x must also install its forwarding table (LFIB). Upstream AN/AGN1x also installs the
the received label as an outgoing label in their LIB and LFIB. If received label as an outgoing label in their LIB and LFIB. If the
the downstream AN/AGN1x does have the route present in its RIB, but downstream AN/AGN1x does have the route present in its RIB, but does
does not have a valid label binding from its downstream, it should not have a valid label binding from its downstream, it forwards the
forward the request to its downstream. 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 also sends LDP DoD label requests to alternate next-hops per
per its RIB, and install received labels as alternate entries in its its RIB, and install received labels as alternate entries in its LIB
LIB and LFIB. and LFIB.
AGN1x node on the network side may use BGP labeled unicast [RFC3107] AGN1x node on the network side can 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-
to-access traffic flows. Likewise, to facilitate access-to-network to-access traffic flows. Likewise, to facilitate access-to-network
traffic flows, AGN1x will be responding to access-originated LDP DoD traffic flows, AGN1x will be responding to access-originated LDP DoD
label requests with label mappings based on its BGP labeled unicast label requests with label mappings based on its BGP labeled unicast
reachability for requested FECs. reachability for requested FECs.
3.1.2. AN with Access IGP 3.1.2. AN with Access IGP
If access IGP is used, AN(s) advertise their loopbacks over the If access IGP is used, AN(s) advertise their loopbacks over the
access IGP with configured metrics. AGN1x advertise a default route access IGP with configured metrics. AGN1x advertise a default route
over the access IGP. over the access IGP.
Routers request labels over LDP DoD session(s) according to their Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per needs for MPLS connectivity (LSPs). In particular if AGNs, as per
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute
routes from the IGP into BGP labeled unicast [RFC3107], they should routes from the IGP into BGP labeled unicast [RFC3107], they request
request labels over LDP DoD session(s) for those routes. labels over LDP DoD session(s) for those routes.
Identically to the static route case, downstream AN/AGN1x should Identically to the static route case, downstream AN/AGN1x responds to
respond to the Label Request from the upstream AN/AGN1x with a Label the Label Request from the upstream AN/AGN1x with a Label Mapping (if
Mapping (if the requested route is present in its RIB, and there is a the requested route is present in its RIB, and there is a valid label
valid label binding from its downstream), and must install the binding from its downstream), and installs the advertised label as an
advertised label as an incoming label in its LIB and LFIB. Upstream incoming label in its LIB and LFIB. Upstream AN/AGN1x also installs
AN/AGN1x must also install the received label as an outgoing label in the received label as an outgoing label in their LIB and LFIB.
their LIB and LFIB.
Identically to the static route case, in order to facilitate ECMP and Identically to the static route case, in order to facilitate ECMP and
IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD IPFRR LFA local-repair, upstream AN/AGN1x also sends LDP DoD label
label requests to alternate next-hops per its RIB, and install requests to alternate next-hops per its RIB, and installs received
received labels as alternate entries in its LIB and LFIB. labels as alternate entries in its LIB and LFIB.
AGN1x node on the network side may use BGP labeled unicast [RFC3107] AGN1x node on the network side can use BGP labeled unicast [RFC3107]
in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In
such case AGN1x will be redistributing routes received over the such case AGN1x will be redistributing routes received over the
access IGP (and pointing to local ANs), into BGP labeled unicast to access IGP (and pointing to local ANs), into BGP labeled unicast to
facilitate network-to-access traffic flows. Likewise, to facilitate facilitate network-to-access traffic flows. Likewise, to facilitate
access-to-network traffic flows AGN1x will be responding to access access-to-network traffic flows AGN1x will be responding to access
originated LDP DoD label requests with label mappings based on its originated LDP DoD label requests with label mappings based on its
BGP labeled unicast reachability for requested FECs. BGP labeled unicast reachability for requested FECs.
3.2. Service Provisioning and Activation 3.2. Service Provisioning and Activation
skipping to change at page 13, line 24 skipping to change at page 12, line 32
instance. instance.
c. Local and remote PWE3 labels for specific FEC128 PW ID need to be c. Local and remote PWE3 labels for specific FEC128 PW ID need to be
signaled using targeted LDP and PWE3 signaling procedures signaled using targeted LDP and PWE3 signaling procedures
[RFC4447]. [RFC4447].
d. Upon successful completion of the above operations, AN* programs d. Upon successful completion of the above operations, AN* programs
its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service.
Note - only minimum operations applicable to service connectivity Note - only minimum operations applicable to service connectivity
have been listed. Other non IP/MPLS connectivity operations that may have been listed. Other non IP/MPLS connectivity operations that are
be required for successful service provisioning and activation are required for successful service provisioning and activation are out
out of scope in this document. of scope in this document.
BGP/MPLS IPVPN service - for description simplicity it is assumed BGP/MPLS IPVPN service - for description simplicity it is assumed
that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for
short) [RFC4364]. The following IP/MPLS operations need to be short) [RFC4364]. The following IP/MPLS operations need to be
completed on the AN* to successfully establish VPNv4 service: completed on the AN* to successfully establish VPNv4 service:
a. BGP peering sessions with associated TCP/IP connections need to a. BGP peering sessions with associated TCP/IP connections need to
be established with the remote destination VPNv4 PEs or Route be established with the remote destination VPNv4 PEs or Route
Reflectors. Reflectors.
skipping to change at page 14, line 6 skipping to change at page 13, line 14
d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) d. LSP labels for destination BGP next-hop /32 FEC (outgoing label)
and the local /32 loopback (incoming label) need to be signaled and the local /32 loopback (incoming label) need to be signaled
using LDP DoD. using LDP DoD.
e. Upon successful completion of above operations, AN* programs its e. Upon successful completion of above operations, AN* programs its
RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN
service. service.
Note - only minimum operations applicable to service connectivity Note - only minimum operations applicable to service connectivity
have been listed. Other non IP/MPLS connectivity operations that may have been listed. Other non IP/MPLS connectivity operations that are
be required for successful service provisioning are out of scope in required for successful service provisioning are out of scope in this
this document. document.
To establish an LSP for destination /32 FEC for any of the above To establish an LSP for destination /32 FEC for any of the above
services, AN* looks up its local routing table for a matching route, services, AN* looks up its local routing table for a matching route,
selects the best next-hop(s) and associated outgoing link(s). selects the best next-hop(s) and associated outgoing link(s).
If a label for this /32 FEC is not already installed based on the If a label for this /32 FEC is not already installed based on the
configured static route with LDP DoD request policy or access IGP RIB configured static route with LDP DoD request policy or access IGP RIB
entry, AN* must send an LDP DoD Label Mapping request. Downstream AN entry, AN* sends an LDP DoD Label Mapping request. Downstream AN/
/AGN1x LSR(s) checks its RIB for presence of the requested /32 and AGN1x LSR(s) checks its RIB for presence of the requested /32 and
associated valid outgoing label binding, and if both are present, associated valid outgoing label binding, and if both are present,
replies with its label for this FEC and installs this label as replies with its label for this FEC and installs this label as
incoming in its LIB and LFIB. Upon receiving the Label Mapping the incoming in its LIB and LFIB. Upon receiving the Label Mapping the
AN* must accept this label based on the exact route match of AN* accepts this label based on the exact route match of advertised
advertised FEC and route entry in its RIB or based on the longest FEC and route entry in its RIB or based on the longest match in line
match in line with Inter-area LDP [RFC5283]. If the AN* accepts the with Inter-area LDP [RFC5283]. If the AN* accepts the label it
label it must install it as an outgoing label in its LIB and LFIB. installs it as an outgoing label in its LIB and LFIB.
In access topologies [V] and [Y], if AN* is dual homed to two AGN1x In access topologies [V] and [Y], if AN* is dual homed to two AGN1x
and routing entries for these AGN1x are configured as equal cost and routing entries for these AGN1x are configured as equal cost
paths, AN* must send LDP DoD label requests to both AGN1x devices and paths, AN* sends LDP DoD label requests to both AGN1x devices and
install all received labels in its LIB and LFIB. install all received labels in its LIB and LFIB.
In order for AN* to implement IPFRR LFA local-repair, AN* must also In order for AN* to implement IPFRR LFA local-repair, AN* also sends
send LDP DoD label requests to alternate next-hops per its RIB, and LDP DoD label requests to alternate next-hops per its RIB, and
install received labels as alternate entries in its LIB and LFIB. install received labels as alternate entries in its LIB and LFIB.
When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based
on the locally configured static /32 or default route, or default on the locally configured static /32 or default route, or default
route signaled via access IGP. If a route is reachable via multiple route signaled via access IGP. If a route is reachable via multiple
interfaces to AGN1x nodes and the route has multiple equal cost interfaces to AGN1x nodes and the route has multiple equal cost
paths, AN* must implement Equal Cost Multi-Path (ECMP) functionality. paths, AN* implements Equal Cost Multi-Path (ECMP) functionality.
This involves AN* using hash-based load-balancing mechanism and This involves AN* using hash-based load-balancing mechanism and
sending the PWE3 or VPNv4 packets in a flow-aware manner with sending the PWE3 or VPNv4 packets in a flow-aware manner with
appropriate LSP labels via all equal cost links. appropriate LSP labels via all equal cost links.
ECMP mechanism is applicable in an equal manner to parallel links ECMP mechanism is applicable in an equal manner to parallel links
between two network elements and multiple paths towards the between two network elements and multiple paths towards the
destination. The traffic demand is distributed over the available destination. The traffic demand is distributed over the available
paths. paths.
AGN1x node on the network side may use BGP labeled unicast [RFC3107] AGN1x node on the network side can use BGP labeled unicast [RFC3107]
in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In
such case AGN1x will be redistributing its static routes (or routes such case AGN1x will be redistributing its static routes (or routes
received from the access IGP) pointing to local ANs into BGP labeled received from the access IGP) pointing to local ANs into BGP labeled
unicast to facilitate network-to-access traffic flows. Likewise, to unicast to facilitate network-to-access traffic flows. Likewise, to
facilitate access-to-network traffic flows AGN1x will be responding facilitate access-to-network traffic flows AGN1x will be responding
to access originated LDP DoD label requests with label mappings based to access originated LDP DoD label requests with label mappings based
on its BGP labeled unicast reachability for requested FECs. on its BGP labeled unicast reachability for requested FECs.
3.3. Service Changes and Decommissioning 3.3. Service Changes and Decommissioning
Whenever AN* service gets decommissioned or changed and connectivity Whenever AN* service gets decommissioned or changed and connectivity
to specific destination is not longer required, the associated MPLS to specific destination is not longer required, the associated MPLS
LSP label resources should be released on AN*. LSP label resources are to be released on AN*.
MPLS PWE3 service - if the PWE3 service gets decommissioned and it is MPLS PWE3 service - if the PWE3 service gets decommissioned and it is
the last PWE3 to a specific destination node, the targeted LDP the last PWE3 to a specific destination node, the targeted LDP
session is not longer needed and should be terminated (automatically session is not longer needed and is to be terminated (automatically
or by configuration). The MPLS LSP(s) to that destination is no or by configuration). The MPLS LSP(s) to that destination is no
longer needed either. longer needed either.
BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance,
local or remote re-configuration may result in specific BGP next- local or remote re-configuration can result in specific BGP next-
hop(s) being no longer needed. The MPLS LSP(s) to that destination hop(s) being no longer needed. The MPLS LSP(s) to that destination
is no longer needed either. is no longer needed either.
In all of the above cases the following LDP DoD related operations In all of the above cases the following LDP DoD related operations
apply: apply:
o If the /32 FEC label for the aforementioned destination node was o If the /32 FEC label for the aforementioned destination node was
originally requested based on either tLDP session configuration originally requested based on either tLDP session configuration
and default route or required BGP next-hop and default route, AN* and default route or required BGP next-hop and default route, AN*
should delete the label from its LIB and LFIB, and release it from deletes the label from its LIB and LFIB, and release it from
downstream AN/AGN1x by using LDP DoD procedures. downstream AN/AGN1x by using LDP DoD procedures.
o If the /32 FEC label was originally requested based on the static o If the /32 FEC label was originally requested based on the static
/32 route configuration with LDP DoD request policy, the label /32 route configuration with LDP DoD request policy, the label is
must be retained by AN*. retained by AN*.
3.4. Service Failure 3.4. Service Failure
A service instance may stop being operational due to a local or A service instance can stop being operational due to a local or
remote service failure event. remote service failure event.
In general, unless the service failure event modifies required MPLS In general, unless the service failure event modifies required MPLS
connectivity, there should be no impact on the LDP DoD operation. connectivity, there is no impact on the LDP DoD operation.
If the service failure event does modify the required MPLS If the service failure event does modify the required MPLS
connectivity, LDP DoD operations apply as described in Section 3.2 connectivity, LDP DoD operations apply as described in Section 3.2
and Section 3.3. and Section 3.3.
3.5. Network Transport Failure 3.5. Network Transport Failure
A number of different network events can impact services on AN*. The A number of different network events can impact services on AN*. The
following sections describe network event types that impact LDP DoD following sections describe network event types that impact LDP DoD
operation on AN and AGN1x nodes. operation on AN and AGN1x nodes.
3.5.1. General Notes 3.5.1. General Notes
If service on any of the ANs is affected by any network failure and If service on any of the ANs is affected by any network failure and
there is no network redundancy, the service must go into a failure there is no network redundancy, the service goes into a failure
state. When the network failure is recovered from, the service must state. When the network failure is recovered from, the service is to
be re-established automatically. be re-established automatically.
The following additional LDP-related functions should be supported to The following additional LDP-related functions need to be supported
comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast service to comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast
restoration requirements as follows: service restoration requirements as follows:
a. Local-repair - AN and AGN1x should support local-repair for a. Local-repair - AN and AGN1x support local-repair for adjacent
adjacent link or node failure for access-to-network, network-to- link or node failure for access-to-network, network-to-access and
access and access-to-access traffic flows. Local-repair should access-to-access traffic flows. Local-repair is to be
be implemented by using either IPFRR LDP LFA, simple ECMP or implemented by using either IPFRR LDP LFA, simple ECMP or primary
primary/backup switchover upon failure detection. /backup switchover upon failure detection.
b. LDP session protection - LDP sessions should be configured with b. LDP session protection - LDP sessions are configured with LDP
LDP session protection to avoid delay upon the recovery from link session protection to avoid delay upon the recovery from link
failure. LDP session protection ensures that FEC label binding failure. LDP session protection ensures that FEC label binding
is maintained in the control plane as long as LDP session stays is maintained in the control plane as long as LDP session stays
up. up.
c. IGP-LDP synchronization - If access IGP is used, LDP sessions c. IGP-LDP synchronization - If access IGP is used, LDP sessions
between ANs, and between ANs and AGN1x, should be configured with between ANs, and between ANs and AGN1x, are configured with IGP-
IGP-LDP synchronization to avoid unnecessary traffic loss in case LDP synchronization to avoid unnecessary traffic loss in case the
the access IGP converged before LDP and there is no LDP label access IGP converged before LDP and there is no LDP label binding
binding to the downstream best next-hop. to the downstream best next-hop.
3.5.2. AN Node Failure 3.5.2. AN Node Failure
AN node fails and all links to adjacent nodes go down. AN node fails and all links to adjacent nodes go down.
Adjacent AN/AGN1x nodes remove all routes pointing to the failed Adjacent AN/AGN1x nodes remove all routes pointing to the failed
link(s) from their RIB tables (including /32 loopback belonging to link(s) from their RIB tables (including /32 loopback belonging to
the failed AN and any other routes reachable via the failed AN). the failed AN and any other routes reachable via the failed AN).
This in turn triggers the removal of associated outgoing /32 FEC This in turn triggers the removal of associated outgoing /32 FEC
labels from their LIB and LFIB tables. labels from their LIB and LFIB tables.
If access IGP is used, the AN node failure will be propagated via IGP If access IGP is used, the AN node failure will be propagated via IGP
link updates across the access topology. link updates across the access topology.
If a specific /32 FEC(s) is not reachable anymore from those AN/ If a specific /32 FEC(s) is not reachable anymore from those AN/
AGN1x, they must also send LDP Label Withdraw to their upstream LSRs AGN1x, they also send LDP Label Withdraw to their upstream LSRs to
to notify about the failure, and remove the associated incoming notify about the failure, and remove the associated incoming label(s)
label(s) from their LIB and LFIB tables. Upstream LSRs upon from their LIB and LFIB tables. Upstream LSRs upon receiving Label
receiving Label Withdraw should remove the signaled labels from their Withdraw remove the signaled labels from their LIB/LFIB tables, and
LIB/LFIB tables, and propagate LDP Label Withdraw across their propagate LDP Label Withdraw across their upstream LDP DoD sessions.
upstream LDP DoD sessions.
In [U] topology there may be an alternative path to routes previously In [U] topology there may be an alternative path to routes previously
reachable via the failed AN node. In this case adjacent AN/AGN1x reachable via the failed AN node. In this case adjacent AN/AGN1x
should invoke local-repair (IPFRR LFA, ECMP) and switchover to invoke local-repair (IPFRR LFA, ECMP) and switchover to alternate
alternate next-hop to reach those routes. next-hop to reach those routes.
AGN1x gets notified about the AN failure via either access IGP (if AGN1x gets notified about the AN failure via either access IGP (if
used) and/or cascaded LDP DoD label withdraw(s). AGN1x must used) and/or cascaded LDP DoD label withdraw(s). AGN1x implements
implement all relevant global-repair IP/MPLS procedures to propagate all relevant global-repair IP/MPLS procedures to propagate the AN
the AN failure towards the core network. This should involve failure towards the core network. This involves removing associated
removing associated routes (in access IGP case) and labels from its routes (in access IGP case) and labels from its LIB and LFIB tables,
LIB and LFIB tables, and propagating the failure on the network side and propagating the failure on the network side using BGP-LU and/or
using BGP-LU and/or core IGP/LDP-DU procedures. core IGP/LDP-DU procedures.
Upon AN coming back up, adjacent AN/AGN1x nodes automatically add Upon AN coming back up, adjacent AN/AGN1x nodes automatically add
routes pointing to recovered links based on the configured static routes pointing to recovered links based on the configured static
routes or access IGP adjacency and link state updates. This should routes or access IGP adjacency and link state updates. This is then
be then followed by LDP DoD label signaling and subsequent binding followed by LDP DoD label signaling and subsequent binding and
and installation of labels in LIB and LFIB tables. installation of labels in LIB and LFIB tables.
3.5.3. AN/AGN Link Failure 3.5.3. AN/AGN Link Failure
Depending on the access topology and the failed link location Depending on the access topology and the failed link location
different cases apply to the network operation after AN link failure different cases apply to the network operation after AN link failure
(topology references from Section 2 in square brackets): (topology references from Section 2 in square brackets):
a. [all] - link failed, but at least one ECMP parallel link remains a. [all] - link failed, but at least one ECMP parallel link remains
- nodes on both sides of the failed link must stop using the - nodes on both sides of the failed link stop using the failed
failed link immediately (local-repair), and keep using the link immediately (local-repair), and keep using the remaining
remaining ECMP parallel links. ECMP parallel links.
b. [I1, I, Y] - link failed, and there are no ECMP or alternative b. [I1, I, Y] - link failed, and there are no ECMP or alternative
links and paths - nodes on both sides of the failed link must links and paths - nodes on both sides of the failed link remove
remove routes pointing to the failed link immediately from the routes pointing to the failed link immediately from the RIB,
RIB, remove associated labels from their LIB and LFIB tabels, and remove associated labels from their LIB and LFIB tabels, and send
must send LDP label withdraw(s) to their upstream LSRs. LDP label withdraw(s) to their upstream LSRs.
c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate
path remains - AN/AGN1x node must stop using the failed link and path remains - AN/AGN1x node stops using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switchover (local-repair) to the remaining ECMP path
or alternate path. AN/AGN1x must remove affected next-hops and or alternate path. AN/AGN1x removes affected next-hops and
labels from its tables and invoke LDP Label Withdraw as per point labels from its tables and invoke LDP Label Withdraw as per point
(a) above. If there is an AGN1x node terminating the failed (a) above. If there is an AGN1x node terminating the failed
link, it must remove routes pointing to the failed link link, it removes routes pointing to the failed link immediately
immediately from the RIB, remove associated labels from their LIB from the RIB, remove associated labels from their LIB and LFIB
and LFIB tabels, and must propagate the failure on the network tabels, and propagate the failure on the network side using BGP-
side using BGP-LU and/or core IGP procedures. LU and/or core IGP procedures.
If access IGP is used AN/AGN1x link failure will be propagated via If access IGP is used AN/AGN1x link failure will be propagated via
IGP link updates across the access topology. IGP link updates across the access topology.
LDP DoD will also propagate the link failure by sending label LDP DoD will also propagate the link failure by sending label
withdraws to upstream AN/AGN1x nodes, and Label Release messages withdraws to upstream AN/AGN1x nodes, and Label Release messages
downstream AN/AGN1x nodes. downstream AN/AGN1x nodes.
3.5.4. AGN Node Failure 3.5.4. AGN Node Failure
AGN1x fails and all links to adjacent access nodes go down. AGN1x fails and all links to adjacent access nodes go down.
Depending on the access topology, following cases apply to the Depending on the access topology, following cases apply to the
network operation after AGN1x node failure (topology references from network operation after AGN1x node failure (topology references from
Section 2 in square brackets): Section 2 in square brackets):
a. [I1, I] - ANs are isolated from the network - AN adjacent to the a. [I1, I] - ANs are isolated from the network - AN adjacent to the
failure must remove routes pointing to the failed AGN1x node failure removes routes pointing to the failed AGN1x node
immediately from the RIB, remove associated labels from their LIB immediately from the RIB, removes associated labels from their
and LFIB tabels, and must send LDP label withdraw(s) to their LIB and LFIB tabels, and sends LDP label withdraw(s) to their
upstream LSRs. If access IGP is used, an IGP link update should upstream LSRs. If access IGP is used, an IGP link update is
be sent. sent.
b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN
adjacent to failed AGN1x must stop using the failed link and adjacent to failed AGN1x stops using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switchover (local-repair) to the remaining ECMP path
or alternate path. AN must remove affected routes and labels or alternate path. AN removes affected routes and labels from
from its tables and invoke LDP Label Withdraw as per point (a) its tables and invoke LDP Label Withdraw as per point (a) above.
above.
Network side procedures for handling AGN1x node failure have been Network side procedures for handling AGN1x node failure have been
described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls].
3.5.5. AGN Network-side Reachability Failure 3.5.5. AGN Network-side Reachability Failure
AGN1x loses network reachability to a specific destination or set of AGN1x loses network reachability to a specific destination or set of
network-side destinations. network-side destinations.
In such event AGN1x must send LDP Label Withdraw messages to its In such event AGN1x sends LDP Label Withdraw messages to its upstream
upstream ANs, withdrawing labels for all affected /32 FECs. Upon ANs, withdrawing labels for all affected /32 FECs. Upon receiving
receiving those messages ANs must remove those labels from their LIB those messages ANs remove those labels from their LIB and LFIB
and LFIB tables, and use alternative LSPs instead if available as tables, and use alternative LSPs instead if available as part of
part of global-repair. In turn ANs should also sent Label Withdraw global-repair. In turn ANs also send Label Withdraw messages for
messages for affected /32 FECs to their upstream ANs. affected /32 FECs to their upstream ANs.
If access IGP is used, and AGN1x gets completely isolated from the If access IGP is used, and AGN1x gets completely isolated from the
core network, it should stop advertising the default route 0/0 into core network, it stops advertising the default route 0/0 into the
the access IGP. access IGP.
4. LDP DoD Procedures 4. LDP DoD Procedures
Label Distribution Protocol is specified in [RFC5036], and all LDP Label Distribution Protocol is specified in [RFC5036], and all LDP
Downstream-on-Demand implementations follow [RFC5036] specification. Downstream-on-Demand implementations follow [RFC5036] specification.
This section does not update [RFC5036] procedures, but illustrates This section does not update [RFC5036] procedures, but illustrates
LDP DoD operations in the context of use cases identified in LDP DoD operations in the context of use cases identified in
Section 3 in this document, for information only. Section 3 in this document, for information only.
In the MPLS architecture [RFC3031], network traffic flows from In the MPLS architecture [RFC3031], network traffic flows from
skipping to change at page 19, line 51 skipping to change at page 19, line 18
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 needs to bind a label to a particular FEC if o Ordered mode - an LSR needs to bind a label to a particular FEC if
it knows how to forward packets for that FEC ( i.e. it has a it knows how to forward packets for that FEC ( i.e. it has a route
route corresponding to that FEC ) and if it has already received corresponding to that FEC ) and if it has already received at
at least one Label Request message from an upstream LSR. 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 21, line 32 skipping to change at page 20, line 41
In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an
access ABR connecting access and metro domains. To enable failure access ABR connecting access and metro domains. To enable failure
propagation between those domains, access ABR implements ordered propagation between those domains, access ABR implements ordered
label distribution control when redistributing routes/FEC between the label distribution control when redistributing routes/FEC between the
access-side (using LDP DoD and static or access IGP) and the network- access-side (using LDP DoD and static or access IGP) and the network-
side ( using BGP labeled unicast [RFC3107] or core IGP with LDP side ( using BGP labeled unicast [RFC3107] or core IGP with LDP
Downstream Unsolicited label advertisement. Downstream Unsolicited label advertisement.
4.2. LDP DoD Session Negotiation 4.2. LDP DoD Session Negotiation
Access LSR/ABR should propose the Downstream-on-Demand label Access LSR/ABR propose the Downstream-on-Demand label advertisement
advertisement by setting "A" value to 1 in the Common Session by setting "A" value to 1 in the Common Session Parameters TLV of the
Parameters TLV of the Initialization message. The rules for Initialization message. The rules for negotiating the label
negotiating the label advertisement mode are specified in LDP advertisement mode are specified in LDP protocol specification
protocol specification [RFC5036]. [RFC5036].
To establish a Downstream-on-Demand session between the two access To establish a Downstream-on-Demand session between the two access
LSR/ABRs, both should propose the Downstream-on-Demand label LSR/ABRs, both propose the Downstream-on-Demand label advertisement
advertisement mode in the Initialization message. If the access LSR mode in the Initialization message. If the access LSR only supports
only supports LDP DoD and the access ABR proposes Downstream LDP DoD and the access ABR proposes Downstream Unsolicited mode, the
Unsolicited mode, the access LSR should send a Notification message access LSR sends a Notification message with status "Session Rejected
with status "Session Rejected/Parameters Advertisement Mode" and then /Parameters Advertisement Mode" and then close the LDP session as
close the LDP session as specified in LDP protocol specification specified in LDP protocol specification [RFC5036].
[RFC5036].
If an access LSR is acting in an active role, it should re-attempt If an access LSR is acting in an active role, it re-attempts the LDP
the LDP session immediately. If the access LSR receives the same session immediately. If the access LSR receives the same Downstream
Downstream Unsolicited mode again, it should follow the exponential Unsolicited mode again, it follows the exponential backoff algorithm
backoff algorithm as defined in the LDP protocol specification as defined in the LDP protocol specification [RFC5036] with delay of
[RFC5036] with delay of 15 seconds and subsequent delays growing to a 15 seconds and subsequent delays growing to a maximum delay of 2
maximum delay of 2 minutes. minutes.
In case a PWE3 service is required between the adjacent access LSR/ In case a PWE3 service is required between the adjacent access LSR/
ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same
LDP session should be used for PWE3 FECs. Even if LDP DoD label LDP session is used for PWE3 FECs. Even if LDP DoD label
advertisement has been negotiated for IPv4 and IPv6 LDP FECs as advertisement has been negotiated for IPv4 and IPv6 LDP FECs as
described earlier, LDP session should use Downstream Unsolicited described earlier, LDP session uses Downstream Unsolicited label
label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447].
4.3. Label Request Procedures 4.3. Label Request Procedures
4.3.1. Access LSR/ABR Label Request 4.3.1. Access LSR/ABR Label Request
Upstream access LSR/ABR will request label bindings from adjacent Upstream access LSR/ABR will request label bindings from adjacent
downstream access LSR/ABR based on the following trigger events: downstream access LSR/ABR based on the following trigger events:
a. Access LSR/ABR is configured with /32 static route with LDP DoD a. Access LSR/ABR is configured with /32 static route with LDP DoD
Label Request policy in line with initial network setup use case Label Request policy in line with initial network setup use case
described in Section 3.1. described in Section 3.1.
b. Access LSR/ABR is configured with a service in line with service b. Access LSR/ABR is configured with a service in line with service
use cases described in Section 3.2 and Section 3.3. use cases described in Section 3.2 and Section 3.3.
c. Configuration with access static routes - Access LSR/ABR link to c. Configuration with access static routes - Access LSR/ABR link to
adjacent node comes up and LDP DoD session is established. In adjacent node comes up and LDP DoD session is established. In
this case access LSR should send Label Request messages for all / this case access LSR sends Label Request messages for all /32
32 static routes configured with LDP DoD policy and all /32 static routes configured with LDP DoD policy and all /32 routes
routes related to provisioned services that are covered by related to provisioned services that are covered by default
default route. route.
d. Configuration with access IGP - Access LSR/ABR link to adjacent d. Configuration with access IGP - Access LSR/ABR link to adjacent
node comes up and LDP DoD session is established. In this case node comes up and LDP DoD session is established. In this case
access LSR should send Label Request messages for all /32 routes access LSR sends Label Request messages for all /32 routes
learned over the access IGP and all /32 routes related to learned over the access IGP and all /32 routes related to
provisioned services that are covered by access IGP routes. provisioned services that are covered by access IGP routes.
e. In all above cases requests must be sent to next-hop LSR(s) and e. In all above cases requests are sent to next-hop LSR(s) and
alternate LSR(s). alternate LSR(s).
Downstream access LSR/ABR will respond with Label Mapping message Downstream access LSR/ABR will respond with Label Mapping message
with a non-null label if any of the below conditions are met: with a non-null label if any of the below conditions are met:
a. Downstream access LSR/ABR - requested FEC is an IGP or static a. Downstream access LSR/ABR - requested FEC is an IGP or static
route and there is an LDP label already learnt from the next- route and there is an LDP label already learnt from the next-
next-hop downstream LSR (by LDP DoD or LDP DU). If there is no next-hop downstream LSR (by LDP DoD or LDP DU). If there is no
label for the requested FEC and there is an LDP DoD session to label for the requested FEC and there is an LDP DoD session to
the next-next-hop downstream LSR, downstream LSR must send a the next-next-hop downstream LSR, downstream LSR sends a Label
Label Request message for the same FEC to the next-next-hop Request message for the same FEC to the next-next-hop downstream
downstream LSR. In such case downstream LSR will respond back to LSR. In such case downstream LSR will respond back to the
the requesting upstream access LSR only after getting a label requesting upstream access LSR only after getting a label from
from the next-next-hop downstream LSR peer. the next-next-hop downstream LSR peer.
b. Downstream access ABR only - requested FEC is a BGP labelled b. Downstream access ABR only - requested FEC is a BGP labelled
unicast route [RFC3107] and this BGP route is the best selected unicast route [RFC3107] and this BGP route is the best selected
for this FEC. for this FEC.
Downstream access LSR/ABR may respond with a Label Mapping with Downstream access LSR/ABR can respond with a Label Mapping with
explicit-null or implicit-null label if it is acting as an egress for explicit-null or implicit-null label if it is acting as an egress for
the requested FEC, or it may respond with "No Route" notification if the requested FEC, or it can respond with "No Route" notification if
no route exists. no route exists.
4.3.2. Label Request Retry 4.3.2. Label Request Retry
Following LDP specification LDP specification [RFC5036], if an access Following LDP specification LDP specification [RFC5036], if an access
LSR/ABR receives a "No route" Notification in response to its Label LSR/ABR receives a "No route" Notification in response to its Label
Request message, it should retry using an exponential backoff Request message, it retries using an exponential backoff algorithm
algorithm similar to the backoff algoritm mentioned in the LDP similar to the backoff algoritm mentioned in the LDP session
session negotiation described in Section 4.2. negotiation described in Section 4.2.
If there is no response to the sent Label Request message, the LDP If there is no response to the sent Label Request message, the LDP
specification [RFC5036] (section A.1.1, page# 100) states that the specification [RFC5036] (section A.1.1, page# 100) states that the
LSR should not send another request for the same label to the peer LSR does not send another request for the same label to the peer and
and mandates that a duplicate Label Request is considered a protocol mandates that a duplicate Label Request is considered a protocol
error and should be dropped by the receiving LSR by sending a error and is dropped by the receiving LSR by sending a Notification
Notification message. message.
Thus, if there is no response from the downstream peer, the access Thus, if there is no response from the downstream peer, the access
LSR/ABR should not send a duplicate Label Request message again. LSR/ABR does not send a duplicate Label Request message again.
If the static route corresponding to the FEC gets deleted or if the If the static route corresponding to the FEC gets deleted or if the
DoD request policy is modified to reject the FEC before receiving the DoD request policy is modified to reject the FEC before receiving the
Label Mapping message, then the access LSR/ABR should send a Label Label Mapping message, then the access LSR/ABR sends a Label Abort
Abort message to the downstream LSR. message to the downstream LSR.
To address the case of slower convergence resulting from described To address the case of slower convergence resulting from described
LDP behavior in line with LDP specification [RFC5036], a new LDP TLV LDP behavior in line with LDP specification [RFC5036], a new LDP TLV
extension is proposed and described in Section 5. extension is proposed and described in Section 5.
4.4. Label Withdraw 4.4. Label Withdraw
If an MPLS label on the downstream access LSR/ABR is no longer valid, If an MPLS label on the downstream access LSR/ABR is no longer valid,
the downstream access LSR/ABR withdraws this FEC/label binding from the downstream access LSR/ABR withdraws this FEC/label binding from
the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] the upstream access LSR/ABR with the Label Withdraw Message [RFC5036]
with a specified label TLV or with an empty label TLV. with a specified label TLV or with an empty label TLV.
Downstream access LSR/ABR should withdraw a label for specific FEC in Downstream access LSR/ABR withdraws a label for specific FEC in the
the following cases: following cases:
a. If LDP DoD ingress label is associated with an outgoing label a. If LDP DoD ingress label is associated with an outgoing label
assigned by BGP labelled unicast route, and this route is assigned by BGP labelled unicast route, and this route is
withdrawn. withdrawn.
b. If LDP DoD ingress label is associated with an outgoing label b. If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the IGP route is withdrawn from assigned by LDP (DoD or DU) and the IGP route is withdrawn from
the RIB or downstream LDP session is lost. the RIB or downstream LDP session is lost.
c. If LDP DoD ingress label is associated with an outgoing label c. If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the outgoing label is withdrawn assigned by LDP (DoD or DU) and the outgoing label is withdrawn
by the downstream LSR. by the downstream LSR.
d. If LDP DoD ingress label is associated with an outgoing label d. If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU), route next-hop changed and assigned by LDP (DoD or DU), route next-hop changed and
* there is no LDP session to the new next-hop. To minimize * there is no LDP session to the new next-hop. To minimize
probability of this, the access LSR/ABR should implement LDP- probability of this, the access LSR/ABR implements LDP-IGP
IGP synchronization procedures as specified in [RFC5443]. synchronization procedures as specified in [RFC5443].
* there is an LDP session but no label from downstream LSR. See * there is an LDP session but no label from downstream LSR. See
note below. note below.
e. If access LSR/ABR is configured with a policy to reject exporting e. If access LSR/ABR is configured with a policy to reject exporting
label mappings to upstream LSR. label mappings to upstream LSR.
The upstream access LSR/ABR responds to the Label Withdraw Message The upstream access LSR/ABR responds to the Label Withdraw Message
with the Label Release Message [RFC5036]. with the Label Release Message [RFC5036].
After sending Label Release message to downstream access LSR/ABR, the After sending Label Release message to downstream access LSR/ABR, the
upstream access LSR/ABR should resend Label Request message, assuming upstream access LSR/ABR resends Label Request message, assuming
upstream access LSR/ABR still requires the label. upstream access LSR/ABR still requires the label.
Downstream access LSR/ABR should withdraw a label if the local route Downstream access LSR/ABR withdraws a label if the local route
configuration (e.g. /32 loopback) is deleted. configuration (e.g. /32 loopback) is deleted.
Note: For any events inducing next hop change, downstream access LSR/ Note: For any events inducing next hop change, downstream access LSR/
ABR should attempt to converge the LSP locally before withdrawing the ABR is to attempt to converge the LSP locally before withdrawing the
label from an upstream access LSR/ABR. For example if the next-hop label from an upstream access LSR/ABR. For example if the next-hop
changes for a particular FEC and if the new next-hop allocates labels changes for a particular FEC and if the new next-hop allocates labels
by LDP DoD session, then the downstream access LSR/ABR must send a by LDP DoD session, then the downstream access LSR/ABR sends a Label
Label Request on the new next-hop session. If downstream access LSR/ Request on the new next-hop session. If downstream access LSR/ABR
ABR doesn't get Label Mapping for some duration, then and only then doesn't get Label Mapping for some duration, then and only then
downstream access LSR/ABR must withdraw the upstream label. downstream access LSR/ABR withdraws the upstream label.
4.5. Label Release 4.5. Label Release
If an access LSR/ABR does not need any longer a label for a FEC, it If an access LSR/ABR does not need any longer a label for a FEC, it
sends a Label Release Message [RFC5036] to the downstream access LSR/ sends a Label Release Message [RFC5036] to the downstream access LSR/
ABR with or without the label TLV. ABR with or without the label TLV.
If upstream access LSR/ABR receives an unsolicited Label Mapping on If upstream access LSR/ABR receives an unsolicited Label Mapping on
DoD session, they should release the label by sending Label Release DoD session, they release the label by sending Label Release message.
message.
Access LSR/ABR should send a Label Release message to the downstream Access LSR/ABR sends a Label Release message to the downstream LSR in
LSR in the following cases: the following cases:
a. If it receives a Label Withdraw from the downstream access LSR/ a. If it receives a Label Withdraw from the downstream access LSR/
ABR. ABR.
b. If the /32 static route with LDP DoD Label Request policy is b. If the /32 static route with LDP DoD Label Request policy is
deleted. deleted.
c. If the service gets decommissioned and there is no corresponding c. If the service gets decommissioned and there is no corresponding
/32 static route with LDP DoD Label Request policy configured. /32 static route with LDP DoD Label Request policy configured.
d. If the route next-hop changed, and the label does not point to d. If the route next-hop changed, and the label does not point to
the best or alternate next-hop. the best or alternate next-hop.
e. If it receives a Label Withdraw from a downstream DoD session. e. If it receives a Label Withdraw from a downstream DoD session.
4.6. Local Repair 4.6. Local Repair
To support local-repair with ECMP and IPFRR LFA, access LSR/ABR must To support local-repair with ECMP and IPFRR LFA, access LSR/ABR
request labels on both the best next-hop and the alternate next-hop requests labels on both the best next-hop and the alternate next-hop
LDP DoD sessions, as specified in the Label Request procedures in LDP DoD sessions, as specified in the Label Request procedures in
Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label
from its alternate next-hop toward the PQ node and needs a label from from its alternate next-hop toward the PQ node and needs a label from
the remote PQ node toward its FEC/destination. If access LSR/ABR the remote PQ node toward its FEC/destination. If access LSR/ABR
doesn't already know those labels, it must request them. doesn't already know those labels, it requests them.
This will enable access LSR/ABR to pre-program the alternate This will enable access LSR/ABR to pre-program the alternate
forwarding path with the alternate label(s), and invoke IPFRR LFA forwarding path with the alternate label(s), and invoke IPFRR LFA
switch-over procedure if the primary next-hop link fails. switch-over procedure if the primary next-hop link fails.
5. LDP Extension for LDP DoD Fast-Up Convergence 5. LDP Extension for LDP DoD Fast-Up Convergence
In some conditions, the exponential backoff algorithm usage described In some conditions, the exponential backoff algorithm usage described
in Section 4.3.2 may result in a longer than desired wait time to get in Section 4.3.2 can result in a longer than desired wait time to get
a successful LDP label to route mapping. An example is when a a successful LDP label to route mapping. An example is when a
specific route is unavailable on the downstream LSR when the Label specific route is unavailable on the downstream LSR when the Label
Mapping request from the upstream is received, but later comes back. Mapping request from the upstream is received, but later comes back.
In such case using the exponential backoff algorithm may result in a In such case using the exponential backoff algorithm can result in a
max delay wait time before the upstream LSR sends another LDP Label max delay wait time before the upstream LSR sends another LDP Label
Request. Request.
This section describes an extension to the LDP DoD procedure to This section describes an extension to the LDP DoD procedure to
address fast-up convergence, and as such should be treated as a address fast-up convergence, and as such is to be treated as a
normative reference. The downstream and upstream LSRs SHOULD normative reference. The downstream and upstream LSRs SHOULD
implement this extension if the improvement in up convergence is implement this extension if the improvement in up convergence is
desired. desired.
The extension consists of the upstream LSR indicating to the The extension consists of the upstream LSR indicating to the
downstream LSR that the Label Request SHOULD be queued on the downstream LSR that the Label Request SHOULD be queued on the
downstream LSR until the requested route is available. downstream LSR until the requested route is available.
To implement this behavior, a new Optional Parameter is defined for To implement this behavior, a new Optional Parameter is defined for
use in the Label Request message: use in the Label Request message:
skipping to change at page 28, line 12 skipping to change at page 27, line 12
7. Security Considerations 7. Security Considerations
MPLS LDP Downstream on Demand deployment in the access network is MPLS LDP Downstream on Demand deployment in the access network is
subject to similar security threats as any MPLS LDP deployment. It subject to similar security threats as any MPLS LDP deployment. It
is recommended that baseline security measures are considered as is recommended that baseline security measures are considered as
described in Security Framework for MPLS and GMPLS networks [RFC5920] described in Security Framework for MPLS and GMPLS networks [RFC5920]
and the LDP specification [RFC5036] including ensuring authenticity and the LDP specification [RFC5036] including ensuring authenticity
and integrity of LDP messages, as well as protection against spoofing and integrity of LDP messages, as well as protection against spoofing
and Denial of Service attacks. and Denial of Service attacks.
Some deployments may require increased measures of network security Some deployments require increased measures of network security if a
if a subset of Access Nodes are placed in locations with lower levels subset of Access Nodes are placed in locations with lower levels of
of physical security e.g. street cabinets (common practice for VDSL physical security e.g. street cabinets (common practice for VDSL
access). In such cases it is the responsibility of the system access). In such cases it is the responsibility of the system
designer to take into account the physical security measures designer to take into account the physical security measures
(environmental design, mechanical or electronic access control, (environmental design, mechanical or electronic access control,
intrusion detection), as well as monitoring and auditing measures intrusion detection), as well as monitoring and auditing measures
(configuration and Operating System changes, reloads, routes (configuration and Operating System changes, reloads, routes
advertisements). advertisements).
But even with all this in mind, the designer still should consider But even with all this in mind, the designer still needs to consider
network security risks and adequate measures arising from the lower network security risks and adequate measures arising from the lower
level of physical security of those locations. level of physical security of those locations.
7.1. Security and LDP DoD 7.1. LDP DoD Native Security Properties
7.1.1. Access to network packet flow direction
An important property of MPLS LDP Downstream on Demand operation is
that the upstream LSR (requesting LSR) accepts only mappings it sent
a request for (in other words the ones it is interested in), and does
not accept any unsolicited label mappings by design.
This limits the potential of an unauthorized third party fiddling
with label mappings operations on the wire. It also enables ABR LSR
to monitor behaviour of any Access LSR in case the latter gets
compromised and attempts to get access to an unauthorized FEC or
remote LSR. Note that ABR LSR is effectively acting as a gateway to
the MPLS network, and any Label Mapping requests made by any Access
LSR are processed and can be monitored on this ABR LSR.
7.1.2. Network to access packet flow direction MPLS LDP Downstream on Demand operation is request driven and
unsolicited label mappings are not accepted by upstream LSR by
design. This inherently limits the potential of an unauthorized
third party injecting unsolicited label mappings on the wire.
Another important property of MPLS LDP DoD operation in the access is This native security property enables ABR LSR to act as a gateway to
that the number of access nodes and associated MPLS FECs per ABR LSR the MPLS network and to control the requests coming from any Access
is not large in number, and they are all known at the deployment LSR and prevent cases when the Access LSR attempts to get access to
time. Hence any changes of the access MPLS FECs can be easily an unauthorized FEC or remote LSR after being compromised.
controlled and monitored on the ABR LSR.
And then, even in the event when Access LSR manages to advertise a In the event when Access LSR gets compromised, and manages to
FEC that belongs to another LSR (e.g. in order to 'steal' third advertise a FEC belonging to another LSR (e.g. in order to 'steal'
party data flows, or breach a privacy of VPN), such Access LSR will third party data flows, or breach a privacy of a VPN), such Access
have to influence the routing decision for affected FEC on the ABR LSR would also have to influence the routing decision for affected
LSR. Following measures should be considered to prevent such event FEC on the ABR LSR to attract the flows. Following measures need to
from occurring: be considered on ABR LSR to prevent such event from occurring:
a. ABR LSR - access side with static routes - this is not possible a. Access with static routes - Access LSR can not influence ABR LSR
for Access LSR. Access LSR has no way to influence ABR LSR routing decisions due to static nature of routing configuration,
routing decisions due to static nature of routing configuration native property of the design.
here.
b. ABR LSR - access side with IGP - this is still not possible if b. Access with IGP - access FEC "stealing" - if the compromised
the compromised Access LSR is a leaf in the access topology (leaf Access LSR is a leaf in the access topology (leaf node in
node in topologies I1, I, V, Y described earlier in this topologies I1, I, V, Y described earlier), this will not have any
document), due to the leaf metrics being configured on the ABR adverse effect, due to the leaf IGP metrics being configured on
LSR. If the compromised Access LSR is a transit LSR in the the ABR LSR. If the compromised Access LSR is a transit LSR in
access topology (transit node in topologies I, Y, U), it is the access topology (transit node in topologies I, Y, U), it is
possible for this Access LSR to attract to itself traffic only possible for this Access LSR to attract traffic destined to
destined to the nodes upstream from it. However elaborate such the nodes upstream from it. Such a 'man in the middle attack'
'man in the middle attack' is possible, but can be quickly can be quickly detected by upstream Access LSRs not receiving
detected by upstream Access LSRs not receiving traffic, and traffic and LDP TCP session being lost.
legitimate traffic from them getting dropped.
c. ABR LSR - network side - designer should consider giving a higher c. Access with IGP - network FEC "stealing" - the compromised Access
LSR can use IGP to advertise "stolen" FEC prefix belonging to the
network side. This case can be prevented by giving a better
administrative preference to the labeled unicast BGP routes vs. administrative preference to the labeled unicast BGP routes vs.
access IGP routes. access IGP routes.
In summary MPLS in access design with LDP DoD has number of native In summary the native properties of MPLS in access design with LDP
properties that prevent number of security attacks and make their DoD prevent a number of security attacks and make their detection
detection quick and straightforward. quick and straightforward.
Following two sections describe other security considerations Following two sections describe other security considerations
applicable to general MPLS deployments in the access. applicable to general MPLS deployments in the access.
7.2. Data Plane Security 7.2. Data Plane Security
Data plane security risks applicable to the access MPLS network are Data plane security risks applicable to the access MPLS network
listed below (a non-exhaustive list): include :
a. packets from a specific access node flow to an altered transport
layer or service layer destination.
b. packets belonging to undefined services flow to and from the a. Labelled packets from specific Access LSR are sent to an
access network. unauthorized destination.
c. unlabelled packets destined to remote network nodes. b. Unlabelled packets are sent by Access LSR to remote network
nodes.
Following mechanisms should be considered to address listed data Following mechanisms apply to MPLS access design with LDP DoD that
plane security risks: address listed data plane security risks:
1. addressing (a) - Access and ABR LSRs should NOT accept labeled 1. addressing (a) - Access and ABR LSRs are not accepting labeled
packets over a particular data link, unless from the Access or packets over a particular data link, unless from the Access or
ABR LSR perspective this data link is known to attach to a ABR LSR perspective this data link is known to attach to a
trusted system based on employed authentication mechanism(s), and trusted system based on control plane security described in
the top label has been distributed to the upstream neighbour by Section 7.3, and the top label has been distributed to the
the receiving Access or ABR LSR. upstream neighbour by the receiving Access or ABR LSR.
2. addressing (a) - ABR LSR MAY restrict network reachability for
access devices to a subset of remote network LSR, based on
authentication or other network security technologies employed
towards Access LSRs. Restricted reachability can be enforced on
the ABR LSR using local routing policies, and can be distributed
towards the core MPLS network using routing policies associated
with access MPLS FECs.
3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP) 2. addressing (a) - ABR LSR restricts network reachability for
are not accepted from unreliable routing peers. Detection of access devices to a subset of remote network LSRs, based on
unreliable routing peers is achieved by engaging routing protocol control plane security described in Section 7.3, FEC filters and
detection and alarm mechanisms, and is out of scope of this routing policy.
document.
4. addressing (a) and (b) - no successful attacks have been mounted 3. addressing (a) - use control plane authentication described in
on the control plane and has been detected. Section 7.3.
5. addressing (c) - ABR LSR MAY restrict IP network reachability to 4. addressing (b) - ABR LSR restricts IP network reachability to and
and from the access LSR. from the Access LSR.
7.3. Control Plane Security 7.3. Control Plane Security
Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control
plane security is prerequisite to the data plane security. plane security is prerequisite to the data plane security.
To ensure control plane security access LDP DoD sessions should only To ensure control plane security access LDP DoD sessions are
be established with LDP peers that are considered trusted from the established only with LDP peers that are considered trusted from the
local LSR perspective, meaning they are reachable over a data link local LSR perspective, meaning they are reachable over a data link
that is known to attach to a trusted system based on employed that is known to attach to a trusted system based on employed
authentication mechanism(s) on the local LSR. authentication mechanism(s) on the local LSR.
The security of LDP sesions is analyzed in The security of LDP sesions is analyzed in LDP specification
[I-D.ietf-karp-routing-tcp-analysis], and its reading is recommended. [RFC5036] and in Analysis of BGP, LDP, PCEP and MSDP Issues According
Specifically the TCP/IP MD5 authentication option [RFC5925] should be to KARP Design Guide [I-D.ietf-karp-routing-tcp-analysis]. Both
used with LDP as described in LDP specification [RFC5036]. If TCP/IP documents state that LDP is subject to two different types of attacks
MD5 authentication is considered not secure enough, the designer may - spoofing and denial of service attacks.
consider using a more elaborate and advanced TCP Authentication
Option TCP-AO [RFC5925] for LDP session authentication.
Access IGP (if used) and any routing protocols used in access network
for signaling service routes should also be secured in a similar
manner. Refer to [I-D.ietf-karp-routing-tcp-analysis] and [RFC6863]
for further analysis of security properties of IS-IS and OSPF IGP
routing protocols.
For increased level of authentication in the control plane security
for a subset of access locations with lower physical security,
designer could also consider using:
o different crypto keys for use in authentication procedures for Threat of spoofed LDP Hello messages can be reduced by following
these locations. guidelines listed in LDP specification [RFC5036]: accepting Basic
Hellos only on interfaces connected to trusted LSRs, ignoring Basic
Hellos that are not addressed to All Routers on this Subnet multicast
group, using access lists. LDP Hello messages can be also secured
using an optional Cryptographic Authentication TLV specified in LDP
Hello Cryptographic Authentication
[I-D.ietf-mpls-ldp-hello-crypto-auth], what further reduces the
threat of spoofing during LDP discovery phase.
o stricter network protection mechanisms including DoS protection, Spoofing during LDP session communication phase can be prevented by
interface and session flap dampening. using TCP Authentication Option TCP-AO [RFC5925] that uses a stronger
hashing algorithm e.g. SHA1 compared to traditionally used MD5
authentication. TCP-AO is recommended as more secure compared to TCP
/IP MD5 authentication option [RFC5925].
7.4. Network Node Security The threat of the Denial of Service targetting well-known UDP port
for LDP discovery and TCP port for LDP session establishment can be
reduced by following the guidelines listed in [RFC5036] and in
[I-D.ietf-karp-routing-tcp-analysis].
If a network node, especially an Access Node, is not located in a Access IGP (if used) and any routing protocols used in access network
physically secured and controlled location, then this Access Node for signaling service routes needs also to be secured following
should implement some measures to provide a level of protection of routing protocol security best practices. Refer to KARP IS-IS
the key(s) used to its authenticate to the network, so as to avoid an security analysis [I-D.ietf-karp-isis-analysis] and Analysis of OSPF
attacker to get those keys easily. Software tools should monitor and Security According to KARP Design Guide [RFC6863] for further
keep checking the integrity of the Access Node configuration and analysis of security properties of IS-IS and OSPF IGP routing
software version. Note that this is not specific to the node using protocols.
LDP DoD. In the contrary, the use of LDP DoD will allow the upstream
/network to check, log and possibly deny the FEC requests from the
Access Node.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray
and Lizhong Jin for their suggestions and review. Additional thanks and Lizhong Jin for their suggestions and review. Additional thanks
go to Adrian Farrel for thorough pre-publication review and editing go to Adrian Farrel for thorough pre-publication review, Stephen Kent
suggestions. for review and guidance specifically for the security section.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
skipping to change at page 32, line 21 skipping to change at page 30, line 42
[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.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
9.2. Informative References 9.2. Informative References
[I-D.ietf-karp-isis-analysis]
Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security
analysis", draft-ietf-karp-isis-analysis-00 (work in
progress), March 2013.
[I-D.ietf-karp-routing-tcp-analysis] [I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013. progress), April 2013.
[I-D.ietf-mpls-ldp-hello-crypto-auth]
Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", draft-ietf-mpls-ldp-hello-
crypto-auth-01 (work in progress), January 2013.
[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", draft- M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-02 (work in progress), October ietf-mpls-seamless-mpls-03 (work in progress), May 2013.
2012.
[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.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
skipping to change at page 33, line 14 skipping to change at page 31, line 43
Thomas Beckhaus (editor) Thomas Beckhaus (editor)
Deutsche Telekom AG Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64307 Darmstadt 64307
Germany Germany
Phone: +49 6151 58 12825 Phone: +49 6151 58 12825
Email: thomas.beckhaus@telekom.de Email: thomas.beckhaus@telekom.de
Bruno Decraene Bruno Decraene
France Telecom Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9 92794
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Kishore Tiruveedhula Kishore Tiruveedhula
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
USA USA
Phone: 1-(978)-589-8861 Phone: 1-(978)-589-8861
Email: kishoret@juniper.net Email: kishoret@juniper.net
Maciek Konstantynowicz (editor) Maciek Konstantynowicz (editor)
 End of changes. 116 change blocks. 
348 lines changed or deleted 324 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/