Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
RFC 7246

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

(Stewart Bryant) Yes

(Adrian Farrel) Yes

Comment (2014-02-16)
No email
send info
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."

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2014-02-20)
No email
send info
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.

(Brian Haberman) (was Discuss) No Objection

Comment (2014-02-20)
No email
send info
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?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-02-17)
No email
send info
No objection, and no complaint at all here... just an observation:
I find it interesting that an 11-page document has six authors.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection