draft-ietf-mpls-ldp-dod-06.txt   draft-ietf-mpls-ldp-dod-07.txt 
Network Working Group T. Beckhaus Network Working Group T. Beckhaus
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track B. Decraene Intended status: Standards Track B. Decraene
Expires: November 11, 2013 France Telecom Expires: November 14, 2013 France Telecom
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz M. Konstantynowicz
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
May 10, 2013 May 13, 2013
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-06 draft-ietf-mpls-ldp-dod-07
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of using standardized IP/MPLS protocols. One of the key goals of
Seamless MPLS is to meet requirements specific to access, including Seamless MPLS is to meet requirements specific to access, including
high number of devices, their position in network topology and their high number of devices, their position in network topology and their
compute and memory constraints that limit the amount of state access compute and memory constraints that limit the amount of state access
devices can hold.This can be achieved with LDP Downstream-on-Demand devices can hold.This can be achieved with LDP Downstream-on-Demand
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 11, 2013. This Internet-Draft will expire on November 14, 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 26, line 38 skipping to change at page 26, line 38
0 1 2 3 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 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) | |1|0| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1 U-bit = 1
Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit 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 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. rest of the message processed as if the unknown TLV did not
In case requested route is not available, the downstream LSR MUST exist. In case requested route is not available, the downstream
ignore this unknown TLV and send a "no route" notification back. LSR MUST ignore this unknown TLV and send a "no route"
Ensures backward compatibility. notification back. Ensures backward compatibility.
F-bit = 0 F-bit = 0
Forward unknown TLV bit. This bit applies only when the U-bit is 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 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. Due to F-bit being clear (=0), the unknown TLV is not
forwarded with the containing message. forwarded with the containing message.
Type Type
Queue Request Type value to be allocated by IANA. Queue Request Type value to be allocated by IANA.
skipping to change at page 31, line 37 skipping to change at page 31, line 37
attacker to get those keys easily. Software tools should monitor and attacker to get those keys easily. Software tools should monitor and
keep checking the integrity of the Access Node configuration and keep checking the integrity of the Access Node configuration and
software version. Note that this is not specific to the node using 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 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 /network to check, log and possibly deny the FEC requests from the
Access Node. Access Node.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray
for their suggestions and review. 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. References
9.1. Normative 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 [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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
9.2. Informative References 9.2. Informative References
[I-D.ietf-karp-routing-tcp-analysis] [I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013. 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 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. 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 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013. Protocols (KARP) Design Guide", RFC 6863, March 2013.
Authors' Addresses Authors' Addresses
Thomas Beckhaus Thomas Beckhaus
Deutsche Telekom AG Deutsche Telekom AG
 End of changes. 10 change blocks. 
19 lines changed or deleted 21 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/