Using BGP to Bind MPLS Labels to Address Prefixes

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

Alia Atlas Yes

Deborah Brungard Yes

Ben Campbell No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2017-08-17 for -03)
Thank you for working to address my DISCUSS.

In Section 2.3:

      0                   1                   2                     3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |    Length     |
     |                 Label                 |Rsrv |S~
     ~                 Label                 |Rsrv |S|
     |                          Prefix                               ~
     ~                                                               |

                    Figure 3: NLRI With Multiple Labels

   - Length:

      The Length field consists of a single octet.  It specifies the
      length in bits of the remainder of the NLRI field.

I would like to double check that my math is correct. With SAFI=128 and AFI=2,
assuming the prefix length of 192 bits, this will leave space for:

 (255-192)/24 = 2.625. So this configuration only allows for 2 labels to be included, right?

Kathleen Moriarty No Objection

Comment (2017-08-02 for -02)
The security considerations section should at least mention that none of the tunnel methods provide encryption or authentication of those mentioned earlier in the document (Section 4: LSP, IP, GRE, & UDP).  Although this isn't listed as a discuss, I'd appreciate the comment being addressed with an update to the text (1-2 sentences at most).  Thank you.

Eric Rescorla No Objection

Comment (2017-08-02 for -02)
Document: draft-ietf-mpls-rfc3107bis-02.txt

S 2.1
I note that you use 255 to mean "any number of labels" and 0 is marked
ignore. Is there a reason not to use 255 as a concrete number and 0
to mean "any number"? This is just for my information.

S 2.3.
      Note that failure to set the S bit in the last label will make it
      impossible to parse the NLRI correctly.  See Section 3 paragraph j
      of [RFC7606] for a discussion of error handling when the NLRI
      cannot be parsed.

It would be helpful if you explicitly said that you parse this value
by reading labels one at a time until you get a non-zero S bit. It's
implicity, but having it be clear would be nice.