[Idr] Re: RFC 8277 clarifications

[Dmytro Shypovalov <[e-mail]>]

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