Skip to main content

LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-09

Yes

(Adrian Farrel)

No Objection

(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)

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

Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Stewart Bryant Former IESG member
Yes
Yes (2013-08-05) Unknown
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.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-08-12) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2013-08-12) Unknown
Has there been a response to Gen-ART review comments from Francis Dupont?
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-08-13) Unknown
nicely done!
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-08-09) Unknown
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 Former IESG member
No Objection
No Objection (2013-08-13) Unknown

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