[Idr] Re: RFC 8277 clarifications

[Robert Raszuk <[e-mail]>]

Hi Dmytro,

Have you perhaps considered using MPLS Label Stack Sub-TLV as described in
section 3.6 of RFC9012 ?

Thx,
Robert

On Sun, Nov 23, 2025 at 2:08 PM Dmytro Shypovalov <[e-mail]>
wrote:

> Hi Bruno, thanks for your response.
>
> BGP-SRTE is definitely a more superior protocol and as an SR-TE controller
> developer, I always prefer it whenever possible. However, many router
> implementations don't support BGP-SRTE and BGP-LU is a nice workaround that
> is widely supported. And it's definitely better than PCEP (anything is
> better than PCEP).
>
> I just wanted to clarify this behaviour, because the discussion came up
> when Kyrylo was implementing multiple labels support in FRR and discovered
> this limitation, but it's never mentioned in the RFC.
>
> Regards,
> Dmytro
>
> On Thu, 20 Nov 2025 at 09:27, <[e-mail]> wrote:
>
>> Hi Dmytro,
>>
>>
>>
>> Thanks for your message.
>>
>> Please see inline my 2 cents
>>
>>
>>
>> *From:* Dmytro Shypovalov <[e-mail]>
>> *Sent:* Wednesday, November 19, 2025 11:19 PM
>>
>>
>>
>> Dear IDR WG,
>>
>>
>>
>> I've been working on an SR-TE project using BGP-LU to influence traffic
>> engineering paths. This requires the advertisement of multiple labels.
>>
>>
>>
>> RFC8277 seems to have 2 conflicting statements
>>
>>
>>
>> Section 2.1:
>>
>>
>>
>>    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.  If the Count
>>
>>    is 255, then no limit has been placed on the number of labels that
>>
>>    can be processed in a received UPDATE of the specified AFI/SAFI.
>>
>>
>>
>> This assumes the BGP update can have up to 255 labels (in theory).
>>
>>
>>
>> This probably needs to be read as an additional limit. (in addition to
>> some other constraints, e.g., the one you described below)
>>
>> We need to consider that BGP LU was originally specified in RFC 3107.
>> That BGP capability has been added by 8277 as a patch, mostly to
>> accommodate some non-compliant implementations if you ask me.
>>
>>
>>
>> Section 2.3:
>>
>>
>>
>>    - Length:
>>
>>
>>
>>       The Length field consists of a single octet.  It specifies the
>>
>>       length in bits of the remainder of the NLRI field.
>>
>>
>>
>>       Note that for each label, the length is increased by 24 bits (20
>>
>>       bits in the Label field, plus 3 bits in the Rsrv field, plus 1 S
>>
>>       bit).
>>
>>
>>
>> If we use BGP-LU with multiple labels for SR-TE, it will always advertise
>> host routes, which given max 255 bits of NLRI, leaves us with theoretical
>> maximum of 9 labels for IPv4 and 5 labels for IPv6. The RFC message
>> format will not be able to support more labels, regardless of platform
>> capabilities.
>>
>>
>>
>> Alas…
>>
>> (note that at the time of RFC 3107, that was probably considered as good
>> enough. To the point that some implementations did not even allow the
>> emission (fine) and reception (less fine…) of more than one label.)
>>
>> RFC 8277 could have revisited a few things, but did not (presumably to
>> minimize the impact on existing implementation, among other things)
>>
>>
>>
>> But I've seen vendor implementations advertising multi label capability
>> with more labels.
>>
>>
>>
>> Cf above: we should probably assume that the minimum of all limits is to
>> be used: min (capability sig, encoding space)
>>
>>
>>
>> Am I missing something? Is there a way to advertise more labels in BGP-LU?
>>
>>
>>
>> I guess that we could always define a new spec to revisit the whole
>> thing, but that would imply a large effort and sufficient interest (read
>> $$) from enough parties.
>>
>> In the meantime ( 😉 ), have you considered the advertisement of SR
>> Policies in BGP https://datatracker.ietf.org/doc/html/rfc9830 ?
>>
>>
>>
>> Regards,
>>
>> --Bruno
>>
>>
>>
>>
>>
>> Regards,
>>
>> Dmytro
>>
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>