Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B35C1D52E0; Mon, 9 Dec 2024 08:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzc5NHRPnsdH; Mon, 9 Dec 2024 08:28:58 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 84803C1D52F5; Mon, 9 Dec 2024 08:28:58 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-2164b1f05caso11874625ad.3; Mon, 09 Dec 2024 08:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733761738; x=1734366538; 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=37IVxZkRxwPgrFnr1UfIvAp+hNpn3+wUUDzaCbe4Lag=; b=TXiufus+F9MJgHrbA592wVVAUcUxCyYenjs9jv65HjOB0hjd+qNWQzZ6N6x2uyF3mv D2S/vYN807IzVzSwpqyBGS/lAmhWgPMid3LUC6x0Ra5LC8JZuOTyTxs0XWQcNmB4+pPz 7BfPogfNXZzzEq3/qWfhpArExnve/l48y1lQosbPGF1fZPNQ+JrTIguJnWsYB/Fq8+nX x3wgMVK547Uzm9e0/hneN1DhItyrkJmH9bdFmZDTOxgvmFzC4X1uaHNT+tRDdO9cPwve Rrb1SDGAROLyiNCas9GAqct2QYNCCsFz77EEZUWCihdYD+td+WX4Haw/NoDRawIM8T6K LA6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761738; x=1734366538; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=37IVxZkRxwPgrFnr1UfIvAp+hNpn3+wUUDzaCbe4Lag=; b=tE6IbX4P22WNZOKcduPuk0dtUAfdcG4NKMTlAREVQEEX5vN4xj/XZYHaHuxO72cHBn F1JvHERMETPknec5MCgAsENPYWqnU3Z7Yj6dO9N4z2CfR8bo41gncMYEhV6jH/K2CMwo F5S1tDWzW6cXW8ucWamRG4wrfqZfDivweFIJuQpLnTSxZac+6xBT1GqP5JP1Mv6ea4I6 WLANr6nS4mgowdgPA+W3VwZpjOyAIogwHpTFaJwm1B7gpM1wk7cOumTi241y+Dv8cUKp JerEcS9b7zSiqj6vVfAbMMM6tI1tqjL68ujdSOWSi/TqD9LNzuPINaFqSB0mWK5YmnTN h7zQ== X-Forwarded-Encrypted: i=1; AJvYcCUWtwXThd5ONKug6wUG0fpDiWEOmiUnufo9/L3htHlAKXO32GnMPVY+bC7UstsXzqwVj1EMvaKsFp66ww==@ietf.org, AJvYcCUrwQ1+DMtzCd9MEAz+ulC0vaINxLnNDPD9wr0ft8oPY5s/luVDgSlLTWDtfBgk0CaXGFy+WAthWFnjLx11F+SKygz+yI20T3ZTJQCRzz4=@ietf.org, AJvYcCVWdMRXJZ8W4iPope3Glmy1WSXcfteeP1rErCJATNQbb+EY36I7a6aTpTXlHgtAAeORn+gwlw==@ietf.org X-Gm-Message-State: AOJu0YwvhAm0Y6Mj4bIBogy00ldY4lqMKExOPbOSbaNowdLe8sdg2V53 wfMELcE++E8SI30oh/guSDM06yVzVGHtbTLvnoJvMVaOYItxwwJB5HrWgdk94GKRUDEUrPpq7Dz Nazm0VRUKxLWP8TJC/X2urVEc1MbIemOr X-Gm-Gg: ASbGnctbntfOCJeYvIOeDm9RTKJW7O1zuFeu0Ss70PMIGPIHjfX9qj/Y0BmGQ81RgXa +PLVbBbpAMlsU4VPB2uv9z8odRRLUH9579H6j4Gk6hFE= X-Google-Smtp-Source: AGHT+IF9NWk9Z2pTcI5NCULJpelDhJiYfl4evKyg72U/39WToQyBuRXko23tH+YlK60sts8NqAeGl/LJ5cr/9mRDADo= X-Received: by 2002:a17:902:d4ca:b0:215:6816:632e with SMTP id d9443c01a7336-21614dcbc3cmr192699345ad.48.1733761737621; Mon, 09 Dec 2024 08:28:57 -0800 (PST) MIME-Version: 1.0 References: <173062996677.426998.2534209820011949359@dt-datatracker-84cf84bdcc-hlxgg> In-Reply-To: From: Ketan Talaulikar Date: Mon, 9 Dec 2024 21:58:44 +0530 Message-ID: To: =?UTF-8?Q?Luc_Andr=C3=A9_Burdet?= Content-Type: multipart/alternative; boundary="0000000000007f09240628d8dc1e" Message-ID-Hash: KCMRMA3GGYMOGIWEGHW7KTIPCSGQNT7W X-Message-ID-Hash: KCMRMA3GGYMOGIWEGHW7KTIPCSGQNT7W X-MailFrom: ketant.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Jorge Rabadan (Nokia)" , "Jeffrey (Zhaohui) Zhang" , Wen Lin , "bess-chairs@ietf.org" , "draft-ietf-bess-bgp-srv6-args@ietf.org" , BESS X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_draft-ietf-bess-bgp-srv6-args_missing_on_BESS_wik?= =?utf-8?q?i?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000007f09240628d8dc1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luc/All, As we've discussed earlier on this thread, this draft is limited to the SRv6 signaling aspect and does not change anything with respect to other aspects such as multihoming and the usage of Ether AD per ES Route type. Yet another text proposal for consideration: NEW When ESI Filtering is not in use, there is no ESI Filtering ARG to be conveyed. *However, the advertisement of this route SHOULD include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID with the value ::0 in the SRv6 SID Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M for backward compatibility and consistency with [RFC9252].* Since the End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be included, and as no ARG value needs to be signaled, the AL MUST be set to 0. Does this work for everyone? Thanks, Ketan On Mon, Dec 9, 2024 at 8:02=E2=80=AFPM Luc Andr=C3=A9 Burdet wrote: > Jeffrey, all, > > > > I find the change to =E2=80=9Cif this route is advertised=E2=80=9D to be = imprecise: =E2=80=98if=E2=80=99 > implies EtherA-D per ES is an optional route, incl for multihoming. > > I disagree this change is needed and the original text was fine =E2=80=93= this > draft is about the args presence or encoding on a route, not whether or n= ot > it is to be advertised: that is covered already in the various > service/multihoming drafts, and should be left there. > > > > For reference, the use of ESI Filtering itself (vs. Local-bias) is in the > EtherA-D per ES ( > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-split-horiz= on-11#section-2.2), > adding ambiguity to that advertisement here doesn=E2=80=99t make sense. T= he plain > reading of the new statement is that the EtherA-D per ES does not need to > be advertised if ESI-Filtering is not used. > > > > Regards, > > Luc Andr=C3=A9 > > > > Luc Andr=C3=A9 Burdet | Cisco | laburdet.ietf@gmail.com | Tel: +1 61= 3 254 > 4814 > > > > > > *From: *Jorge Rabadan (Nokia) > *Date: *Friday, December 6, 2024 at 08:03 > *To: *Jeffrey (Zhaohui) Zhang , Ketan Talaulikar < > ketant.ietf@gmail.com> > *Cc: *Wen Lin , bess-chairs@ietf.org < > bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org>, BESS > *Subject: *[bess] Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > Hi Jeffrey, > > > > I didn=E2=80=99t think the second red text was necessary, but I don=E2=80= =99t have a > strong opinion about it and I=E2=80=99m ok if Ketan/Wen are good. > > Other than that, a small typo in the NEW text: > > > > NEW: > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, if this route is advertised, it SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M > > for backward compatibility or consistency considerations. Since the > > End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub- > > sub-TLV MUST be included, and as no ARG value needs to be signaled, > > the AL MUST be set to 0. > > > > i.e., remove =E2=80=9Cis carried=E2=80=9D > > > > Thanks. > > Jorge > > > > > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Thursday, December 5, 2024 at 2:47=E2=80=AFPM > *To: *Ketan Talaulikar > *Cc: *Jorge Rabadan (Nokia) , Wen Lin < > wlin@juniper.net>, bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org>, BESS > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Hi Ketan, Jorge, Wen, > > > > To clarify, I would like to see the following changes: > > > > OLD: > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, *the advertisement of this route* SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > *The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service* > > * TLV indicates support for SRv6 as specified in [RFC9252].* Since the > > End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub- > > sub-TLV MUST be included, and as no ARG value needs to be signaled, > > the AL MUST be set to 0. > > > > NEW: > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, if this route is advertised, it SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M > > for backward compatibility or consistency considerations. Since the > > End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub- > > sub-TLV MUST be included, and as no ARG value needs to be signaled, > > the AL MUST be set to 0. > > > > Please let me know if this is ok. If you still strongly believe the secon= d > red text is not correct, please also let me know. Either way, I will > start the WGLC process after hearing from you and seeing at least the fir= st > red change. > > > > Thanks. > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Jeffrey (Zhaohui) Zhang > *Sent:* Tuesday, November 26, 2024 2:04 PM > *To:* Ketan Talaulikar > *Cc:* Jorge Rabadan (Nokia) ; Wen Lin < > wlin@juniper.net>; bess-chairs@ietf.org; > draft-ietf-bess-bgp-srv6-args@ietf.org; BESS > *Subject:* RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > Hi Ketan, > > > > That addresses part of my of concern. > > > > Remember that this started with my question =E2=80=9Cwhy is =E2=80=98SHOU= LD=E2=80=99 used here=E2=80=9D. > The answer was: > > KT> The reason is provided in the next sentence "The presence of BGP > Prefix-SID Attribute carrying an SRv6 L2 Service TLV indicates support fo= r > SRv6 as specified in [RFC9252 > > ]." > > After a long discussion, now my understanding is that it=E2=80=99s not re= ally to > =E2=80=9Cindicate SRv6 support=E2=80=9D =E2=80=93 because the MAC/IP rout= es and the AD per EVI > routes are sufficient in that already =E2=80=93 it=E2=80=99s really for b= ackward > compatibility/consistency (perhaps it is more for consistency than for > compatibility =E2=80=93 unless an existing implementation stops working i= f it does > not see the SID ::0 advertised). > > > > This may seem a nitpick, but since it took us quite some time to arrive a= t > this conclusion (I hope we have a consensus now), I=E2=80=99d rather see = the spec > document it properly. > > > > Therefore, I would like to see the rest of that paragraph as follows: > > > > for backward compatibility or consistency considerations. =C3=9F new > > The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service > =C3=9F deleted > > TLV indicates support for SRv6 as specified in [RFC9252]. > > Thanks. > > Jeffrey > > > > *From:* Ketan Talaulikar > *Sent:* Monday, November 25, 2024 8:39 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* Jorge Rabadan (Nokia) ; Wen Lin < > wlin@juniper.net>; bess-chairs@ietf.org; > draft-ietf-bess-bgp-srv6-args@ietf.org; BESS > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > This draft is not getting into all the scenarios when the Route Type 1 is > advertised and its usage - that would be outside the scope of this docume= nt. > > > > Does the following text change address your concerns? > > > > > OLD > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, the advertisement of this route SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > > > NEW > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, *if this route is advertised, it *SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > > > > > Thanks, > > Ketan > > > > > > On Mon, Nov 25, 2024 at 6:29=E2=80=AFPM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net> wrote: > > [+ BESS mailing list] > > > > Hi Jorge, > > > > Please see zzh> below. > > > > > > Juniper Business Use Only > > *From:* Jorge Rabadan (Nokia) > *Sent:* Friday, November 22, 2024 4:05 PM > *To:* Wen Lin ; Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net>; Ketan Talaulikar > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Also, I see where you are coming from, thanks for explaining, however: > > > > Zzh> The spec needs to be clear whether the ESI-0 A-D per ES route is > needed for EVPN/EVPN-VPWS when multi-homing is not used. My understanding > is that it is not needed. > > > > =E2=80=9Cbut as you said =E2=80=9CI don=E2=80=99t see the need to signal = the support of SRv6 as a > generic capability at the PE level=E2=80=9D=E2=80=9D > > > > True, but you still need to signal the encapsulation at the EVPN update > level. That is the case ever since RFC8365. And if you don=E2=80=99t add = the > encapsulation in the route, the default encapsulation is really MPLS (sin= ce > there was no encap signaled in RFC7432). So things could have been > different, yes, but it was decided to always signal the encapsulation wit= h > the EVPN routes. And that is the reason for the red text. > > > > We should really not change existing deployments. > > > > Zzh> Even when MH is used, the A-D per EVI routes, IMET and MAC/IP routes > have sufficient encapsulation information. Adding that to the per-ES rout= e > is really like an appendix. I can understand you want to do it for backwa= rd > compatibility and/or consistency reasons =E2=80=93 so I suggest the follo= wing text: > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, in the case of EVPN/EVPN-VPWS multihoming =C3= =9F new > > or E-TREE, the advertisement of this route SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M > > for backward compatibility or consistency considerations. =C3=9F ne= w > > The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service > =C3=9F deleted > > TLV indicates support for SRv6 as specified in [RFC9252]. > > > > Zzh> Does that make sense? This whole discussion started with my question > =E2=80=9Cwhy =E2=80=98SHOULD=E2=80=99 is used=E2=80=9D. BTW, when this do= cument goes through more reviews, > there may be questions like =E2=80=9Cwhat if it is not included=E2=80=9D = (people like to > ask that question with the SHOULD keyword). > > Zzh> Thanks. > > Zzh> Jeffrey > > > > Thanks! > > Jorge > > > > > > > > Juniper Business Use Only > > *From: *Wen Lin > *Date: *Friday, November 22, 2024 at 12:19=E2=80=AFPM > *To: *Jeffrey (Zhaohui) Zhang , Jorge Rabadan (Nokia) > , Ketan Talaulikar > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > > for additional information. > > > > Hi Jeffrey, > > > > I raised a good point regarding the definition of RT for ES per AD route > when ESI value is 0. You=E2=80=99re right that it is operated at the PE = scope > instead of individual multihomed ES scope. > > However, we left to each individual draft or RFC that uses such a route > to specify the appropriate RT as this draft does not intent to alter any > existing definitions or practices. > > > > Thanks, > > Wen > > > > > > Juniper Business Use Only > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Friday, November 22, 2024 at 2:49=E2=80=AFPM > *To: *Jorge Rabadan (Nokia) , Wen Lin < > wlin@juniper.net>, Ketan Talaulikar > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > Hi Jorge, > > > > Here is what I think, point by point: > > =C2=B7 If we do not need to signal =E2=80=9CI am using SRv6=E2=80= =9D, then all of the > following text should be removed. I was told that purpose of the text is = to > show the support of SRv6 (but as you said =E2=80=9CI don=E2=80=99t see th= e need to signal > the support of SRv6 as a generic capability at the PE level=E2=80=9D. The= signaling > does not convey any information if we do not need to signal =E2=80=9CI am= using > SRv6=E2=80=9D, and an ingress PE will use argument if and only if it is s= ignaled in > the type-1 route. > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, the advertisement of this route SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service > > TLV indicates support for SRv6 as specified in [RFC9252]. Since the > > End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub- > > sub-TLV MUST be included, and as no ARG value needs to be signaled, > > the AL MUST be set to 0. > > > > Following is an example representation of the BGP Prefix-SID > > Attribute encoding in this case: > > > > BGP Prefix SID Attr: > > SRv6 L2 Service TLV: > > SRv6 SID Information sub-TLV: > > SID: ::0 > > Behavior: End.DT2M > > SRv6 SID Structure sub-sub-TLV: > > LBL: 32, LNL: 16, FL: 16, AL: 0, TPOS-L: 0, TPOS-O: 0 > > > > Figure 1: EVPN Route Type 1 without ARG for ESI Filtering > > > > =C2=B7 If we do need to signal =E2=80=9CI am using SRv6=E2=80=9D, t= hen because RFC7432 > does not talk about ESI-0 type-1 routes for regular EVPN, we need to call > it out that we=E2=80=99re using ESI-0 type-1 route (when there is no MHES= ) to > signal =E2=80=9CI am using SRv6=E2=80=9D, and we need to say what RT to u= se =E2=80=93 it=E2=80=99s an RT > that gets the ESI-0 route to every PE. > > Jeffrey > > > > > > > > Juniper Business Use Only > > *From:* Jorge Rabadan (Nokia) > *Sent:* Friday, November 22, 2024 1:47 PM > *To:* Jeffrey (Zhaohui) Zhang ; Wen Lin < > wlin@juniper.net>; Ketan Talaulikar > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Still not sure where the disconnect is. > > This text: > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, the advertisement of this route SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > > > > > Is not changing the way the AD per-ES routes are used in RFC7432, 8365, > 9152 or even 8317. So there is no need to specify any new route targets. > > > > The text is just saying that if no ESI filtering is needed but we still > need to advertise the AD per ES route (examples are local-bias, or EVPN > VPWS as Wen said), then the BGP Prefix-SID attribute is just an indicator > of the encapsulation. That indicator uses that format with SRv6 L2 servic= e > TLV. > > > > That=E2=80=99s how it=E2=80=99s been implemented and deployed. So what ho= w would you > change the text above in red to clarify that? > > > > Thanks. > > Jorge > > > > > > > > Juniper Business Use Only > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Friday, November 22, 2024 at 9:38=E2=80=AFAM > *To: *Wen Lin , Jorge Rabadan (Nokia) < > jorge.rabadan@nokia.com>, Ketan Talaulikar > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > > for additional information. > > > > For the RT issue, it is when ESI-0 is used. What RT we should use? > > For the non-0 type-1 per ES routes, the RTs make sure that they=E2=80=99r= e > imported by PEs who have the ES. > > For the ESI-0 type-1 routes, I suppose all PEs need to import that route. > > > > > > Juniper Business Use Only > > *From:* Wen Lin > *Sent:* Friday, November 22, 2024 12:35 PM > *To:* Jeffrey (Zhaohui) Zhang ; Jorge Rabadan (Nokia) > ; Ketan Talaulikar > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > In EVPN-VPWS MH case, it is non-zero ESI in the ES per AD route. > > There is no change to how RT is contrasted when EVPN runs over SRv6. > > > > Thanks, > > Wen > > > > > > Juniper Business Use Only > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Friday, November 22, 2024 at 12:30=E2=80=AFPM > *To: *Wen Lin , Jorge Rabadan (Nokia) < > jorge.rabadan@nokia.com>, Ketan Talaulikar > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > Do those routes have non-zero ESI? > > Do we need to signal SID ::0 to indicate SRv6 in the VPWS MH case? Or are > you just saying that we should point out VPWS MH case as well for > consistency (if we do signal ::0 to indicate SRv6)? > > > > To re-summarize my points: > > > > Do we really need to signal SID ::0 in type-1 routes to signal SRv6? > > If so, for the EVPN non-MH case we need to explicitly call out the > following: > > Advertise ESI-0 type-1 route (as this is not in RFC7432) > > Specify what RTs to use > > If not, delete the relevant text > > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Wen Lin > *Sent:* Friday, November 22, 2024 12:22 PM > *To:* Jeffrey (Zhaohui) Zhang ; Jorge Rabadan (Nokia) > ; Ketan Talaulikar > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > Please also consider the case that per ES AD route is also used in > EVPN-VPWS MH case even though no need for ARG. > > In this case, the BGP Prefix-SID Attribute signals this is for SRv6, make > the encapsulation consistent across the EVPN routes. > > > > Thanks, > > Wen > > > > > > > > Juniper Business Use Only > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Friday, November 22, 2024 at 10:56=E2=80=AFAM > *To: *Jorge Rabadan (Nokia) , Ketan Talaulikar < > ketant.ietf@gmail.com>, Wen Lin > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > I don=E2=80=99t see the need to signal the support of SRv6 as a generic c= apability > at the PE level. > > That=E2=80=99s my point. As a result, the red text should be removed =F0= =9F=98=8A > > > > > > Juniper Business Use Only > > *From:* Jorge Rabadan (Nokia) > *Sent:* Friday, November 22, 2024 10:55 AM > *To:* Jeffrey (Zhaohui) Zhang ; Ketan Talaulikar < > ketant.ietf@gmail.com>; Wen Lin > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > If there is no multi-homing or etree or any applications for the A-D per > ES route, then there is no reason to advertise the route. > > > > How do I know if my remote PE1 supports SRv6? Well, it is indicated in th= e > routes that I receive from it and that I use to program my forwarding > entries. E.g., if I want to send routed traffic to prefix P, there will b= e > an IP Prefix route that covers P and that route comes with the BGP Prefix > SID and the SRv6 information. > > > > I don=E2=80=99t see the need to signal the support of SRv6 as a generic c= apability > at the PE level. The current implementations do not use that. Same goes f= or > other encapsulations supported by EVPN =E2=80=93 MPLS, MPLSoGRE, VXLAN, G= ENEVE... > the different routes will signal the encapsulation. > > > > Please bear with me if I am not understanding your point.. > > > > Thanks! > > Jorge > > > > > > Juniper Business Use Only > > *From: *Jeffrey (Zhaohui) Zhang > *Date: *Friday, November 22, 2024 at 7:11=E2=80=AFAM > *To: *Jorge Rabadan (Nokia) , Ketan Talaulikar < > ketant.ietf@gmail.com>, Wen Lin > *Cc: *bess-chairs@ietf.org , > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > > for additional information. > > > > Hi Jorge, > > > > That red text is about the following: > > > > Even if ESI filtering is not needed, to signal that the advertising route= r > supports SRv6, the type-1 route is advertised, with SID ::0. > > > > My comments are that in the case of EVPN (non-Etree) w/o multihoming, we= =E2=80=99d > need explicitly call out the following for the purpose of signaling =E2= =80=9CI > support SRv6=E2=80=9D > > > > We need to advertise a type-1 route with ESI 0 and SID ::0 > > We need to spell out what RT to use for that type-1 route (since it needs > to go to every PE, not just PEs on an ES). > > I also wonder if that is the best way to signal the SRv6 capability. > > > > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Jorge Rabadan (Nokia) > *Sent:* Friday, November 22, 2024 9:49 AM > *To:* Jeffrey (Zhaohui) Zhang ; Ketan Talaulikar < > ketant.ietf@gmail.com>; Wen Lin > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Without Etree the AD routes are only advertised if there are multihoming > Ethernet segments, as you say. However, even with multihoming you may or > may not need ESI based filtering. If you use local-bias, then there is no > need for ESI filtering and hence the argument is 0. > > The split-horizon-group draft explains the different SHTs for EVPN with > SRv6 transport. > > > > Does this help? Let us know please. > > Thanks! > > Jorge > > > > Juniper Business Use Only > ------------------------------ > > *From:* Jeffrey (Zhaohui) Zhang > *Sent:* Friday, November 22, 2024 05:56 > *To:* Ketan Talaulikar ; Jorge Rabadan (Nokia) < > jorge.rabadan@nokia.com>; Wen Lin > *Cc:* bess-chairs@ietf.org ; > draft-ietf-bess-bgp-srv6-args@ietf.org < > draft-ietf-bess-bgp-srv6-args@ietf.org> > *Subject:* RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > > for additional information. > > > > Hi Jorge, Wen, > > > > I was asking you on the side about type-1 per EVI route. With RFC7432 (fo= r > regular EVPN, not E-Tree), the type-1 route is only used for multi-homing > case, and they=E2=80=99re advertised with non-0 ESIs. If there is no mult= i-homing, > then they=E2=80=99re not advertised per my understanding. > > > > The question was triggered by the red text below (though here it is the > per-ES route). It is considered necessary to signal SID ::0 via the type-= 1 > route when ESI filtering is not in use, so that other routers know that t= he > advertising router supports SRv6. That means, for regular EVPN (not > E-Tree), even if there is no multi-homing, a type-1 route is needed, and > the ESI needs to be set to 0. > > > > If that is needed, the draft should call that out, and we also need to > talk about the RTs that need to be used with that ESI-0 type-1 route. > > > > More details/thoughts are in the email below. > > > > Thanks. > > Jeffrey > > > > > > Juniper Business Use Only > > *From:* Jeffrey (Zhaohui) Zhang > *Sent:* Friday, November 15, 2024 10:20 AM > *To:* Ketan Talaulikar > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > KT2> I am not an EVPN expert, but I don't believe Type-1 route is only > used for multihoming cases - e.g., RFC8317? I'll also let my co-authors o= r > others on this thread clarify/correct me. > > > > It seems that for regular EVPN (RFC7432), Type-1 routes are only used for > multihoming. > > For E-Tree (RFC8317) the type-1 per ES route (though with ESI-0) is > specifically for the mandatory ESI filtering purposes. Therefore, the > following becomes a moot point for E-Tree. > > > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > > conveyed. However, the advertisement of this route SHOULD include > > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > > > For regular EVPN, we either need to explicitly say that we use a > type-1-per-ES route with ESI 0 when there is no multi-homing (which is no= t > currently in RFC7432) and the above to indicate the support of SRv6, or > just use the type-3 IMET route for that purpose. The latter does not have > the flexibility of allowing different mechanisms for unicast and BUM; the > former is a bit shoehorning but explicit text is needed if that=E2=80=99s= what we > want to go with. > > > > It seems to me that any of the following can be used to indicate the > support of SRv6 when there is no need for the ESI filtering > > > > SRv6 service SID in IMET route > > SRv6 service SID in Type-1-per-ES route with non-zero ESI > > SRv6 service SID in Type-1-per-ES route with zero ESI (if there are no > multi-homing) > > A flag bit in the IMET route=E2=80=99s P-Tunnel Attribute > > Based on local provisioning (that all PEs support SRv6) > > > > Jeffrey > > > > *From:* Ketan Talaulikar > *Sent:* Friday, November 15, 2024 6:10 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Please check inline below with KT2. > > > > > > On Wed, Nov 13, 2024 at 3:33=E2=80=AFAM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net> wrote: > > Hi Ketan, > > > > Please see zzh> below. > > > > > > Juniper Business Use Only > > *From:* Ketan Talaulikar > *Sent:* Tuesday, November 12, 2024 11:37 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* bess-chairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org > *Subject:* Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > *[External Email. Be cautious of content]* > > > > Hi Jeffrey, > > > > Thanks for your help with this document and for your review. Please check > inline below for responses. > > > > > > On Tue, Nov 12, 2024 at 9:31=E2=80=AFPM Jeffrey (Zhaohui) Zhang < > zzhang@juniper.net> wrote: > > Hi Ketan, > > I will be shepherding this document. > I did a quick review before I call for WGLC, and have some nit/clarifying > questions: > > It seems that the main problem is not "lack of details", but the followin= g > that is mentioned in the "backward compatibility" section: > > > > KT> This is indeed one of the issues - the procedure in RFC9252 (which is > a SHOULD) does not work in all cases. However, there is also the lack of > details that were raised during the interop. > > > > > [RFC9252] section 6.3 specifies the use of a bitwise logical-OR > operation between the SID with ARG signaled via Route Type 1 and the > SID with LOC:FUNC parts signaled via Route Type 3 to form the SRv6 > Service SID to be used in the data path. However, this assumes that > the same uniform SID structure is used and signaled for all SIDs > advertised via Route Type 3 and the Route Type 1. Such an assumption > may not always be correct and the procedures in this document remove > this restriction. > > If my understanding is correct, the above should be moved forward and > called out at the very beginning (and refer to Figure 7 as an example). > > > > KT> We placed that text in the section since it immediately follows the > example in figure 7 and placing it under the backward compatibility secti= on > draws special attention to it in terms of change of procedure. > > > > Zzh> The change of procedure (from bitwise logical-OR to filling the Arg > bits from the type-1 signaling), as per my understanding, is the key chan= ge > in this document. As such, it should be mentioned at the very beginning o= f > the document. > > > > Zzh> In addition, the backward compatibility section can be simply change= d > to as follows: > > > > 4. Backward Compatibility > > > > Existing implementations based on the bitwise logical-OR operation > > specified in [RFC9252 work only if the SID structures of the two route > > types are identical. The new procedures in this document not only > > remove that restriction, but also is backward compatible with the > > existing implementations (when the SID structures of the two route > > types are identical). > > > > > > KT2> Sure. I can make that change. > > > > > > Related to that, since different LOC:FUNC lengths could be used, shouldn'= t > we (allow to) encode LBL: 0, LNL: 0, FL: 0, AL: 16 in the type 1 route? > > > > KT> The structure in type 1 route is so that one can pick the ARG in the > SID being signaled. By fully specifying the structure, we are able to > interop with older versions that used the bitwise logical-OR when the > structures are identical. The structures being identical is still the mos= t > common deployment design. > > Zzh> Good point. > > > > > BGP Prefix SID Attr: > SRv6 L2 Service TLV: > SRv6 SID Information sub-TLV: > SID: 0:0:0:0:aaaa:: > Behavior: End.DT2M > SRv6 SID Structure sub-sub-TLV: > LBL: 32, LNL: 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0 > > Figure 2: EVPN Route Type 1 with ARG for ESI Filtering > > When ESI filtering is not used, why SHOULD we advertise the following at > all? What if it is not advertised? > > When ESI Filtering is not in use, there is no ESI Filtering ARG to be > conveyed. However, the advertisement of this route SHOULD include > the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an > SRv6 Service SID with the value ::0 is carried in the SRv6 SID > Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M. > > > > KT> The reason is provided in the next sentence "The presence of BGP > Prefix-SID Attribute carrying an SRv6 L2 Service TLV indicates support fo= r > SRv6 as specified in [RFC9252 > > ]." > > Zzh> The Type-1 route is advertised only for MHESes and a deployment w/o > MHES will not have type-1 routes so relying on the above is not robust. F= or > comparison, type-3 routes are always present it is better to rely on that= . > > > > > > KT2> I am not an EVPN expert, but I don't believe Type-1 route is only > used for multihoming cases - e.g., RFC8317? I'll also let my co-authors o= r > others on this thread clarify/correct me. > > > > > BTW, should "is carried" be removed from the above? Otherwise, it does no= t > parse to me. > > > > KT> Ack - will remove it. > > > > > Since the LOC:FUNC and the ARG portions of the SRv6 Service SID are > signaled via different route advertisements, there can be conditions > where the ingress PE gets inconsistent ALs from the two route types. > If the ingress PE expected ESI filtering to be in use (i.e., when > forwarding BUM traffic to other PEs attached to a shared Ethernet > Segment) but does not find a usable ARG value during the above > processing, it SHOULD log a message to help with troubleshooting. > > The above paragraph should be moved to before the two steps in the same > section for a better flow. > > > > KT> I felt the other way is better flow but since this is editorial, I > will look for input from others as well as they review and do the needful= . > > Zzh> Because of the following in step 2: > > > > b. If the AL values in Route Type 1 and 3 are both non-zero and > > not equal, then there is no usable ARG value. It also > > indicates an inconsistency in signaling from the egress PE. > > To avoid looping, the BUM traffic MUST NOT be forwarded for > > such routes from the specific Ethernet Segment and > > implementations SHOULD log an error message. > > > > c. The ARG value from Route Type 1 is usable only when its AL is > > equal to the AL of the SID structure advertised via Route > > Type 3. =E2=80=A6 > > > > Zzh> It=E2=80=99s more natural to point out ahead of the steps that diff= erent AI > values may be signaled (and that is a error condition). > > > > > > KT2> Ack - will make this change as well. > > > > > The description and the examples in this section do not use the > Transposition Scheme. Hence, the Transposition Offset (TPOS-O) and > Transposition Length (TPOS-L) are both shown to be 0 and the various > MPLS label fields into which the FUNC or ARG portions may be > transposed into are also not described. The same examples could use > the Transposition Scheme. This document does not introduce any > change with respect to the use of the Transposition Scheme in the > signaling of EVPN Routes and implementations need to follow the > procedures and recommendations related to the Transposition Schemed > as specified in [RFC9252]. > > Is it that RFC9252 has no problem with the transposition scheme? If so, > better make it clear at the very beginning of the document and remove the > above paragraph. > > > > KT> The details and procedures apply whether or not a transposition schem= e > is used. So there is no additional/specific issue with the transposition > scheme. This text is there to indicate that the same procedures apply eve= n > when transposition is used. > > Zzh> Because of the following: > > > > =E2=80=A6 This document does not introduce any > change with respect to the use of the Transposition Scheme in the > signaling of EVPN Routes and implementations need to follow the > procedures and recommendations related to the Transposition Schemed > as specified in [RFC9252]. > > Zzh> It makes me believe that the RFC9252 is fine with the transposition > scheme. Therefore, it is better to point that out at the very beginning. > > Zzh> Jeffrey > > > > KT2> It is not clear to me if you wanted me to move this paragraph in the > introduction section or section 2? Can you please clarify? I will update > accordingly. > > > > Thanks, > > Ketan > > > > > > > > > > Thanks, > > Ketan > > > > > Thanks. > Jeffrey > > > Juniper Business Use Only > -----Original Message----- > From: Ketan Talaulikar > Sent: Sunday, November 3, 2024 5:47 AM > To: bess-chairs@ietf.org > Cc: draft-ietf-bess-bgp-srv6-args@ietf.org > Subject: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > [External Email. Be cautious of content] > > > Hello Chairs, > > I noticed that this draft is missing from the BESS wiki. > > As a reminder, the authors had requested for an expedited WGLC for this > document that covers important clarifications for issues discovered durin= g > interop for the WG RFC9252. > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/MD= pZsTSaYv9AAfQenspGqEZA7NY/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgRev1nD2= fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbtV-bB7iA$ > > > That was in March 2024. I hope our position on the Q is being tracked :-) > > Thanks, > Ketan > > ---------- Forwarded message --------- > From: Ketan Talaulikar > Date: Sun, Nov 3, 2024 at 10:41=E2=80=AFAM > Subject: Re: [bess] I-D Action: draft-ietf-bess-bgp-srv6-args-02.txt > To: > > > Hello All, > > This version includes text to clarify the applicability to a deployment > with a mix of compressed (CSID) and uncompressed SID. > > Thanks, > Ketan (on behalf of co-authors) > > On Sun, Nov 3, 2024 at 10:35=E2=80=AFAM wrote: > > > > Internet-Draft draft-ietf-bess-bgp-srv6-args-02.txt is now available. > > It is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF. > > > > Title: SRv6 Argument Signaling for BGP Services > > Authors: Ketan Talaulikar > > Kamran Raza > > Jorge Rabadan > > Wen Lin > > Name: draft-ietf-bess-bgp-srv6-args-02.txt > > Pages: 13 > > Dates: 2024-11-03 > > > > Abstract: > > > > RFC9252 defines procedures and messages for SRv6-based BGP services > > including L3VPN, EVPN, and Internet services. This document updates > > RFC9252 and provides more detailed specifications for the signaling > > and processing of SRv6 SID advertisements for BGP Service routes > > associated with SRv6 Endpoint Behaviors that support arguments. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet > > > f-bess-bgp-srv6-args/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgRev1nD2 > > fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbuWpTPgKQ$ > > > > There is also an HTMLized version available at: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > > > t-ietf-bess-bgp-srv6-args-02__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkg > > Rev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbvVUBdI8g$ > > > > A diff from the previous version is available at: > > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2= =3D > > > draft-ietf-bess-bgp-srv6-args-02__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1 > > ldkgRev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbsvxxynfQ$ > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > BESS mailing list -- bess@ietf.org > > To unsubscribe send an email to bess-leave@ietf.org > > --0000000000007f09240628d8dc1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luc/All,

