Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-mldp-in-band-signaling-08
Yes
(Adrian Farrel)
(Ron Bonica)
(Stewart Bryant)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Sean Turner)
(Wesley Eddy)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -07)
Unknown
Ron Bonica Former IESG member
Yes
Yes
(for -07)
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(for -07)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2012-11-12 for -07)
Unknown
A very small point, which you can absolutely ignore if you don't think there's anything wrong: In newspaper parlance, one would say that the Abstract "buries the lede". The key point -- what this document is about -- doesn't come until the last sentence, only after a bunch of "suppose you have this," and "after this happens," and so on. Can you find a way to lead with the last sentence, and re-cast the abstract from there? -- Section 3 -- In the figures in these subsections... maybe this is just me, maybe this is how all the MPLS diagrams are, and maybe it's not a problem at all. In which case, just ignore this also. But look at 3.1, for example: Type: 3 (to be assigned by IANA). Length: 8 octets Source: IPv4 multicast source address, 4 octets. Group: IPv4 multicast group address, 4 octets. You say "8 octets" for "Length", and "4 octets" for "Source"... but you mean two different things. For Source, you mean that the field is 4 octets in size. For Length, you mean that the *value* in the field is 8 -- the field itself is 2 octets in size. That inconsistency bothers me. Might it be better to do it somewhat like this?: NEW - choice 1 Type: 3 (to be assigned by IANA). Length: 8 (octet size of Source and Group fields) Source: IPv4 multicast source address, 4 octets. Group: IPv4 multicast group address, 4 octets. NEW - choice 2 Type: 3 (to be assigned by IANA). Length: 8 (octet size of the remainder of the TLV) Source: IPv4 multicast source address, 4 octets. Group: IPv4 multicast group address, 4 octets. ...and similarly for Sections 3.2 thru 3.4.
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(for -07)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -07)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-11-15 for -07)
Unknown
The Gen-ART Review by Suresh Krishnan on 13-Nov-2012 raised a non-blocking question: The draft has the pre-5378 boilerplate but it is unclear to me why. I went through the older versions to find draft-wijnands but that was submitted first in 2009. Is this really necessary?
Sean Turner Former IESG member
No Objection
No Objection
(for -07)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-11-15 for -07)
Unknown
(1) and (2) were originally discusses, I've left in the text but added comments from the mail exchange below each. (1) I'm skeptical that there are no security considerations beyond those in 5036. As I read it, you are taking addresses and masks from PIM messages and maybe creating LSPs based on those, so its hard to believe there's no way to muck with PIM messages to create a new bad effect for the MPLS n/w. Can you point me at where the WG considered this and concluded that there is in fact nothing new here? So if badness can happen to the PIM n/w when it connects via MPLS, it'd be good to describe that. (2) RFCs 4607 and 4601 seem to depend on IPsec as a countermeasure, and I'm not sure that e.g. LSR (D) in figure 1 would be able to see anything much if ESP were in use to protect PIM messages, or is AH really used here? If AH is not used, but ESP is, or if IPsec is not used at all, that would seem to imply that all of the security considerations of 4607 and 4601 also come into play but without being able to depend on IPsec as a useful countermeasure, which'd imply that more text is needed here (or somewhere). Am I right there? (It could be that expectations when 460[17] were written were optimistic, but if that's the case we ought recognise reality and not depend on what turned out to be bad predictions.) RFCs 5294 and 5796 (which updates 4601) might also have relevant security considerations - were those taken into account here? Turns out it wasn't clear to me that (D) in figure 1 has to be a PIM speaker and part of the IPsec SA with (B) which, if true, means that ESP would be fine. If that's right then making it clear would be good, e.g. say that (D) has to share an IPsec SA with (B) if PIM security based on IPsec is to be of use. --- original comment below - typo: speccial - section 3, is opaque really a good term here when you're defining the internal structure? If that's inherited from elsewhere maybe just say that they're not opaque in this context. Or perhaps s/transit opaque/transit-opaque/ is right? - 3.3 & 3.4 - can't you specify a max for Mask Len for each of these? Why not do that?
Wesley Eddy Former IESG member
No Objection
No Objection
(for -07)
Unknown