Return-Path: X-Original-To: idr@mail2.ietf.org Delivered-To: idr@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5A58D9048E66 for ; Tue, 25 Nov 2025 07:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=vegvisir.ie Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WawiSQc0m6AN for ; Tue, 25 Nov 2025 07:25:34 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D5AE89048E4F for ; Tue, 25 Nov 2025 07:25:34 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-644f90587e5so1902636a12.0 for ; Tue, 25 Nov 2025 07:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vegvisir.ie; s=google; t=1764084333; x=1764689133; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Passt6Xj1Kjg5OMNUhzW42ws1sg2BmZqyHVbF5EgkhE=; b=h/k5b9apZoVcAFJYFpp3oRkYj0xk+bjj1zWKpNLstciKVUaIOKnKy9GuIVhfGX8JSx DwWAYBeqDKqy36auRsa4fl/IK7GGYvOn1T+qgiddSocKp8stWM2UFhrGdz4n87BmomQ1 Lt7DnzG34kRi+6Qt1KVt6F+j0P5CUAlpIeVfWdpEUtmg4+CR92KuUF5JODQua5W0pgAk jM9qhbNnTNo8BhHxRTa8fLtBwEUjO3+R0juQ2FeFQxCGRfbbYNcj5saMMmGQuR2wURF2 cG4czWF2DFHJVcrauDPV+qgoDq0SkDKcxBjONYnaghYx8Huvh4fLsK+BukyUK/oDhlAN 8WgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764084333; x=1764689133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Passt6Xj1Kjg5OMNUhzW42ws1sg2BmZqyHVbF5EgkhE=; b=Wre4aei/IDgfLARR+xotGowmYJ8Ip2fRTceUWGQGZV2Y/4EtAd+CcPWER7oEoOvZSy pG6vMrrzvpdJh/xIPamypzR9yXxe9Pggppk1a5BNYULImEmydfRrEIT84UZkD5Iz3lB9 /1fVr8DIJKOK2nlzSG61dPllVa9tI+4+I4kBmgTgUrrhrGiDZK0VU22dUy52VKPs07Er MHo5egbqWVVZ4K57cs2A0Zu5t1h80Dk0JmgVfH+YBArOTZPdaBZLCGwXTJhN3o1lTSbd wHyzbBTG2kILeFWSSX5nvg93juvaNX2gnQox3vIEcTs7pNp/yIAdPZ1W2dF+P9iOSqTi IiYQ== X-Forwarded-Encrypted: i=1; AJvYcCVZaWfuLkEczxqnlZPlI8vaujsimeKk5OqSkpGIWjaEQQSJ8JUaCNisWKWHgDCY2frNG28=@ietf.org X-Gm-Message-State: AOJu0YwhfLvvAiC0zReAOKEMh1t51zILA0fApnD3lSc9ChzEbbKLk5bm qYZmZhk1CTKYWPjjdPK13hGPcFPxQv+UbA57ciqSfs+FqYixjuXbjTrH3dFV/zz+3RxSV/aQ5e9 uV1MDOCCL7AoW1VsCQunc9jzi+ACxuvRRyClA1TUkKYsqAGwoca92 X-Gm-Gg: ASbGncupIhI2QGiIpkSQhIJRA2cPk5rAClRW5hWgv/hbPqTOyNGz1fXz9SKhRU1YYYb CoXmHeE9Wlz+19tZeH7SseafuAbPATTPsHPNEmFiNLDAgV6lIrCpAzRkw1hkuCtmduG0N7GxtNN /b4bZw7Gq7jLPbT1g0vehSLcYV0pN8BsaDjE2CpPmfELu7/cxbkfTHBLHXMjLz9PSaChdBwTVi/ gb/NI8kPDGwYN3jzVcMBb73ZD3EovV8VK140NlnssP7MGK6x3WsdYZ8vO0V4WoyeSZXS4A= X-Google-Smtp-Source: AGHT+IF9qrR4cS4NI0Jvr+wIcfVV3B+jMDDAJjJauhMrmgkZru1Pp/tNRyIY0KqZWpNg9KzwjQhdYBeJ+SWkRd/0M9k= X-Received: by 2002:a05:6402:1ec8:b0:645:dc6b:40e with SMTP id 4fb4d7f45d1cf-645eb228c63mr3005841a12.9.1764084332974; Tue, 25 Nov 2025 07:25:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dmytro Shypovalov Date: Tue, 25 Nov 2025 15:25:20 +0000 X-Gm-Features: AWmQ_blbwNVXmhdNyZYPK8Z9tWypttFwh8su95HesF4onNBtA0RoOuSsWQ5ZLd0 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary="00000000000005624a06446ce400" X-MailFrom: dmytro@vegvisir.ie X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0 Message-ID-Hash: WRVFWHHOU6OYOSLIFXA6BPT2UW53H23U X-Message-ID-Hash: WRVFWHHOU6OYOSLIFXA6BPT2UW53H23U X-Mailman-Approved-At: Tue, 25 Nov 2025 08:03:39 -0800 CC: bruno.decraene@orange.com, Kyrylo Yatsenko , "idr@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_RFC_8277_clarifications?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000005624a06446ce400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Dmytro, > > Have you perhaps considered using MPLS Label Stack Sub-TLV as described i= n > section 3.6 of RFC9012 ? > > Thx, > Robert > > On Sun, Nov 23, 2025 at 2:08=E2=80=AFPM Dmytro Shypovalov > 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, man= y >> router implementations don't support BGP-SRTE and BGP-LU is a nice >> workaround that is widely supported. And it's definitely better than PCE= P >> (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 discover= ed >> this limitation, but it's never mentioned in the RFC. >> >> Regards, >> Dmytro >> >> On Thu, 20 Nov 2025 at 09:27, wrote: >> >>> Hi Dmytro, >>> >>> >>> >>> Thanks for your message. >>> >>> Please see inline my 2 cents >>> >>> >>> >>> *From:* Dmytro Shypovalov >>> *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 Coun= t >>> >>> 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=E2=80=A6 >>> >>> (note that at the time of RFC 3107, that was probably considered as goo= d >>> enough. To the point that some implementations did not even allow the >>> emission (fine) and reception (less fine=E2=80=A6) of more than one lab= el.) >>> >>> 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 t= o >>> 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 (rea= d >>> $$) from enough parties. >>> >>> In the meantime ( =F0=9F=98=89 ), 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 conf= identielles 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 message= s 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 b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >> Idr mailing list -- idr@ietf.org >> To unsubscribe send an email to idr-leave@ietf.org >> > --00000000000005624a06446ce400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,

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

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

