[Idr] Re: RFC 8277 clarifications

[Robert Raszuk <[e-mail]>]

Well I don't think there is any vendor supporting what you are trying to
accomplish anyway :)

But as Bruno hinted about inventing a new protocol extension I thought you
may want to leverage existing one.

Cheers,
R.

On Tue, Nov 25, 2025 at 4:25 PM Dmytro Shypovalov <[e-mail]>
wrote:

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