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

["Acee Lindem (acee)" <[e-mail]>]

Hi Alexey,

See one comment below.

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

>Hi Eric,
>Sorry for the slow response.
>
>On Tue, Aug 1, 2017, at 09:59 PM, Eric C Rosen wrote:
>> 
>> > 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?
>> 
>> 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.
>
>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
>> NLRI, it won't help much if some of his boxes can only support 2.
>
>Exactly my point. Without the minimum you still need to have out-of-band
>selection of implementations that support your minimum requirements.
>
>> ---------------------------------------------------------------------
>> > 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?
>> >
>> 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.
>
>Yes, I was just surprised that this has such a small limit. I wanted to
>make sure that this is by design.

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls