draft-ietf-mpls-ldp-ip-pw-capability-08.txt   draft-ietf-mpls-ldp-ip-pw-capability-09.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: April 18, 2015 Cisco Systems, Inc. Expires: July 17, 2015 Cisco Systems, Inc.
October 15, 2014 January 18, 2015
Controlling State Advertisements Of Non-negotiated LDP Applications Controlling State Advertisements Of Non-negotiated LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-08.txt draft-ietf-mpls-ldp-ip-pw-capability-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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 Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 carefully, publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the Legal Provisions and are provided without warranty as described in the
skipping to change at page 2, line 26 skipping to change at page 2, line 26
non-negotiated applications, thus disabling the unnecessary non-negotiated applications, thus disabling the unnecessary
advertisement of corresponding application state, which would have advertisement of corresponding application state, which would have
otherwise be advertised over the established LDP session. otherwise be advertised over the established LDP session.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4
3. Non-negotiated LDP applications . . . . . . . . . . . . . . . . 4 3. Non-negotiated LDP applications . . . . . . . . . . . . . . . . 4
3.1. Non-interesting State . . . . . . . . . . . . . . . . . . . 4 3.1. Non-interesting State . . . . . . . . . . . . . . . . . . . 4
3.1.1 Prefix-LSPs . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Prefix-LSPs . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 P2P-PWs . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. P2P-PWs . . . . . . . . . . . . . . . . . . . . . . . 5
4. Controlling State Advertisement . . . . . . . . . . . . . . . . 5 4. Controlling State Advertisement . . . . . . . . . . . . . . . . 5
4.1. State Advertisement Control Capability . . . . . . . . . . 5 4.1. State Advertisement Control Capability . . . . . . . . . . 5
4.2. Capabilities Procedures . . . . . . . . . . . . . . . . . . 8 4.2. Capabilities Procedures . . . . . . . . . . . . . . . . . . 8
4.2.1. State Control Capability in an Initialization message . 8 4.2.1. State Control Capability in an Initialization message . 8
4.2.2. State Control capability in a Capability message . . . 9 4.2.2. State Control capability in a Capability message . . . 9
5. Applicability Statement . . . . . . . . . . . . . . . . . . . . 9 5. Applicability Statement . . . . . . . . . . . . . . . . . . . . 9
6. Operational Examples . . . . . . . . . . . . . . . . . . . . . 11 6. Operational Examples . . . . . . . . . . . . . . . . . . . . . 11
6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session . . . 11 6.1. Disabling Prefix-LSPs and P2P-PWs on an ICCP session . . . 11
6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session . . . . . 11 6.2. Disabling Prefix-LSPs on a L2VPN/PW T-LDP session . . . . . 11
6.3. Disabling Prefix-LSPs dynamically on an established LDP 6.3. Disabling Prefix-LSPs dynamically on an estab. LDP session 11
session . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Disabling Prefix-LSPs on an mLDP-only session . . . . . . . 12 6.4. Disabling Prefix-LSPs on an mLDP-only session . . . . . . . 12
6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR . . 12 6.5. Disabling IPv4 or IPv6 Prefix-LSPs on a dual-stack LSR . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2 Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
LDP Capabilities specification [RFC5561] introduced a mechanism to LDP Capabilities specification [RFC5561] introduced a mechanism to
negotiate LDP capabilities for a given feature between peer Label negotiate LDP capabilities for a given feature between peer Label
Switching Routers (LSRs). The capability mechanism insures that no Switching Routers (LSRs). The capability mechanism insures that no
unnecessary state is exchanged between peer LSRs unless the unnecessary state is exchanged between peer LSRs unless the
corresponding feature capability is successfully negotiated between corresponding feature capability is successfully negotiated between
skipping to change at page 6, line 47 skipping to change at page 6, line 47
Figure 2: Format of "State Advertisement Control Element" Figure 2: Format of "State Advertisement Control Element"
Where: Where:
D bit: Controls the advertisement of the state specified in "App" D bit: Controls the advertisement of the state specified in "App"
field: field:
1: Disable state advertisement 1: Disable state advertisement
0: Enable state advertisement 0: Enable state advertisement
When sent in an Initialization message, D bit MUST be set When sent in an Initialization message, D bit MUST be set
to 1. to 1.
App: Defines the application type whose state advertisement is to be App: Defines the legacy application type whose state advertisement
controlled. The value of this field is defined as follows: is to be controlled. The value of this field is defined as
follows:
1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) 1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes)
2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) 2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes)
3: FEC128 P2P-PW (L2VPN PWid FEC signaling) 3: FEC128 P2P-PW (L2VPN PWid FEC signaling)
4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling) 4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling)
Any other value in this field MUST be treated as an error. Any other value in this field MUST be treated as an error.
Unused: MBZ on transmit and ignored on receipt. Unused: MBZ on transmit and ignored on receipt.
The "Length" field of SAC Capability TLV depends on the number of SAC The "Length" field of SAC Capability TLV (in octets) is computed as
Elements present in the TLV. For example, if there are two elements following:
present, then the Length field is set to 3 octets. A receiver of this Length (in octets) = 1 + number of SAC elements
capability TLV can deduce number of elements present in the TLV by For example, if there are two SAC elements present, then the Length
using the Length field. field is set to 3 octets. A receiver of this capability TLV can
deduce the number of elements 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 exchange for one or more application(s) need to be disabled on
the given peer session. This TLV can also be sent later in a the given peer session. This TLV can also be sent later in a
Capability message to selectively enable or disable these Capability message to selectively enable or disable these
applications. If there are more than one elements present in a SAC applications. If there are more than one elements present in a SAC
skipping to change at page 10, line 35 skipping to change at page 10, line 35
"Dynamic Announcement" Capability to announce the change in SAC "Dynamic Announcement" Capability to announce the change in SAC
capability via LDP Capability message. However, if any of the peering capability via LDP Capability message. However, if any of the peering
LSR does not support this capability, the alternate option is to LSR does not support this capability, the alternate option is to
force reset the LDP session to advertise the new SAC capability force reset the LDP session to advertise the new SAC capability
accordingly during the following session initialization. accordingly during the following session initialization.
Following are some more important points that an operator need to Following are some more important points that an operator need to
consider regarding the applicability of this new capability and consider regarding the applicability of this new capability and
associated procedures defined in this document: associated procedures defined in this document:
- An operator SHOULD disable Prefix-LSPs state on any Targeted LDP (T-LDP) - An operator SHOULD disable Prefix-LSPs state on any Targeted LDP
session that is established for ICCP-only and/or PW-only purposes. (T-LDP) session that is established for ICCP-only and/or PW-only
purposes.
- An operator MUST NOT disable Prefix-LSPs state on any T-LDP session - An operator MUST NOT disable Prefix-LSPs state on any T-LDP session
that is established for remote LFA FRR [RLFA] reasons. that is established for remote LFA FRR [RLFA] reasons.
- In a remote LFA FRR [RLFA] enabled network, it is RECOMMENDED to - In a remote LFA FRR [RLFA] enabled network, it is RECOMMENDED to
not disable Prefix-LSPs state on a T-LDP session even if the current not disable Prefix-LSPs state on a T-LDP session even if the
session type is PW-only and/or ICCP-only. This is recommended because current session type is PW-only and/or ICCP-only. This is
any remote/T-LDP neighbor could potentially be picked as a remote LFA recommended because any remote/T-LDP neighbor could potentially be
PQ node. picked as a remote LFA PQ node.
- This capability SHOULD be enabled for Prefix-LSPs in the - This capability SHOULD be enabled for Prefix-LSPs in the
scenarios when it is desirable to disable (or enable) scenarios when it is desirable to disable (or enable)
advertisement of "all" the prefix label bindings. For scenarios advertisement of "all" the prefix label bindings. For scenarios
when a "subset" of bindings need to be filtered, the existing when a "subset" of bindings need to be filtered, the existing
filtering procedures pertaining to label binding announcement filtering procedures pertaining to label binding announcement
should be used. should be used.
- It is allowed to use label advertisement filtering policies in - It is allowed to use label advertisement filtering policies in
conjunction with the procedures defined in this document for conjunction with the procedures defined in this document for
skipping to change at page 14, line 32 skipping to change at page 14, line 32
Matsushima, S., and T. Nadeau, "Inter-Chassis Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June
2014, <http://www.rfc-editor.org/info/rfc7275>. 2014, <http://www.rfc-editor.org/info/rfc7275>.
[P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to- [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp- Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-
pw-04.txt, Work in Progress, March 2012. pw-04.txt, Work in Progress, March 2012.
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N., [RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N.,
"Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-08, Work in "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-10, Work in
Progress, September 2014. Progress, January 2015.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Eric Rosen and Alexander Vainshtein The authors would like to thank Eric Rosen and Alexander Vainshtein
for their review and valuable comments. We also acknowledge Karthik for their review and valuable comments. We also acknowledge Karthik
Subramanian and IJsbrand Wijnands for bringing up mLDP use case. Subramanian and IJsbrand Wijnands for bringing up mLDP use case.
Authors' Addresses Authors' Addresses
Kamran Raza Kamran Raza
 End of changes. 12 change blocks. 
25 lines changed or deleted 28 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/