=
Regards,
Dmytro

On Sun, 23 = Nov 2025 at 13:31, Robert Raszuk <r= obert@raszuk.net> wrote:
Hi Dmytro,

Have you per= haps considered using MPLS Label Stack Sub-TLV as described=C2=A0in section= 3.6 of RFC9012 ?

Thx,
Robert

On Su= n, Nov 23, 2025 at 2:08=E2=80=AFPM Dmytro Shypovalov <dmytro@vegvisir.ie> wrote:
=
Hi= Bruno, thanks for your response.

BGP-SRTE is definitely= a more superior protocol and as an SR-TE controller developer, I always pr= efer it whenever possible. However, many router implementations don't s= upport BGP-SRTE and BGP-LU is a nice workaround that is widely supported. A= nd it's definitely better than PCEP (anything is better than PCEP).=C2= =A0

I just wanted to clarify this behaviour, becau= se the discussion came up when Kyrylo was implementing multiple labels supp= ort in FRR and discovered this limitation, but it's never mentioned in = the RFC.

Regards,
Dmytro

=
On Thu, 20= Nov 2025 at 09:27, <bruno.decraene@orange.com> wrote:

Hi Dmytro,

=C2=A0

Thanks for your message.=

Please see inline my 2 cents=

=C2=A0

From: Dmytro Shypovalov <dmytro@vegvisir.ie>
Sent: Wednesday, November 19, 2025 11:19 PM

=C2=A0

Dear IDR WG,<= /u>

=C2=A0

I've been working o= n an SR-TE project using BGP-LU to influence traffic engineering paths. Thi= s requires the advertisement of multiple labels.

=C2=A0

RFC8277 seems to have 2= conflicting statements

=C2=A0

Section 2.1:<= /u>

=C2=A0 

=C2=A0=C2=A0 the Count is the maximum<=
/u>
=C2=A0=C2=A0 number of labels that the BG=
P speaker sending the Capability can
=C2=A0=C2=A0 process in a received UPDATE=
 of the specified AFI/SAFI.=C2=A0 If the Count
=C2=A0=C2=A0 is 255, then no limit has be=
en placed on the number of labels that
=C2=A0=C2=A0 can be processed in a receiv=
ed UPDATE of the specified AFI/SAFI.

=C2=A0

This assumes the BGP up= date can have up to 255 labels (in theory).

=C2=A0

This probably needs to be read = as an additional limit. (in addition to some other constraints, e.g., the o= ne you described below)

We need to consider that BGP LU= was originally specified in RFC 3107. That BGP capability has been added b= y 8277 as a patch, mostly to accommodate some non-compliant implementations= if you ask me.

=C2=A0

Section 2.3:<= /u>

=C2=A0 

=C2=A0=C2=A0 - Length:

=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Length=
 field consists of a single octet.=C2=A0 It specifies the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 length in =
bits of the remainder of the NLRI field.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note that =
for each label, the length is increased by 24 bits (20


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bits in th=
e Label field, plus 3 bits in the Rsrv field, plus 1 S


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bit).

=C2=A0

If we use BGP-LU with m= ultiple 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 I= Pv4 and 5 labels for IPv6. The RFC message format will not be able to support mor= e labels, regardless of platform capabilities.

=C2=A0

Alas=E2=80=A6

(note that at the time of RFC 3= 107, that was probably considered as good enough. To the point that some im= plementations did not even allow the emission (fine) and reception (less fi= ne=E2=80=A6) of more than one label.)

RFC 8277 could have revisited a= few things, but did not (presumably to minimize the impact on existing imp= lementation, among other things)

=C2=A0

Bu= t I've seen vendor implementations advertising multi label capability w= ith more labels.

=C2=A0

Cf above: we should probably as= sume that the minimum of all limits is to be used: min (capability sig, enc= oding space)

=C2=A0

Am I missing something?= Is there a way to advertise more labels in BGP-LU?

=C2=A0

I guess that we could always de= fine a new spec to revisit the whole thing, but that would imply a large ef= fort and sufficient interest (read $$) from enough parties.

In the meantime ( = =F0=9F=98=89 ), have you considered the adverti= sement of SR Policies in BGP https://datatracker.ietf.org/doc/html/rfc9830 ?

=C2=A0

Regards,

--Bruno

=C2=A0

=C2=A0

Regards,<= /p>

Dmytro 

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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 -- idr@i= etf.org
To unsubscribe send an email to idr-leave@ietf.org
--00000000000005624a06446ce400--