--- 1/draft-ietf-mpls-ldp-dod-06.txt 2013-05-13 14:14:26.773867199 +0100 +++ 2/draft-ietf-mpls-ldp-dod-07.txt 2013-05-13 14:14:26.837868755 +0100 @@ -1,24 +1,24 @@ Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Standards Track B. Decraene -Expires: November 11, 2013 France Telecom +Expires: November 14, 2013 France Telecom K. Tiruveedhula Juniper Networks M. Konstantynowicz L. Martini Cisco Systems, Inc. - May 10, 2013 + May 13, 2013 LDP Downstream-on-Demand in Seamless MPLS - draft-ietf-mpls-ldp-dod-06 + draft-ietf-mpls-ldp-dod-07 Abstract Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand @@ -43,21 +43,21 @@ 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 November 11, 2013. + This Internet-Draft will expire on November 14, 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 @@ -1169,24 +1169,24 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Queue Request (0x0971) | Length (0x00) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit = 1 Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit being set (=1), the unknown TLV MUST be silently ignored and the - rest of the message processed as if the unknown TLV did not exist. - In case requested route is not available, the downstream LSR MUST - ignore this unknown TLV and send a "no route" notification back. - Ensures backward compatibility. + rest of the message processed as if the unknown TLV did not + exist. In case requested route is not available, the downstream + LSR MUST ignore this unknown TLV and send a "no route" + notification back. Ensures backward compatibility. F-bit = 0 Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. Due to F-bit being clear (=0), the unknown TLV is not forwarded with the containing message. Type Queue Request Type value to be allocated by IANA. @@ -1404,70 +1404,72 @@ attacker to get those keys easily. Software tools should monitor and keep checking the integrity of the Access Node configuration and software version. Note that this is not specific to the node using 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 The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai - Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin - for their suggestions and review. + Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray + and Lizhong Jin for their suggestions and review. Additional thanks + go to Adrian Farrel for thorough pre-publication review and editing + suggestions. 9. References 9.1. Normative References - [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-02 (work in progress), October - 2012. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [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. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. - [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS - Networks", RFC 5920, July 2010. - 9.2. Informative References [I-D.ietf-karp-routing-tcp-analysis] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in progress), April 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-02 (work in progress), October + 2012. + [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009. + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013. Authors' Addresses Thomas Beckhaus Deutsche Telekom AG