LDP Downstream-on-Demand in Seamless MPLS
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, mpls mailing list <firstname.lastname@example.org>, mpls chair <email@example.com> Subject: Protocol Action: 'LDP Downstream-on-Demand in Seamless MPLS' to Proposed Standard (draft-ietf-mpls-ldp-dod-09.txt) The IESG has approved the following document: - 'LDP Downstream-on-Demand in Seamless MPLS' (draft-ietf-mpls-ldp-dod-09.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/
Technical Summary 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 (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. Working Group Summary There is a strong support for this document in the working group and it has been has been well reviewed. Draft has been mainly driven and architected by an operator that have specifed the Seamless MPLS, based on opreational experiences. Document Quality There are both existing and intended implementations of this specification. The document has been reviewed as needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the responsible AD. RFC Editor Note Please replace "ISIS" with "IS-IS" throughout. On first use, please expand RIB and FIB as Routing Information Base Forwarding Information base Please expand ECMP as Equal-Cost Multipath Please expand LAG as Link Aggregation Group Please expand FEC as Forwarding Equivalence Class Please expand IPFRR as IP Fast-reroute Please expand LFA as Loop-Free Alternate --- Abstract s/specific to access/specific to access networks/ --- Section 1 s/(access ABRs)/ABRs/ --- Section 3.1.1... In order to facilitate ECMP and IPFRR LFA local-repair, the upstream AN/AGN1x also sends LDP DoD label requests to alternate next-hops per its RIB, and install received labels as alternate entries in its LIB and LFIB. As well as expanding the acronyms as requested above, please... s/local-repair/ local-repair [RFC5714]/ --- Section 4.3.2 s/algoritm/algorithm/ --- Section 4.6 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR requests labels on both the best next-hop and the alternate next-hop LDP DoD sessions, as specified in the Label Request procedures in Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label from its alternate next-hop toward the PQ node and needs a label from the remote PQ node toward its FEC/destination. If access LSR/ABR doesn't already know those labels, it requests them. Note that "PQ" has no expansion! s/destination./destination [I-D.ietf-rtgwg-remote-lfa]./ --- Section 9.2 please add [I-D.ietf-rtgwg-remote-lfa] Bryant, S., Filsfils, C., Previdi, S., Shand, M. and N. So, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa, (work in progress. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.