Subject: [mpls] Alexey Melnikov's Discuss on draft-ietf-mpls-rfc3107bis-02: (with DISCUSS and COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Aug 2017 08:22:03 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-mpls-rfc3107bis-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to discuss one issue before recommending approval of this document:

In Section 2.1:

   The value field of the Multiple Labels Capability (shown in Figure 1)
   consists of one or more triples, where each triple consists of four
   octets.  The first two octets of a triple specify an AFI value, the
   third octet specifies a SAFI value, and the fourth specifies a Count.
   If one of the triples is <AFI,SAFI,Count>, the Count is the maximum
   number of labels that the BGP speaker sending the Capability can
   process in a received UPDATE of the specified AFI/SAFI.

I think lack of recommendations on the minimal supported Count value will
result in lack of interoperability. What are the common Count values used by
implementations?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 1 Aug 2017 16:59:49 -0400

> DISCUSS:

An implementation is not required to support more than one label in the 
NLRI.  In that case, of course the Multiple Labels Capability is not  
supposed to be used.  So if the Capability is used, the minimum value is 
2.   It looks like the document does not state that explicitly, but it 
certainly should.  I will fix that.

Thus the literal answer to your question is that the Multiple Labels 
Capability MUST NOT contain a count less than 2.

Typically when SAFI-4 or SAFI-128 routes are used, only one label is 
included.  If an operator has a scenario in which multiple labels are 
needed, it is necessary for the operator to ensure that all his vendors 
can support however many labels he needs.  That's not really something 
that the standard can address.  If the operator needs 3 labels in the 
NLRI, it won't help much if some of his boxes can only support 2.

---------------------------------------------------------------------
> COMMENT:
Your arithmetic is accurate ;-)

If you are implying that this is not necessarily the best mechanism for 
associating an arbitrarily long label stack with a prefix, I wouldn't 
disagree.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 13:05:04 +0100

Hi Eric,
Sorry for the slow response.

On Tue, Aug 1, 2017, at 09:59 PM, Eric C Rosen wrote:
> that the standard can address. 

The standard can specify minimum requirement (and this has been done in
the past). For example you can say that all implementations must support
4 (or whatever).

> If the operator needs 3 labels in the 

Exactly my point. Without the minimum you still need to have out-of-band
selection of implementations that support your minimum requirements.

> associating an arbitrarily long label stack with a prefix, I wouldn't 

Yes, I was just surprised that this has such a small limit. I wanted to
make sure that this is by design.

Best Regards,
Alexey

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 17 Aug 2017 13:11:21 +0000

Hi Alexey,

See one comment below.

On 8/17/17, 8:05 AM, "mpls on behalf of Alexey Melnikov"
<[email-masked] on behalf of [email-masked]> wrote:

>> >       |                          Prefix
>>~
>> >       ~       
>>|

Note that there are more complex BGP encodings in IDR WG documents that
support larger label stacks.

https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-00.txt
https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt

This much-needed document simply clears up the ambiguities of advertising
multiple labels with the RFC 3107 NLRI encodings.

Thanks,
Acee

>
>Best Regards,
>Alexey
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 14:14:39 +0100

Hi Acee,

> multiple labels with the RFC 3107 NLRI encodings.

So just to double check: you are saying that this is cleaning up a
legacy specification and there are better/more modern specifications
that can do the same thing?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 17 Aug 2017 13:19:27 +0000

Hi Alexey, 

On 8/17/17, 9:14 AM, "Alexey Melnikov" <[email-masked]> wrote:

>> >> > I think lack of recommendations on the minimal supported Count
>>value
>> >>will
>> >> > result in lack of interoperability. What are the common Count
>>values
>> >>used by
>> >> > implementations?
>> >> 
>> >> >        0                   1                   2
>>  3

It is more complicated than that. There are other considerations with
using tunnel attributes and still others with SR policies. RFC 3107 NIS is
needed. 

Thanks,
Acee

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 17 Aug 2017 09:51:07 -0400

H Alexey,

In BGP, anything that is announced by a Capability is always optional.  
Per the draft, if one doesn't send the Multiple Labels Capability, one 
sends exactly one label in the NLRI.   So in that sense, the mandatory 
minimum value is 1.  I thought this part was clear from the first bullet 
point in Section 2.

When the Multiple Labels Capability is sent at session establishment 
time, I thought the new text:

"A triple of the form <AFI=x,SAFI=y,Count=0> or <AFI=x,SAFI=y,Count=1>
  MUST NOT be sent.  If such a triple is received, it MUST be ignored."

implied that the mandatory minimum value is 2, as that text precludes 
the use of the only smaller values.

If you think this isn't clear enough, I can some text like "Any 
implementation that sends a Multiple Labels Capability MUST be able to 
support at least two labels in the NLRI.  However, there may be 
deployment scenarios in which a larger number of labels is needed."

Would that be okay?

I wouldn't want to make the mandatory minimum any larger, because (a) 
some deployment scenarios might only require two labels, and (b) we 
don't want to have a larger mandatory minimum because the number of 
labels is not merely a control plane issue, but also affects the data 
plane.  E.g., if some platform can only push two labels at a time, 
there's no value to requiring it to support three labels in the control 
plane.

Eric

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 14:55:39 +0100

Hi Eric,

> minimum value is 1.  I thought this part was clear from the first bullet 

Yes, this part was clear.

> the use of the only smaller values.

I got that. I thought 2 was a rather low limit, but you made a good
explanation in this email, so I am Ok with that. So I will clear my
DISCUSS.

> deployment scenarios in which a larger number of labels is needed."

Probably not needed, but I am Ok if the above is added.