draft-ietf-mpls-ldp-ip-pw-capability-04.txt   draft-ietf-mpls-ldp-ip-pw-capability-05.txt 
MPLS Working Group Kamran Raza MPLS Working Group Kamran Raza
Internet Draft Sami Boutros Internet Draft Sami Boutros
Intended status: Standards Track Intended status: Standards Track
Expires: November 8, 2013 Cisco Systems Expires: November 9, 2013 Cisco Systems
May 9, 2013 May 10, 2013
Disabling IPoMPLS and P2P PW LDP Application's State Advertisement Disabling IPoMPLS and P2P PW LDP Application's State Advertisement
draft-ietf-mpls-ldp-ip-pw-capability-04.txt draft-ietf-mpls-ldp-ip-pw-capability-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 8, 2013. This Internet-Draft will expire on November 9, 2013.
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 4, line 35 skipping to change at page 4, line 35
Capabilities framework [RFC5561], an LDP speaker typically Capabilities framework [RFC5561], an LDP speaker typically
advertises, without waiting for any capabilities exchange and advertises, without waiting for any capabilities exchange and
negotiation, its corresponding application state to its peers right negotiation, its corresponding application state to its peers right
after the session establishment. These early LDP applications after the session establishment. These early LDP applications
include: include:
o IPv4/IPv6 Label Switching ("IPoMPLS") o IPv4/IPv6 Label Switching ("IPoMPLS")
o L2VPN P2P PW signaling ("P2P PW") o L2VPN P2P PW signaling ("P2P PW")
To disable unnecessary state exchange for such LDP applications over To disable unnecessary state advertisement for such LDP applications
an established LDP session, a new capability is being introduced in over an established LDP session, a new capability is introduced in
this document. This new capability controls the advertisement of this document. This new capability controls the advertisement of
application state and enables an LDP speaker to notify its peer its application state and enables an LDP speaker to notify its peer its
disinterest in the state of one or more of these "Non-negotiated" disinterest in the state of one or more of these "Non-negotiated"
LDP applications at the time of session establishment. Upon receipt LDP applications at the time of session establishment. Upon receipt
of such capability, the receiving LDP speaker, if supporting the of such capability, the receiving LDP speaker, if supporting the
capability, disables the advertisement of the state related to the capability, disables the advertisement of the state related to the
application towards the sender. This new capability can also be sent application towards the sender. This new capability can also be sent
later in a Capability message to either disable a previously enabled later in a Capability message to either disable a previously enabled
application's state advertisement or to enable a previously disabled application's state advertisement or to enable a previously disabled
application's state advertisement. application's state advertisement.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
SAC Elements present in the TLV. For example, if there are two SAC Elements present in the TLV. For example, if there are two
elements present, then the Length field is set to 5 octets. A elements present, then the Length field is set to 5 octets. A
receiver of this capability TLV can deduce number of elements receiver of this capability TLV can deduce number of elements
present in the TLV by using the Length field. present in the TLV by using the Length field.
From now onward, this document uses the term "element" to refer to a From now onward, this document uses the term "element" to refer to a
SAC Element. SAC Element.
As described earlier, SAC Capability TLV MAY be included by an LDP As described earlier, SAC Capability TLV MAY be included by an LDP
speaker in an Initialization message to signal to its peer LSR that speaker in an Initialization message to signal to its peer LSR that
state exchange for one or more application(s) need to be disabled on state advertisement for one or more application(s) need to be
the given peer session. This TLV can also be sent later in a disabled on the given peer session. This TLV can also be sent later
Capability message to selectively enable or disable these in a Capability message to selectively enable or disable these
applications. A SAC Capability TLV MUST contain elements with applications. A SAC Capability TLV MUST contain elements with
distinct state types and the TLV MUST NOT contain the same state distinct state types and the TLV MUST NOT contain the same state
type more than once. If a receiver receives such a malformed TLV, it type more than once. If a receiver receives such a malformed TLV, it
SHOULD discard this TLV and continue processing rest of the message. SHOULD discard this TLV and continue processing rest of the message.
To control more than one application state, a sender LSR can either To control more than one application state, a sender LSR can either
send a single capability TLV in a message with multiple elements send a single capability TLV in a message with multiple elements
present, or can send separate messages with capability TLV present, or can send separate messages with capability TLV
specifying one or more elements. A receiving LSR, however, MUST specifying one or more elements. A receiving LSR, however, MUST
treat each incoming capability TLV for a given application state treat each incoming capability TLV for a given application state
skipping to change at page 10, line 43 skipping to change at page 10, line 43
from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label from its peer, LSR2 MAY use a single Prefix FEC Typed Wildcard Label
Withdraw message [RFC5918]. Withdraw message [RFC5918].
This dynamic disability of IPoMPLS application does not impact L2VPN This dynamic disability of IPoMPLS application does not impact L2VPN
P2P PW application on the given session, and both LSRs should P2P PW application on the given session, and both LSRs should
continue to exchange PW Signaling application related state. continue to exchange PW Signaling application related state.
6.4. Disabling IPoMPLS application on an mLDP-only session 6.4. Disabling IPoMPLS application on an mLDP-only session
Now assume that LSR1 and LSR2 have formed an LDP session to exchange Now assume that LSR1 and LSR2 have formed an LDP session to exchange
mLDP state only. In typical deployments, LSR1 and LSR2 also exchange mLDP application state only. In typical deployments, LSR1 and LSR2
bindings for IP prefixes upon mLDP session, which is unnecessary and also exchange label bindings for IP prefixes over an mLDP session,
wasteful for an mLDP-only LSR. which is unnecessary and wasteful for an mLDP-only LSR.
Using the procedures defined earlier, an LSR can indicate its Using the procedures defined earlier, an LSR can indicate its
disinterest in IPoMPLS application state to its peer upon session disinterest in IPoMPLS application state to its peer upon session
establishment time or dynamically later via LDP capabilities update. establishment time or dynamically later via LDP capabilities update.
Reference to section 3.1, the peer disables the advertisement of any Reference to section 3.1, the peer disables the advertisement of any
state related to IP Prefix FECs, but still advertises IP address state related to IP Prefix FECs, but still advertises IP address
bindings that are required for the correct operation of mLDP. bindings that are required for the correct operation of mLDP.
6.5. Disabling unwanted IP state advertisement by an IP dual-stack LSR 6.5. Disabling unwanted IP state advertisement by an IP dual-stack LSR
skipping to change at page 11, line 41 skipping to change at page 11, line 41
IPv6oMPLS Label switching application dynamically. IPv6oMPLS Label switching application dynamically.
7. Security Considerations 7. Security Considerations
The proposal introduced in this document does not introduce any new The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to the base LDP security considerations beyond that already apply to the base LDP
specification [RFC5036] and [RFC5920]. specification [RFC5036] and [RFC5920].
8. IANA Considerations 8. IANA Considerations
The document defines a new capability parameter TLV and requests This document defines a new LDP cpability parameter TLV. IANA is
following LDP TLV code point assignment by IANA from LDP "TLV Type requested to assign the lowest available value after 0x0500 from
Name Space" registry: "TLV Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry within "Label Distribution Protocol (LDP)
Name Spaces" as the new code point for the LDP TLV code point.
o "State Advertisement Control Capability" TLV (requested +-----+---------------------+---------------+-----------------------+
codepoint: 0x50C) |Range| Description | Reference |Notes/Registration Date|
+-----+---------------------+---------------+-----------------------+
| TBA | State Advertisement | This document | |
| | Control Capability | | |
+-----+---------------------+---------------+-----------------------+
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
Specification", RFC 5036, September 2007. Specification", RFC 5036, September 2007.
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le
Roux, "LDP Capabilities", RFC 5561, July 2009. Roux, "LDP Capabilities", RFC 5561, July 2009.
 End of changes. 9 change blocks. 
17 lines changed or deleted 23 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/