Skip to main content

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