Using BGP to Bind MPLS Labels to Address Prefixes
RFC 8277

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)
No email
send info
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)
No email
send info
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)
No email
send info
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.