Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03
Yes
(Stewart Bryant)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2014-02-16)
Unknown
The last paragraph of Section 1 begins: In order to use the mLDP in-band signaling procedures... ...but "the mLDP in-band signaling" is a new term. It turns out that it meas exactly what the previous paragraph ended up saying, viz. encoded into the mLDP FEC element. So I suggest that you update the end of the previous paragraph to read encoded into the mLDP FEC element in what this document terms "mLDP in-band signaling."
Stewart Bryant Former IESG member
Yes
Yes
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-02-17)
Unknown
No objection, and no complaint at all here... just an observation: I find it interesting that an 11-page document has six authors.
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-20)
Unknown
Thanks for the discussion on the handling of scoped IPV6 scoped multicast addresses. Moved to a COMMENT for historical reasons... I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC 6826 so let's discuss it here for the time being... How are non-global-scoped IPv6 multicast addresses handled? There is no discussion in this document about verifying that the creation of an MDT is not violating a scope boundary. RFC 4007 (section 10) is very clear on the rules that must be followed when creating forwarding state. If these rules are not followed, scoped packets can leak out of their allowed zone creating a vulnerability. Notionally, I would have expected to see something in Section 2 saying that scopes need to be checked as a part of the signaling procedure. There does not appear to be any discussion of scoped addresses in 6513, 6512, or 6826. Where in the MPLS VPN specs is support for scoped multicast addresses defined?
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
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
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-20)
Unknown
It seems kind of incredible that the security considerations here are so simple, when we're glueing together two different ways to do multicast. Surely at least the security considerations relevant to PIM ought be noted? Would it (un)fair of me to guess that perhaps nobody has really looked for potential new vulnerabilities here? As it happens, I don't have the time before the telechat, nor probably the MC clue, to help with that so this is not a DISCUSS, but you could set my mind at rest if you told me that yes, a bunch of folks with that clue and some security clue have really spent time looking at this.
Ted Lemon Former IESG member
No Objection
No Objection
()
Unknown