--- 1/draft-ietf-mpls-app-aware-tldp-01.txt 2016-02-17 13:15:34.611133936 -0800 +++ 2/draft-ietf-mpls-app-aware-tldp-02.txt 2016-02-17 13:15:34.707136324 -0800 @@ -1,32 +1,31 @@ MPLS Working Group Santosh Esale INTERNET-DRAFT Raveendra Torvi -Intended Status: Proposed Standard Chris Bowers -Expires: February 21, 2016 Juniper Networks - +Intended Status: Proposed Standard Juniper Networks +Expires: August 20, 2016 Luay Jalil Verizon U. Chunduri Ericsson Inc. Zhenbin Li Huawei Kamran Raza Cisco Systems Inc. - August 20, 2015 + February 17, 2016 Application-aware Targeted LDP - draft-ietf-mpls-app-aware-tldp-01 + draft-ietf-mpls-app-aware-tldp-02 Abstract Recent targeted LDP applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications @@ -53,21 +52,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 @@ -566,31 +565,30 @@ receiver LSR MAY have reached a configured limit for accepting Remote LFA automatic tLDP sessions, but it may also be configured to accept LDP over RSVP tunneling. In such a case, the tLDP session is formed for both LDP over RSVP and Remote LFA applications as both needs same FECs - IPv4 and/or IPv6. 5.4 mLDP node protection targeted session A merge point LSR may determines that it needs to form automatic tLDP session to the upstream point of local repair (PLR) LSR for MP2P and - MP2MP LSP node protection as described in the [I-D.draft-ietf-mpls- - mldp-node-protection]. The MPT LSR may add a new targeted LDP - application - mLDP protection, as a unique TAE in the Targeted - Application Capability Data of a TAC TLV and send it in the - Initialization message to the PLR. If the PLR is configured for mLDP - node protection and establishing this session does not exceed the - limit of either mLDP node protection sessions or automatic tLDP - sessions, the PLR may decide to accept this session. Further, the PLR - responds back with the initialization message with a TAC TLV that has - one of the TAEs as - mLDP protection and the session proceeds to - establishment as per [RFC5036]. + MP2MP LSP node protection as described in the [RFC7715]. The MPT LSR + may add a new targeted LDP application - mLDP protection, as a unique + TAE in the Targeted Application Capability Data of a TAC TLV and send + it in the Initialization message to the PLR. If the PLR is configured + for mLDP node protection and establishing this session does not + exceed the limit of either mLDP node protection sessions or automatic + tLDP sessions, the PLR may decide to accept this session. Further, + the PLR responds back with the initialization message with a TAC TLV + that has one of the TAEs as - mLDP protection and the session + proceeds to establishment as per [RFC5036]. 6 Security Considerations The Capability procedure described in this document will apply and does not introduce any change to LDP Security Considerations section described in [RFC5036]. As described in [RFC5036], DoS attacks via Extended Hellos can be addressed by filtering Extended Hellos using access lists that define addresses with which Extended Discovery is permitted. Further, as @@ -659,36 +657,39 @@ Tiruveedhul, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas Beckhaus, Tarek Saad and Lizhong Jin for doing the detailed review. Thanks to Manish Gupta and Martin Ehlers for their input to this work and for many helpful suggestions. 9 References 9.1 Normative References [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., - "LDP Specification", RFC 5036, October 2007. + "LDP Specification", RFC 5036, October 2007, + . [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. - Le Roux, "LDP Capabilities", RFC 5561, July 2009. + Le Roux, "LDP Capabilities", RFC 5561, July 2009, + . [RFC7473] Kamran Raza, Sami Boutros, "Controlling State Advertisements of Non-negotiated LDP Applications", RFC - 7473, March 2015. + 7473, March 2015, . - [I-D.draft-ietf-mpls-mldp-node-protection] IJ. Wijnands, E. Rosen, K. - Raza, J. Tantsura, A. Atlas, Q. Zhao, "mLDP Node - Protection", draft-ietf-mpls-mldp-node-protection-05 (work - in progress), February 9, 2015. + [RFC7715] IJ. Wijnands, E. Rosen, K. Raza, J. Tantsura, A. Atlas, Q. + Zhao, "mLDP Node Protection", RFC 7715, January 2016, + . [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, + . 9.2 Informative References [RFC7490] S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", April 2015. [RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", January 2011.