As we've discussed earl= ier on this thread, this draft is limited to the SRv6 signaling aspect and = does not change anything with respect to other aspects such as multihoming = and the usage of Ether AD per ES Route type.

Yet a= nother text proposal for consideration:

NEW
<= div>When ESI Filtering is not in use, there is no = ESI Filtering ARG to be conveyed. However, the advertisement of this rou= te SHOULD include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV = carrying an SRv6 Service SID with the value ::0 in the SRv6 SID Information= sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M for backward compa= tibility and consistency with [RFC9252]. Since the End.DT2M behavior su= pports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be included, = and as no ARG value needs to be signaled, the AL MUST be set to 0.

Does this work for everyone?

Than= ks,
Ketan


On Mon, Dec 9= , 2024 at 8:02=E2=80=AFPM Luc Andr=C3=A9 Burdet <laburdet.ietf@gmail.com> wrote:

Jeffrey, all,<= /p>

=C2=A0

I find the change to =E2=80=9Cif th= is route is advertised=E2=80=9D to be imprecise: =E2=80=98if=E2=80=99 impli= es EtherA-D per ES is an optional route, incl for multihoming.

I disagree this change is needed an= d the original text was fine =E2=80=93 this draft is about the args presenc= e or encoding on a route, not whether or not it is to be advertised: that is covered already in the various service/multihoming = drafts, and should be left there.

