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

The IESG <> Thu, 22 August 2013 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D0CF11E822C; Thu, 22 Aug 2013 15:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.471
X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nZqRECVTwwQn; Thu, 22 Aug 2013 15:50:55 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 528E811E8234; Thu, 22 Aug 2013 15:50:51 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'LDP Downstream-on-Demand in Seamless MPLS' to Proposed Standard (draft-ietf-mpls-ldp-dod-09.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.70.p1
Message-ID: <>
Date: Thu, 22 Aug 2013 15:50:51 -0700
Cc: mpls mailing list <>, mpls chair <>, RFC Editor <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2013 22:50:57 -0000

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

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:

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

   The document has been reviewed as needed, the working
   group last call was brought to the attention of SG15 in

   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
              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.