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.