=C2=A0

For reference, the use of ESI Filte= ring itself (vs. Local-bias) is in the EtherA-D per ES (https://datatracker.ietf.org/doc/html/draft-ietf= -bess-evpn-mh-split-horizon-11#section-2.2), adding ambiguity to that advertisement here doesn=E2=80=99t make sense. Th= e plain reading of the new statement is that the EtherA-D per ES does not n= eed to be advertised if ESI-Filtering is not used.

=C2=A0

Regards,

Luc Andr=C3=A9

=C2=A0

Luc Andr=C3=A9 Burdet | =C2=A0Cisco =C2=A0|=C2=A0 = laburdet.ietf@= gmail.com=C2=A0 |=C2=A0 Tel: +1 613 254 4814

=C2=A0

=C2=A0

= Hi Jeffrey,<= /u>

= =C2=A0

= I didn=E2=80=99t think the second red text was necessary, but I don=E2=80= =99t have a strong opinion about it and I=E2=80=99m ok if Ketan/Wen are goo= d.

= Other than that, a small typo in the NEW text:

= =C2=A0

NEW:

=C2=A0

=C2=A0=C2=A0 When ESI Filtering is not in use, there i= s no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, if this route is advertised, it SHOULD inc= lude

=C2=A0=C2=A0 the BGP Prefix-SID Attribute with an SRv6= L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the value ::0 is carried in the SRv6 SID

=C2=A0=C2=A0 Information sub-TLV with the SRv6 Endpoin= t Behavior set to End.DT2M

=C2=A0=C2=A0 for backward compatibility or consistency conside= rations. =C2=A0=C2=A0Since the

=C2=A0=C2=A0 End.DT2M behavior supports the use of ARG= , an SRv6 SID Structure sub-

=C2=A0=C2=A0 sub-TLV MUST be included, and as no ARG v= alue needs to be signaled,

=C2=A0=C2=A0 the AL MUST be set to 0.

= =C2=A0

= i.e., remove =E2=80=9Cis carried=E2=80=9D

= =C2=A0

= Thanks.<= /span>

= Jorge

= =C2=A0

= =C2=A0

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Thursday, December 5, 2024 at 2:47=E2=80=AF= PM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Wen Lin <wlin@juniper.net>, bess-chairs@ietf.or= g <bess-ch= airs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <dra= ft-ietf-bess-bgp-srv6-args@ietf.org>, BESS <bess@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

CAUTION: This is an external email= . Please be very careful when clicking links or opening attachments. See th= e URL nok.it/ext for ad= ditional information.

=C2=A0

Hi Ketan, Jorge, Wen,

=C2=A0

To clarify, I would like to see the following changes:= <= /p>

=C2=A0

OLD:

=C2=A0

=C2=A0=C2=A0 When ESI Filtering is not in use, there i= s no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, the advertisement of this route SHOULD include<= u>

=C2=A0=C2=A0 the BGP Prefix-SID Attribute with an SRv6= L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the value ::0 is ca= rried in the SRv6 SID<= u>

=C2=A0=C2=A0 Information sub-TLV with the SRv6 Endpoin= t Behavior set to End.DT2M.

=C2=A0=C2=A0 The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service= <= /p>

=C2=A0=C2=A0 TLV indicates su= pport for SRv6 as specified in [RFC9252].=C2=A0 Since the

=C2=A0=C2=A0 End.DT2M behavior supports the use of ARG= , an SRv6 SID Structure sub-

=C2=A0=C2=A0 sub-TLV MUST be included, and as no ARG v= alue needs to be signaled,

=C2=A0=C2=A0 the AL MUST be set to 0.

=C2=A0

NEW:

=C2=A0

=C2=A0=C2=A0 When ESI Filtering is not in use, there i= s no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, if this route is advertised, it SHOULD inc= lude

=C2=A0=C2=A0 the BGP Prefix-SID Attribute with an SRv6= L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the value ::0 is ca= rried in the SRv6 SID<= u>

=C2=A0=C2=A0 Information sub-TLV with the SRv6 Endpoin= t Behavior set to End.DT2M

=C2=A0=C2=A0 for backward compatibility or consistency conside= rations. =C2=A0=C2=A0Since the

=C2=A0=C2=A0 End.DT2M behavior supports the use of ARG= , an SRv6 SID Structure sub-

=C2=A0=C2=A0 sub-TLV MUST be included, and as no ARG v= alue needs to be signaled,

=C2=A0=C2=A0 the AL MUST be set to 0.

=C2=A0

Please let me know if this is ok. If you still strongl= y believe the second red text is not correct, please als= o let me know. Either way, I will start the WGLC process after hearing from= you and seeing at least the first red change.

=C2=A0

Thanks.
Jeffrey<= /span>

=C2=A0

=C2=A0

Juniper Business Use Only

From: J= effrey (Zhaohui) Zhang <zzhang@juniper.net>
Sent: Tuesday, November 26, 2024 2:04 PM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>; Wen Lin <wlin@juniper.net>; bess-chairs@ietf.or= g; draft-ietf-bess-bgp-srv6-args@ietf.org; BESS <bess@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

Hi Ketan,

=C2=A0

That addresses part of my of concern.

=C2=A0

Remember that this started with my question =E2=80=9Cw= hy is =E2=80=98SHOULD=E2=80=99 used here=E2=80=9D. The answer was:

KT> The reason is provided in the next sentence &qu= ot;The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service TLV indicates support for SRv6 as sp= ecified in=C2=A0[RFC92= 52]."<= u>

After a long discussion, now my understanding is that = it=E2=80=99s not really to =E2=80=9Cindicate SRv6 support=E2=80=9D =E2=80= =93 because the MAC/IP routes and the AD per EVI routes are sufficient in that already =E2=80=93 it=E2=80=99s really for backward compatibility/c= onsistency (perhaps it is more for consistency than for compatibility =E2= =80=93 unless an existing implementation stops working if it does not see t= he SID ::0 advertised).

=C2=A0

This may seem a nitpick, but since it took us quite so= me time to arrive at this conclusion (I hope we have a consensus now), I=E2= =80=99d rather see the spec document it properly.

=C2=A0

Therefore, I would like to see the rest of that paragr= aph as follows:=

=C2=A0

for backward compatibility or consistency co= nsiderations.=C2=A0=C2=A0=C2=A0 =C3=9F new=

=C2=A0=C2=A0 The presence of BGP Prefix-SID Attribu= te carrying an SRv6 L2 Service =C2=A0=C2=A0=C2=A0=C3=9F deleted=

=C2=A0=C2=A0 TLV indicates support for SRv6 as spec= ified in [RFC9252].=C2=A0

Thanks.

Jeffrey

=C2=A0

From: K= etan Talaulikar <ketant.ietf@gmail.com>
Sent: Monday, November 25, 2024 8:39 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>; Wen Lin <wlin@juniper.net>; bess-chairs@ietf.= org; draft-ietf-bess-bgp-srv6-args@ietf.org; BESS <bess@ietf.org>
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi=C2=A0Jeffrey,

=C2=A0

This draft is not getting into all the scenarios when = the Route Type 1 is advertised and its usage - that would be outside the sc= ope of this document.

=C2=A0

Does the following text change address your concerns?<= u>

=C2=A0


OLD

=C2=A0= =C2=A0When ESI Filtering is not in use, there is no ESI Filtering ARG to b= e=

=C2=A0= =C2=A0 conveyed.=C2=A0 However, the advertisement of this route SHOULD incl= ude

=C2=A0= =C2=A0 the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an= <= /p>

=C2=A0= =C2=A0 SRv6 Service SID with the value ::0 is carried in the SRv6 SID

=C2=A0= =C2=A0 Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M.= <= /p>

=C2=A0

NEW

=C2=A0= =C2=A0When ESI Filtering is not in use, there is no ESI Filtering ARG to b= e=

=C2=A0= =C2=A0 conveyed.=C2=A0 However,=C2=A0if this route is advertised, it=C2= =A0SHOULD include<= u>

=C2=A0= =C2=A0 the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an= <= /p>

=C2=A0= =C2=A0 SRv6 Service SID with the value ::0 is carried in the SRv6 SID

=C2=A0= =C2=A0 Information sub-TLV with the SRv6 Endpoint Behavior set to End.DT2M.= <= /p>

=C2=A0

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

On Mon, Nov 25, 2024 at 6:29=E2=80=AFPM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:

[+ BESS mailing list]

=C2=A0

Hi Jorge,

=C2=A0

Please see zzh> below.

=C2=A0

=C2=A0

Juniper Business Use Only

From: J= orge Rabadan (Nokia) <jorge.rabadan@nokia.com>
Sent: Friday, November 22, 2024 4:05 PM
To: Wen Lin <wlin@juniper.net>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Ketan Tala= ulikar <ketan= t.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Jeffrey,

=C2=A0

Also, I see where you are coming from, thanks fo= r explaining, however:=

=C2=A0

Zzh> The spec needs to be clear whether the ESI-0 A= -D per ES route is needed for EVPN/EVPN-VPWS when multi-homing is not used.= My understanding is that it is not needed.

=C2=A0

=E2=80=9Cbut as you said =E2=80=9CI don=E2=80=99t see = the need to signal the support of SRv6 as a generic capability at the PE le= vel=E2=80=9D=E2=80=9D<= u>

=C2=A0

True, but you still need to signal the encapsula= tion at the EVPN update level. That is the case ever since RFC8365. And if = you don=E2=80=99t add the encapsulation in the route, the default encapsulation is really MPLS (since there was no encap = signaled in RFC7432). So things could have been different, yes, but it was = decided to always signal the encapsulation with the EVPN routes. And that i= s the reason for the red text.

=C2=A0

We should really not change existing deployments= .=

=C2=A0

Zzh> Even when MH is used, the A-D per EVI routes, = IMET and MAC/IP routes have sufficient encapsulation information. Adding th= at to the per-ES route is really like an appendix. I can understand you want to do it for backward compatibility an= d/or consistency reasons =E2=80=93 so I suggest the following text:<= span lang=3D"EN-US" style=3D"font-size:12pt">

=C2=A0

=C2=A0=C2=A0 When ESI Filtering is not in use, there i= s no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, in the case of EVPN/EVPN-VPWS multihoming=C2=A0= =C2=A0=C2=A0 =C3=9F new

=C2=A0 or E-TREE, =C2=A0the advertisement of this route SHOULD inc= lude

=C2=A0=C2=A0 the BGP Prefix-SID Attribute with an SRv6= L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the value ::0 is ca= rried in the SRv6 SID<= u>

=C2=A0=C2=A0 Information sub-TLV with the SRv6 Endpoin= t Behavior set to End.DT2M

=C2=A0=C2=A0 for backward compatibility or consistency conside= rations.=C2=A0=C2=A0=C2=A0 =C3=9F new=

=C2=A0=C2=A0 The presence of BGP Prefix-SID Attribu= te carrying an SRv6 L2 Service =C2=A0=C2=A0=C2=A0=C3=9F deleted=

=C2=A0=C2=A0 TLV indicates support for SRv6 as spec= ified in [RFC9252].=C2=A0

=C2=A0

Zzh&= gt; Does that make sense? This whole discussion started with my question = =E2=80=9Cwhy =E2=80=98SHOULD=E2=80=99 is used=E2=80=9D. BTW, when this docu= ment goes through more reviews, there may be questions like =E2=80=9Cwhat i= f it is not included=E2=80=9D (people like to ask that question with the SHOULD ke= yword).<= /span>

Zzh&= gt; Thanks.<= /u>

Zzh&= gt; Jeffrey<= /u>

=C2=A0

Thanks!

Jorge

=C2=A0

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Wen Lin <wlin@juniper.net>= ;
Date: Friday, November 22, 2024 at 12:19=E2=80=AF= PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>, Jorge Rabadan (Nokia) <<= a href=3D"mailto:jorge.rabadan@nokia.com" target=3D"_blank">jorge.rabadan@n= okia.com>, Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

CAUTION: This is an external email= . Please be very careful when clicking links or opening attachments. See th= e URL nok.it/ext for additional information.

=C2=A0

Hi Jeffrey,

=C2=A0

I raised a good point regarding the definition of RT f= or ES per AD route when ESI value is 0.=C2=A0 You=E2=80=99re right that it = is operated at the PE scope instead of individual multihomed ES scope.<= u>

However, =C2=A0we left to each individual draft or RFC= that uses such a route to specify the appropriate RT as this draft does no= t intent to alter any existing definitions or practices.<= u>

=C2=A0

Thanks,

Wen

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Friday, November 22, 2024 at 2:49=E2=80=AF<= /span>PM
To: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Wen Lin <wlin@juniper.net>, Ke= tan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

Hi Jorge,

=C2=A0

Here is what I think, point by point:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we do not need to s= ignal =E2=80=9CI am using SRv6=E2=80=9D, then all of the following text sho= uld be removed. I was told that purpose of the text is to show the support = of SRv6 (but as you said =E2=80=9CI don=E2=80=99t see the need to signal the support of SRv6 as a generic capability at the PE level=E2=80= =9D. The signaling does not convey any information if we do not need to sig= nal =E2=80=9CI am using SRv6=E2=80=9D, and an ingress PE will use argument = if and only if it is signaled in the type-1 route.

=C2=A0=C2=A0 When ESI Filtering is not in use, there i= s no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, the advertisemen= t of this route SHOULD include

=C2=A0=C2=A0 the BGP Prefix-SID Attribute with an SRv6= L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the value ::0 is ca= rried in the SRv6 SID<= u>

=C2=A0=C2=A0 Information sub-TLV with the SRv6 Endpoin= t Behavior set to End.DT2M.

=C2=A0=C2=A0 The presence of BGP Prefix-SID = Attribute carrying an SRv6 L2 Service

=C2=A0=C2=A0 TLV indicates support for SRv6 = as specified in [RFC9252].=C2=A0 Since the

=C2=A0=C2=A0 End.DT2M behavior supports the use of ARG= , an SRv6 SID Structure sub-

=C2=A0=C2=A0 sub-TLV MUST be included, and as no ARG v= alue needs to be signaled,

=C2=A0=C2=A0 the AL MUST be set to 0.

=C2=A0

=C2=A0=C2=A0 Following is an example representation of= the BGP Prefix-SID=

=C2=A0=C2=A0 Attribute encoding in this case:

=C2=A0

=C2=A0=C2=A0 BGP Prefix SID Attr:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SRv6 L2 Service T= LV:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 SRv6 SID Information sub-TLV:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SID: ::0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Behavior: End.DT2M

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SRv6 SID Structure sub-sub-TLV:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LBL: 32, LNL: 16, FL= : 16, AL: 0, TPOS-L: 0, TPOS-O: 0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figur= e 1: EVPN Route Type 1 without ARG for ESI Filtering

=C2=A0

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we do need to signa= l =E2=80=9CI am using SRv6=E2=80=9D, then because RFC7432 does not talk abo= ut ESI-0 type-1 routes for regular EVPN, we need to call it out that we=E2= =80=99re using ESI-0 type-1 route (when there is no MHES) to signal =E2=80=9CI am using SRv6=E2=80=9D, and we need to say what RT to us= e =E2=80=93 it=E2=80=99s an RT that gets the ESI-0 route to every PE.

Jeffrey

=C2=A0

=C2=A0

=C2=A0

Juniper Business Use Only

From: J= orge Rabadan (Nokia) <jorge.rabadan@nokia.com>
Sent: Friday, November 22, 2024 1:47 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Wen Lin <wlin@juniper.net>; Ketan Tala= ulikar <ketan= t.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Jeffrey,

=C2=A0

Still not sure where the disconnect is.

This text:

=C2=A0

When ESI Filtering is not in use, there is = no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, the a= dvertisement of this route SHOULD include

=C2=A0=C2=A0 the BGP Prefix-SID Attribute w= ith an SRv6 L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the valu= e ::0 is carried in the SRv6 SID

=C2=A0=C2=A0 Information sub-TLV with the S= Rv6 Endpoint Behavior set to End.DT2M.

=C2=A0

=C2=A0

Is not changing the way the AD per-ES routes are= used in RFC7432, 8365, 9152 or even 8317. So there is no need to specify a= ny new route targets.<= u>

=C2=A0

The text is just saying that if no ESI filtering= is needed but we still need to advertise the AD per ES route (examples are= local-bias, or EVPN VPWS as Wen said), then the BGP Prefix-SID attribute is just an indicator of the encapsulatio= n. That indicator uses that format with SRv6 L2 service TLV.

=C2=A0

That=E2=80=99s how it=E2=80=99s been implemented= and deployed. So what how would you change the text above in red to clarif= y that?<= /span>

=C2=A0

Thanks.

Jorge

=C2=A0

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Friday, November 22, 2024 at 9:38=E2=80=AF<= /span>AM
To: Wen Lin <wlin@juniper.net>, Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Ke= tan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

CAUTION: This is an external email= . Please be very careful when clicking links or opening attachments. See th= e URL nok.it/ext for additional information.

=C2=A0

For the RT issue, it is when ESI-0 is used. What RT w= e should use?

For the non-0 type-1 per ES routes, the RTs make sure= that they=E2=80=99re imported by PEs who have the ES.

For the ESI-0 type-1 routes, I suppose all PEs need t= o import that route.

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Wen Lin <wlin@juni= per.net>
Sent: Friday, November 22, 2024 12:35 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Jorge Rabadan (Nokia) <<= a href=3D"mailto:jorge.rabadan@nokia.com" target=3D"_blank">jorge.rabadan@n= okia.com>; Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

In EVPN-VPWS MH case, it is non-zero ESI in the ES pe= r AD route.<= /u>

There is no change to how RT is contrasted when EVPN = runs over SRv6.=

=C2=A0

Thanks,

Wen

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Friday, November 22, 2024 at 12:30=E2=80=AF= PM
To: Wen Lin <wlin@juniper.net>, Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Ke= tan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

Do those routes have non-zero ESI?

Do we need to signal SID ::0 to indicate SRv6 in the = VPWS MH case? Or are you just saying that we should point out VPWS MH case = as well for consistency (if we do signal ::0 to indicate SRv6)?

=C2=A0

To re-summarize my points:

=C2=A0

Do we= really need to signal SID ::0 in type-1 routes to signal SRv6?

If so= , for the EVPN non-MH case we need to explicitly call out the following:

Adver= tise ESI-0 type-1 route (as this is not in RFC7432)

Speci= fy what RTs to use<= /u>

If no= t, delete the relevant text

Jeffrey

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Wen Lin <wlin@juni= per.net>
Sent: Friday, November 22, 2024 12:22 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Jorge Rabadan (Nokia) <<= a href=3D"mailto:jorge.rabadan@nokia.com" target=3D"_blank">jorge.rabadan@n= okia.com>; Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

Please also consider the case that per ES AD route is= also used in EVPN-VPWS MH case even though no need for ARG.

In this case, the BGP Prefix-SID Attribute signals this is fo= r SRv6, make the encapsulation consistent across the EVPN routes.

=C2=A0

Thanks,

Wen

=C2=A0

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Friday, November 22, 2024 at 10:56=E2=80=AF= AM
To: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Ketan Talaulikar &l= t;ketant.ietf@gm= ail.com>, Wen Lin <wlin@juniper.net>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

I don=E2=80=99t see the need to signal the support of SRv6 as a generic ca= pability at the PE level. <= /p>

That=E2=80=99s my point. As a result, the red text sh= ould be removed =F0=9F=98=8A

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>
Sent: Friday, November 22, 2024 10:55 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Ketan Talaulikar <ketant.ietf@gmail.com<= /a>>; Wen Lin <= wlin@juniper.net>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Jeffrey,

=C2=A0

If there is no multi-homing or etree or any app= lications for the A-D per ES route, then there is no reason to advertise th= e route.=

=C2=A0

How do I know if my remote PE1 supports SRv6? W= ell, it is indicated in the routes that I receive from it and that I use to= program my forwarding entries. E.g., if I want to send routed traffic to prefix P, there will be an IP Prefix r= oute that covers P and that route comes with the BGP Prefix SID and the SRv= 6 information.<= u>

=C2=A0

I don=E2=80=99t see the need to signal the supp= ort of SRv6 as a generic capability at the PE level. The current implementa= tions do not use that. Same goes for other encapsulations supported by EVPN =E2=80=93 MPLS, MPLSoGRE, VXLAN, GENEVE... the different= routes will signal the encapsulation.

=C2=A0

Please bear with me if I am not understanding y= our point..<= /u>

=C2=A0

Thanks!

Jorge

=C2=A0

=C2=A0

Juniper Business Use Only

From: <= /b>Jeffrey (Zhaoh= ui) Zhang <zzhan= g@juniper.net>
Date: Friday, November 22, 2024 at 7:11=E2=80=AF<= /span>AM
To: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, Ketan Talaulikar &l= t;ketant.ietf@gm= ail.com>, Wen Lin <wlin@juniper.net>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>, draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

CAUTION: This is an external email= . Please be very careful when clicking links or opening attachments. See th= e URL nok.it/ext for additional information.

=C2=A0

Hi Jorge,

=C2=A0

That red text is about the following:

=C2=A0

Even = if ESI filtering is not needed, to signal that the advertising router suppo= rts SRv6, the type-1 route is advertised, with SID ::0.

=C2=A0

My comments are that in the case of EVPN (non-Etree) = w/o multihoming, we=E2=80=99d need explicitly call out the following for th= e purpose of signaling =E2=80=9CI support SRv6=E2=80=9D

=C2=A0

We ne= ed to advertise a type-1 route with ESI 0 and SID ::0

We ne= ed to spell out what RT to use for that type-1 route (since it needs to go = to every PE, not just PEs on an ES).

I also wonder if that is the best way to signal the S= Rv6 capability.=

=C2=A0

Jeffrey

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>
Sent: Friday, November 22, 2024 9:49 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Ketan Talaulikar <ketant.ietf@gmail.com<= /a>>; Wen Lin <= wlin@juniper.net>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Jeffrey,

=C2=A0

Without Etree the AD routes are only advertised if th= ere are multihoming Ethernet segments, as you say. However, even with multi= homing you may or may not need ESI based filtering. If you use local-bias, then there is no need for ESI filtering = and hence the argument is 0.

The split-horizon-group draft explains the different = SHTs for EVPN with SRv6 transport.

=C2=A0

Does this help? Let us know please.

Thanks!

Jorge

=C2=A0

Juniper Business Use Only

From: = Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Sent: Friday, November 22, 2024 05:56
To: Ketan Talaulikar <ketant.ietf@gmail.com>; Jorge Rabadan (Nokia) <jorge.rabadan@no= kia.com>; Wen Lin <wlin@juniper.net>
Cc: bess-c= hairs@ietf.org <bess-chairs@ietf.org>; draft-ietf-bess-bgp-srv6-args@ietf.org <draft-ietf-bess-bgp-srv6-a= rgs@ietf.org>
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

=C2=A0

CAUTION: This is an external email= . Please be very careful when clicking links or opening attachments. See th= e URL nok.it/ext for additional information.

=C2=A0

Hi Jorge, Wen,

=C2=A0

I was asking you on the side about type-1 per EVI rou= te. With RFC7432 (for regular EVPN, not E-Tree), the type-1 route is only u= sed for multi-homing case, and they=E2=80=99re advertised with non-0 ESIs. If there is no multi-homing, then they=E2=80= =99re not advertised per my understanding.

=C2=A0

The question was triggered by the red text below (though here it is the per-= ES route). It is considered necessary to signal SID ::0 via the type-1 rout= e when ESI filtering is not in use, so that other routers know that the adv= ertising router supports SRv6. That means, for regular EVPN (not E-Tree), even if there is no multi-homing, a = type-1 route is needed, and the ESI needs to be set to 0.

=C2=A0

If that is needed, the draft should call that out, an= d we also need to talk about the RTs that need to be used with that ESI-0 t= ype-1 route.=

=C2=A0

More details/thoughts are in the email below.<= span lang=3D"EN-US" style=3D"font-size:12pt">

=C2=A0

Thanks.

Jeffrey

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Sent: Friday, November 15, 2024 10:20 AM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

KT2> I am not an EVPN expert, but I don't beli= eve Type-1 route is only used for multihoming cases - e.g., RFC8317? I'= ll also let my co-authors or others on this thread clarify/correct me.

=C2=A0

It seems that for regular EVPN (RFC7432), Type-1 rout= es are only used for multihoming.

For E-Tree (RFC8317) the type-1 per ES route (though = with ESI-0) is specifically for the mandatory ESI filtering purposes. There= fore, the following becomes a moot point for E-Tree.=

=C2=A0

=C2=A0=C2=A0 When ESI Filtering is not in u= se, there is no ESI Filtering ARG to be

=C2=A0=C2=A0 conveyed.=C2=A0 However, the a= dvertisement of this route SHOULD include

=C2=A0=C2=A0 the BGP Prefix-SID Attribute w= ith an SRv6 L2 Service TLV carrying an

=C2=A0=C2=A0 SRv6 Service SID with the valu= e ::0 is carried in the SRv6 SID

=C2=A0=C2=A0 Information sub-TLV with the S= Rv6 Endpoint Behavior set to End.DT2M.

=C2=A0

For regular EVPN, we either need to explicitly say th= at we use a type-1-per-ES route with ESI 0 when there is no multi-homing (w= hich is not currently in RFC7432) and the above to indicate the support of SRv6, or just use the type-3 IMET rou= te for that purpose. The latter does not have the flexibility of allowing d= ifferent mechanisms for unicast and BUM; the former is a bit shoehorning bu= t explicit text is needed if that=E2=80=99s what we want to go with.

=C2=A0

It seems to me that any of the following can be used = to indicate the support of SRv6 when there is no need for the ESI filtering= <= /p>

=C2=A0

SRv6 service SID in IMET rout= e=

SRv6 service SID in Type-1-pe= r-ES route with non-zero ESI

SRv6 service SID in Type-1-pe= r-ES route with zero ESI (if there are no multi-homing)

A flag bit in the IMET route= =E2=80=99s P-Tunnel Attribute

Based on local provisioning (= that all PEs support SRv6)

=C2=A0

Jeffrey

=C2=A0

From: = Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Friday, November 15, 2024 6:10 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi=C2=A0Jeffrey,

=C2=A0

Please check inline below with KT2.

=C2=A0

=C2=A0

On Wed, Nov 13, 2024 at 3:33=E2=80=AFAM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:

Hi Ketan,

=C2=A0

Please see zzh> below.

=C2=A0

=C2=A0

Juniper Business Use Only

From: = Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Tuesday, November 12, 2024 11:37 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bess-c= hairs@ietf.org; draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi=C2=A0Jeffrey,

=C2=A0

Thanks for your help with this document and for your = review. Please check inline below for responses.

=C2=A0

=C2=A0

On Tue, Nov 12, 2024 at 9:31=E2=80=AFPM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:

Hi Ketan,

I will be shepherding this document.
I did a quick review before I call for WGLC, and have some nit/clarifying q= uestions:

It seems that the main problem is not "lack of details", but the = following that is mentioned in the "backward compatibility" secti= on:

=C2=A0

KT> This is indeed one of the issues - the procedu= re in RFC9252 (which is a SHOULD) does not work in all cases. However, ther= e is also the lack of details that were raised during the interop.

=C2=A0


=C2=A0 =C2=A0[RFC9252] section 6.3 specifies the use of a bitwise logical-O= R
=C2=A0 =C2=A0operation between the SID with ARG signaled via Route Type 1 a= nd the
=C2=A0 =C2=A0SID with LOC:FUNC parts signaled via Route Type 3 to form the = SRv6
=C2=A0 =C2=A0Service SID to be used in the data path.=C2=A0 However, this a= ssumes that
=C2=A0 =C2=A0the same uniform SID structure is used and signaled for all SI= Ds
=C2=A0 =C2=A0advertised via Route Type 3 and the Route Type 1.=C2=A0 Such a= n assumption
=C2=A0 =C2=A0may not always be correct and the procedures in this document = remove
=C2=A0 =C2=A0this restriction.

If my understanding is correct, the above should be moved forward and calle= d out at the very beginning (and refer to Figure 7 as an example).

=C2=A0

KT> We placed that text in the section since it im= mediately follows the example in figure 7 and placing it under the backward= compatibility section draws special attention to it in terms of change of procedure.

=C2=A0

Zzh> The change of procedure (from bitwise logical= -OR to filling the Arg bits from the type-1 signaling), as per my understan= ding, is the key change in this document. As such, it should be mentioned at the very beginning of the document.

=C2=A0

Zzh> In addition, the backward compatibility secti= on can be simply changed to as follows:

=C2=A0

4.=C2=A0 Backward Compatibility

=C2=A0

=C2=A0=C2=A0 Existing implementations based on the bi= twise logical-OR operation

=C2=A0=C2=A0 specified in [RFC9252 work only if the S= ID structures of the two route

=C2=A0=C2=A0 types are identical. The new procedures = in this document not only

=C2=A0=C2=A0 remove that restriction, but also is bac= kward compatible with the

=C2=A0=C2=A0 existing implementations (when the SID s= tructures of the two route

=C2=A0=C2=A0 types are identical).=C2=A0

=C2=A0

=C2=A0

KT2> Sure. I can make that change.

=C2=A0

=C2=A0

Related to that, since different LOC:FUNC lengths cou= ld be used, shouldn't we (allow to) encode LBL: 0, LNL: 0, FL: 0, AL: 1= 6 in the type 1 route?

=C2=A0

KT> The structure in type 1 route is so that one c= an pick the ARG in the SID being signaled. By fully specifying the structur= e, we are able to interop with older versions that used the bitwise logical-OR when the structures are identical. The st= ructures being identical is still the most common deployment design.=

Zzh> Good point.

=C2=A0


=C2=A0 BGP Prefix SID Attr:
=C2=A0 =C2=A0 =C2=A0 SRv6 L2 Service TLV:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SRv6 SID Information sub-TLV:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SID: 0:0:0:0:aaaa::
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Behavior: End.DT2M
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SRv6 SID Structure sub-sub= -TLV:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LBL: 32, LNL= : 16, FL: 16, AL: 16, TPOS-L: 0, TPOS-O: 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: EVPN Route Type 1 with ARG for= ESI Filtering

When ESI filtering is not used, why SHOULD we advertise the following at al= l? What if it is not advertised?

=C2=A0 =C2=A0When ESI Filtering is not in use, there is no ESI Filtering AR= G to be
=C2=A0 =C2=A0conveyed.=C2=A0 However, the advertisement of this route SHOUL= D include
=C2=A0 =C2=A0the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carry= ing an
=C2=A0 =C2=A0SRv6 Service SID with the value ::0 is carried in the SRv6 SID=
=C2=A0 =C2=A0Information sub-TLV with the SRv6 Endpoint Behavior set to End= .DT2M.

=C2=A0

KT> The reason is provided in the next sentence &q= uot;The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 Service TLV indicates support for SRv6 as sp= ecified in=C2=A0[RFC92= 52]."<= u>

Zzh> The Type-1 route is advertised only for MHESe= s and a deployment w/o MHES will not have type-1 routes so relying on the a= bove is not robust. For comparison, type-3 routes are always present it is better to rely on that.

=C2=A0

=C2=A0

KT2> I am not an EVPN expert, but I don't beli= eve Type-1 route is only used for multihoming cases - e.g., RFC8317? I'= ll also let my co-authors or others on this thread clarify/correct me.

=C2=A0


BTW, should "is carried" be removed from the above? Otherwise, it= does not parse to me.

=C2=A0

KT> Ack - will remove it.

=C2=A0


=C2=A0 =C2=A0Since the LOC:FUNC and the ARG portions of the SRv6 Service SI= D are
=C2=A0 =C2=A0signaled via different route advertisements, there can be cond= itions
=C2=A0 =C2=A0where the ingress PE gets inconsistent ALs from the two route = types.
=C2=A0 =C2=A0If the ingress PE expected ESI filtering to be in use (i.e., w= hen
=C2=A0 =C2=A0forwarding BUM traffic to other PEs attached to a shared Ether= net
=C2=A0 =C2=A0Segment) but does not find a usable ARG value during the above=
=C2=A0 =C2=A0processing, it SHOULD log a message to help with troubleshooti= ng.

The above paragraph should be moved to before the two steps in the same sec= tion for a better flow.

=C2=A0

KT> I felt the other way is better flow but since = this is editorial, I will look for input from others as well as they review= and do the needful.

Zzh> Because of the following in step 2:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b.=C2=A0 If the = AL values in Route Type 1 and 3 are both non-zero and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 not equal, then there is no usable ARG value.=C2=A0 It also

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 indicates an inconsistency in signaling from the egress PE.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 To avoid looping, the BUM traffic MUST NOT be forwarded for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 such routes from the specific Ethernet Segment and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 implementations SHOULD log an error message.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c.=C2=A0 The ARG= value from Route Type 1 is usable only when its AL is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 equal to the AL of the SID structure advertised via Route<= span lang=3D"EN-US" style=3D"font-size:12pt">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Type 3.=C2=A0 =E2=80=A6

=C2=A0

=C2=A0Zzh> It=E2=80=99s more natural to point out = ahead of the steps that different AI values may be signaled (and that is a = error condition).

=C2=A0

=C2=A0

KT2> Ack - will make this change as well.

=C2=A0


=C2=A0 =C2=A0The description and the examples in this section do not use th= e
=C2=A0 =C2=A0Transposition Scheme.=C2=A0 Hence, the Transposition Offset (T= POS-O) and
=C2=A0 =C2=A0Transposition Length (TPOS-L) are both shown to be 0 and the v= arious
=C2=A0 =C2=A0MPLS label fields into which the FUNC or ARG portions may be =C2=A0 =C2=A0transposed into are also not described.=C2=A0 The same example= s could use
=C2=A0 =C2=A0the Transposition Scheme.=C2=A0 This document does not introdu= ce any
=C2=A0 =C2=A0change with respect to the use of the Transposition Scheme in = the
=C2=A0 =C2=A0signaling of EVPN Routes and implementations need to follow th= e
=C2=A0 =C2=A0procedures and recommendations related to the Transposition Sc= hemed
=C2=A0 =C2=A0as specified in [RFC9252].

Is it that RFC9252 has no problem with the transposition scheme? If so, bet= ter make it clear at the very beginning of the document and remove the abov= e paragraph.

=C2=A0

KT> The details and procedures apply whether or no= t a transposition scheme is used. So there is no additional/specific issue = with the transposition scheme. This text is there to indicate that the same procedures apply even when transpositio= n is used.

Zzh> Because of the following:

=C2=A0

=C2=A0=C2=A0 =E2=80=A6 This document does not introdu= ce any
=C2=A0 =C2=A0change with respect to the use of the Transposition Scheme in = the
=C2=A0 =C2=A0signaling of EVPN Routes and implementations need to follow th= e
=C2=A0 =C2=A0procedures and recommendations related to the Transposition Sc= hemed
=C2=A0 =C2=A0as specified in [RFC9252].

Zzh> It makes me believe that the RFC9252 is fine = with the transposition scheme. Therefore, it is better to point that out at= the very beginning.

Zzh> Jeffrey

=C2=A0

KT2> It is not clear to me if you wanted me to mov= e this paragraph in the introduction section or section 2? Can you please c= larify? I will update accordingly.

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Thanks,

Ketan

=C2=A0


Thanks.
Jeffrey


Juniper Business Use Only
-----Original Message-----
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: Sunday, November 3, 2024 5:47 AM
To: bess-chairs@i= etf.org
Cc: draft-ietf-bess-bgp-srv6-args@ietf.org
Subject: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

[External Email. Be cautious of content]


Hello Chairs,

I noticed that this draft is missing from the BESS wiki.

As a reminder, the authors had requested for an expedited WGLC for this doc= ument that covers important clarifications for issues discovered during int= erop for the WG RFC9252.

https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/b= ess/MDpZsTSaYv9AAfQenspGqEZA7NY/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgR= ev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbtV-bB7iA$

That was in March 2024. I hope our position on the Q is being tracked :-)
Thanks,
Ketan

---------- Forwarded message ---------
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Sun, Nov 3, 2024 at 10:41=E2=80=AFAM
Subject: Re: [bess] I-D Action: draft-ietf-bess-bgp-srv6-args-02.txt
To: <bess@ietf.org>


Hello All,

This version includes text to clarify the applicability to a deployment wit= h a mix of compressed (CSID) and uncompressed SID.

Thanks,
Ketan (on behalf of co-authors)

On Sun, Nov 3, 2024 at 10:35=E2=80=AFAM <internet-drafts@ietf.org> wrote:
>
> Internet-Draft draft-ietf-bess-bgp-srv6-args-02.txt is now available.<= br> > It is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF. >
>=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0SRv6 Argument Signaling for BGP Servic= es
>=C2=A0 =C2=A0 Authors: Ketan Talaulikar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kamran Raza
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jorge Rabadan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wen Lin
>=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 draft-ietf-bess-bgp-srv6-args-02.txt >=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A013
>=C2=A0 =C2=A0 Dates:=C2=A0 =C2=A02024-11-03
>
> Abstract:
>
>=C2=A0 =C2=A0 RFC9252 defines procedures and messages for SRv6-based BG= P services
>=C2=A0 =C2=A0 including L3VPN, EVPN, and Internet services.=C2=A0 This = document updates
>=C2=A0 =C2=A0 RFC9252 and provides more detailed specifications for the= signaling
>=C2=A0 =C2=A0 and processing of SRv6 SID advertisements for BGP Service= routes
>=C2=A0 =C2=A0 associated with SRv6 Endpoint Behaviors that support argu= ments.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet<= br> > f-bess-bgp-srv6-args/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgRev1nD2=
> fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbuWpTPgKQ$
>
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf<= br> > t-ietf-bess-bgp-srv6-args-02__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkg=
> Rev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbvVUBdI8g$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=3D
> draft-ietf-bess-bgp-srv6-args-02__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1=
> ldkgRev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbsvxxynfQ$
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> BESS mailing list -- bess@ietf.org
> To unsubscribe send an email to bess-leave@ietf.org

--0000000000007f09240628d8dc1e--