[mpls] Protocol Action: 'LDP Downstream-on-Demand in Seamless MPLS' to Proposed Standard (draft-ietf-mpls-ldp-dod-09.txt)

[The IESG <[e-mail]>]

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.