[Idr] Re: RFC 8277 clarifications

[Dmytro Shypovalov <[e-mail]>]

Hi Robert,

Yes I use the RFC9012 tunnel encap attribute together with BGP-SRTE
(RFC9830).

Do you suggest it can be also used together with BGP-LU (RFC3107/RFC8277)?
Are there any vendor implementations supporting that?

Regards,
Dmytro

On Sun, 23 Nov 2025 at 13:31, Robert Raszuk <[e-mail]> wrote:

> 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]
>>
>