LDP Downstream-on-Demand in Seamless MPLS
RFC 7032

Note: This ballot was opened for revision 09 and is now closed.

(Stewart Bryant) Yes

Comment (2013-08-05)
No email
send info
I am voting yes, but have one small comment that I am confident that Adrian will look at:

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

Remote LFA surely needs a reference as does PQ.

(Adrian Farrel) Yes

(Jari Arkko) No Objection

Comment (2013-08-12)
No email
send info
Has there been a response to Gen-ART review comments from Francis Dupont?

(Richard Barnes) No Objection

(Spencer Dawkins) No Objection

Comment (2013-08-09)
No email
send info
My understanding is that this draft is simply reducing the amount of state that access nodes need to keep, as a cost optimization, and does not introduce new TSV concerns because data plane traffic would end up in the same place if MPLS routers advertise MPLS labels for all valid routes in their RIB, as they would do if Downstream On Demand was not available.

As an aside, I've been reading MPLS-related drafts from time to time since the early 2000s, and found this one to be one of the clearest drafts I've seen. Good job!

One nit:

4.3.2.  Label Request Retry

   Following LDP specification LDP specification [RFC5036], if an access
   LSR/ABR receives a "No route" Notification in response to its Label
   Request message, it retries using an exponential backoff algorithm
   similar to the backoff algoritm mentioned in the LDP session

"algorithm"

   negotiation described in Section 4.2.

(Stephen Farrell) No Objection

Comment (2013-08-13)
No email
send info

- abstract:  "specific to access" reads oddly, "specific to
access networks" might be better

- abstract: "fast-up convergence" isn't that clear (but I
think I get it) - if there were a way to describe that in
plainer language that'd be nice

- I was surprised that the seamless draft is informative
and not normative. Not objecting, just surprised. 

- intro: "access border routers (access ABRs)" seems like
an oddly recursive acronym (a recursive RA:-), or maybe
just a typo?

- The security considerations section seems very thorough,
thanks! One question though - it wasn't clear to me if
there are any security mechanism(s) that are mandatory to
implement - can you clarify? It may well be that that's ok
for this document, and that adding some MTI security, if it
were needed, ought be done elsewhere, but it just wasn't
clear to me whether something here is MTI or not.

- Thanks for addressing the secdir reviewer's issues as
well.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2013-08-12)
No email
send info
I find this document to be quite informational indeed: well written, clear, and thorough.  Thanks for the good work.

Comment below has been addressed, and is retained here for posterity.

--------------------------------------------
From the shepherd writeup:

   There has been a dioscussion if this as a Standards Track 
   or should be Informational. Since the document specifies a new
   LDP TLV we have found that it needs to be on the Standrds track.

In fact, the registration policy for the LDP TLV Type Name Space registry is IETF Consensus (see RFC 5036, Section 4.2), and Informational would work perfectly well.  If that is the deciding reason the working group chose Standards Track over Informational, we should reconsider that now.

Adrian has clarified:
> I think in this case the document is describing a protocol extension to a
> standards track protocol. That extension is intended for wide-scale
> implementation and is neither a vendor-specific extension, not a description
> of how you use existing protocol mechanisms to achieve something. Thus,
> "standards track" was chosen not a requirement of the registry, but as a
> statement about the content of the document.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-08-13)
No email
send info
nicely done!