Internet DRAFT - draft-chen-i2rs-mpls-ldp-usecases
draft-chen-i2rs-mpls-ldp-usecases
Interdomain Routing Working Group X. Chen
Internet-Draft Z. Li
Intended status: Informational Huawei Technologies
Expires: April 23, 2014 October 20, 2013
Use Cases for an Interface to LDP Protocol
draft-chen-i2rs-mpls-ldp-usecases-00
Abstract
The Label Distribution Protocol (LDP) [RFC5036] is a protocol defined
for distributing labels in MPLS domain. Traditionally LDP protocol
may be managed via CLI, SNMP or NETCONF. Interface to the Routing
System's (I2RS) Programmatic interfaces, as defined in
[I-D.ward-i2rs-framework], provides an alternate way to control the
configuration and diagnose the operation of the LDP protocol. This
document describes requirement and use cases for which I2RS can be
used for LDP protocol.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2014.
Chen & Li Expires April 23, 2014 [Page 1]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LDP Configuration . . . . . . . . . . . . . . . . . . . . . . 3
2.1. LDP Protocol Configuration . . . . . . . . . . . . . . . 3
2.2. LDP Policy Configuration . . . . . . . . . . . . . . . . 4
3. LDP Events . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Notification of LDP Session or LSP Events . . . . . . . . 4
3.2. LDP Protocol Statistics . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Label Distribution Protocol (LDP) is a protocol defined for
distributing labels in MPLS domain. Traditionally LDP protocol may
be managed via CLI, SNMP or NETCONF.
The I2RS, as defined in [I-D.ward-i2rs-framework], may be used for
the configuration, manipulation, polling or analyzing protocol data.
The I2RS is not intended to replace any existing configuration
mechanisms. Instead, I2RS is intended to augment those existing
mechanisms by defining a standardized set of programmatic interfaces
to enable easier configuration, interrogation and analysis of the
protocol.
This document describes requirement and use cases for which I2RS can
be used for LDP protocol. The use cases described in this document
encompass: LDP protocol configuration, LDP policy configuration, LDP
protocol events.
Chen & Li Expires April 23, 2014 [Page 2]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
2. LDP Configuration
LDP can be used to create transport LSPs to carry MPLS-based service
and establish the pseudowires for MPLS PWE3 service [RFC4447] or MPLS
VPLS service [RFC4762]. LDP is deployed widely in the network
because of its simple protocol configuration and flexible policy.
For illustration purposes one service type related to pseudowires is
described in following document: PWE3 service.
By I2RS interface the network application can configure LDP sessions
to deploy PWE3 service and can configure LDP policy to control the
setup of LDP LSPs. The application can select proper programmatic
interface.
2.1. LDP Protocol Configuration
The basic configuration of LDP includes establishing and maintaining
LDP sessions, setting parameters of LDP sessions like type of
application over the established LDP session
[I-D.ietf-mpls-ldp-ip-pw-capability] etc.
An LDP session is set up between the pseudowire endpoints to provide
MPLS-based PWE3 services. The PW label bindings are distributed over
the LDP session. The pseudowire endpoints is normally configured as
the LSR ID which is the first four octets of LDP Identifier. LSR can
use the different local LSR ID to build sessions with different peers
in order to isolate VPN services.
LDP sessions used by PWE3 services are established normally by LDP
extended discovery that the LSR periodically sending LDP Targeted
Hellos to the specific address.
I2RS would allow an application to push configuration using a set of
programmatic APIs from a central location where a global PWE3
provisioning information could be stored. This helps avoid manual
configuration of PWE3 and LDP on multiple pseudowire endpoints. Use
of I2RS programmatic API can push the configuration of the local LDP
LSR ID and peer address to set up the targeted session to the
pseudowire endpoints.
Sometimes end-user wants to disable IPoMPLS application on a L2VPN/PW
Tarted LDP session [I-D.ietf-mpls-ldp-ip-pw-capability]. Use of I2RS
programmatic API can set type of application over the established LDP
session. In this way LDP speaker can only advertise to its peer the
application data which is interested by the user.
Chen & Li Expires April 23, 2014 [Page 3]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
2.2. LDP Policy Configuration
LDP supports some policy configuration used to control the allocation
of labels, to filter the advertisement and acceptance of label
bindings, to trigger LDP DoD request for some prefixes and so on.
In seamless MPLS scenario [I-D.ietf-mpls-seamless-mpls] access
devices can only hold limited amount of state because of their
compute and memory constraints.
If LDP DU advertisement mode is used between AN and AGN, the outbound
policy can be configured on AGN to advertise selective prefixes to
specified AN.
With I2RS a network operator can push LDP outbound policy
configuration using a programmatic API from an I2RS controller to
specific AGN according to the network condition.
If LDP DoD advertisement mode is used between AN and AGN, and there
is only default route in AN, the feature which is LDP Extension for
Inter-Area LSPs [RFC5283] must be adopted and the LDP DoD request
policy [I-D.ietf-mpls-ldp-dod] should be configured to trigger the
establishment of LSP for /32 FEC which is PWE3 destination /32 FEC in
PWE3 service or BGP next-hop /32 FEC BGP/MPLS IPVPN service
[RFC4364].
With I2RS a network operator can push LDP DoD request policy
configuration using a programmatic API from an I2RS controller to
specific AN according to the service requirement.
3. LDP Events
I2RS could provide a publish-subscribe capability to applications to:
o subscribe state of LDP sessions or LSPs and related events; and,
o subscribe number of LDP sessions or LSPs or other protocol-related
events of interest.
3.1. Notification of LDP Session or LSP Events
Some applications adopt LSPs established by LDP protocol to carry
service and the end-user would care about the state of such LSPs and
hope to know about changes of their state immediately. PWE3 service
adopt targeted LDP sessions to establish pseudowires and the end-user
would care about the state of such LDP sessions and hope to receive
the immediate notification of changes in their state.
Chen & Li Expires April 23, 2014 [Page 4]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
The applications can use the I2RS interface to subscribe the state of
LDP sessions or LDP LSPs. When the requisite events about sessions
coming up or going down are observed by an LSR, it would notify I2RS
controllers. So applications would immediately receive the published
events and take the appropriate action, for example, diagnosing why
the service is invalid or analyzing whether an alternate path should
be switched to and how the link failure or node failure is recovered.
3.2. LDP Protocol Statistics
There are several statistics related to LDP protocol like the number
of LDP sessions, the count of LDP LSPs. These statistics can help
network operators know about the status of the resources LDP protocol
makes use of.
Some access device has limited label entry resource and need
restricting the maximum number of LDP LSPs. The network
administrator wants to know whether the current number of LDP LSPs is
close to the maximum number and if close the administrator can take
necessary action.
The application can set the maximum number of LDP LSPs by I2RS
programmatic API before LDP is enabled. The application can set the
warning threshold too. When the number of LDP LSPs reaches the
threshold the warning message is triggered and notified to the
application in the I2RS controller. The operator can take some
action according to the warning message.
4. Security Considerations
The LDP use cases described in this document assumes use of I2RS's
programmatic interfaces described in the I2RS framework mentioned in
[I-D.ward-i2rs-framework]. This document does not change the
underlying security issues inherent in the existing [I-D.ward-i2rs-
framework].
5. References
5.1. Normative References
[I-D.ward-i2rs-framework]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Framework", draft-ward-i2rs-framework-00
(work in progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Chen & Li Expires April 23, 2014 [Page 5]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
5.2. Informative References
[I-D.ietf-mpls-ldp-dod]
Beckhaus, T., Decraene, B., Tiruveedhula, K.,
Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work
in progress), July 2013.
[I-D.ietf-mpls-ldp-ip-pw-capability]
Raza, K. and S. Boutros, "Disabling IPoMPLS and P2P PW LDP
Application's State Advertisement", draft-ietf-mpls-ldp-
ip-pw-capability-06 (work in progress), June 2013.
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-04 (work in progress), July 2013.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
Authors' Addresses
Xia Chen
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: smile.chen@huawei.com
Chen & Li Expires April 23, 2014 [Page 6]
Internet-Draft Use Cases for an Interface to LDP Protocol October 2013
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Chen & Li Expires April 23, 2014 [Page 7]
