LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)
draft-ietf-l2vpn-vpls-ldp-mac-opt-13
Yes
(Adrian Farrel)
(Alia Atlas)
No Objection
(Alissa Cooper)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 12 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -12)
Unknown
Alia Atlas Former IESG member
Yes
Yes
(for -12)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -12)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -12)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2014-06-12 for -12)
Unknown
"Discussion with Sue about her OPS DIR review is still ongoing. Hope this will be fully resolved before the document is published." Below is the latest update received: Status: Not ready, but 80%-90% there. Short time with author and review should fix. ================================== Why: Operations issues not 100%. However, a few rounds of text change discussions should fix. Will engage with authors to complete the discussion. What’s good: 3.0 Overview - nice addition, section 5.1 and 5.2 Status: Technical issues: Problem 1: Negotiation is outside your context (to be considered) Description: Negotiation being outside your context does not mean you cannot flag that a flush has been part of a negotiated Flush entity. Have all users of MAC flush set a flag bit if the setting is negotiated. This may help you debugging of this feature distribution. Status: Do not see where this was completely or answers. Answer may be no/yes in the text – but I cannot tell. Authors simply need to tell me if looked at it – said not useful or X is wrong with the idea. Where saw change: Section 3.0 – positive MAC flushes must be always be handled. Section 3.2 – operator can choose optimized flush. Section 5.1.2 – States it applies when optimized flush is supported/no-supported. 5.1.3 specifies actions for optimized Flush. [What’s missing]: Operation section really doesn’t tie together the above changes, and make it easier for the reader to find the solution to problem 1 stated above. Since the authors are very good at this technology and good authors, I think it is simply an oversight that they will fix. If the authors wish to engage with a round of text, I’m glad to work toward this with the authors. Problem 2: fix in 5.2.1 : Very nice work on clear specification. Kudos to the Authors on careful description. This will really help interoperability. Status: fixed Style: Author used their current form rather than a numbered form. OK with reviewer. Editorial: MS-PW – is not defined. I still think it would be useful. Style – OK with reviewer. Problem 3: negotiation – Fall Back: if one side negotiates and expects this option, and the other side does not. Status: Greatly improved. Still does not tie it together with Section 6, para 1-3. It is 90% of the way there, but it still leaves a medium level reader trying to connect the dots. Really, this is the same comment as problem 1. I think the authors are 80-90% the way there, but I really cannot tie section back to the appropriate answers in previous sections. Great progress toward this is made all over the document. An analogy – I can see lines and dots and most of the picture, but it is still fuzzy here and there. Answer: I think a few rounds with the authors. Note: I will help the authors to resolve this comment quickly. Please me let me know if the authors sent email and I missed it. Problem 4: IANA – Looks fixed to me.
Brian Haberman Former IESG member
No Objection
No Objection
(for -12)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -12)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -12)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -12)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -12)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -12)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -12)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -12)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-06-12 for -12)
Unknown
- general: This draft has some acronyms that conflict with other ITEF things, specifically TLS and MTU. Those might be worth emphasising but I expect that you'd rather not, which is fine. I also found this a bit of a hard read, mostly due to a lack of background, so some of my comments may be off-base. - MTU-s - how "multi" tenant? Are there mutually mistrusting customers using the same node/host here? - Even with LDP authentication, isn't there the potential that an authenticated actor DoS'es others by causing their MAC addresses to be flushed? That seems to imply some form of authorization (e.g. mapping authenticated identities to MAC addresses) is required - is that defined somewhere else? If not, why doesn't it need to be defined here? If it does need to be defined here, you probably only need to say that such a mapping MUST be maintained. - section 3: I can't really parse this "This is accomplished by sending an LDP Address Withdraw Message from the PE that is no longer connected to the MTU-s with the primary PW, with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions [RFC4762]." Could you break it up to make it clearer?
Ted Lemon Former IESG member
No Objection
No Objection
(for -12)
Unknown