Hi Jeffrey, Thanks for your feedback. I've gone ahead and posted the draft update that also includes the text changes for your other comments that were prepared by co-authors.
This should help the WG review the latest version during the WGLC that you have just started. We can continue discussion on the WGLC thread for further text refinement as needed. Thanks, Ketan On Tue, Dec 10, 2024 at 2:48 AM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> wrote: > Hi Ketan, > > My email was a bit rushed. > The new text somewhat addresses my concerns: > > - "the advertisement of this route" does imply "if the route is used". > - while the consistency is more with existing implementations, > "consistency with [RFC9252]" is ok. > > Anyway, the WGLC has been issued with the -02 version. You can make the > changes as part of the LC process. > > Thanks. > Jeffrey > > > Juniper Business Use Only > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org> > Sent: Monday, December 9, 2024 12:27 PM > To: Ketan Talaulikar <ketant.i...@gmail.com>; Luc André Burdet < > laburdet.i...@gmail.com> > Cc: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org>; Wen > Lin <w...@juniper.net>; bess-cha...@ietf.org; > draft-ietf-bess-bgp-srv6-a...@ietf.org; BESS <bess@ietf.org> > Subject: [bess] Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > [External Email. Be cautious of content] > > > I believe we have been going in circles, but I will stop here. > > Thanks. > Jeffrey > > > Juniper Business Use Only > > Juniper Business Use Only > -----Original Message----- > From: Ketan Talaulikar <ketant.i...@gmail.com> > Sent: Monday, December 9, 2024 11:29 AM > To: Luc André Burdet <laburdet.i...@gmail.com> > Cc: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org>; > Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Wen Lin <w...@juniper.net>; > bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@ietf.org; BESS < > bess@ietf.org> > Subject: Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > [External Email. Be cautious of content] > > > 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 PM Luc André Burdet <laburdet.i...@gmail.com> > wrote: > > > Jeffrey, all, > > > > > > > > I find the change to “if this route is advertised” to be imprecise: ‘if’ > > implies EtherA-D per ES is an optional route, incl for multihoming. > > > > I disagree this change is needed and the original text was fine – this > > draft is about the args presence 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. > > > > > > > > For reference, the use of ESI Filtering itself (vs. Local-bias) is in > > the EtherA-D per ES ( > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > > t-ietf-bess-evpn-mh-split-horizon-11*section-2.2__;Iw!!NEt6yMaO-gk!EWg > > S9nEhyqi5gCC11-VO5d6kZkf82A0iNk6oIptOlZ4K2oKHmp6k__WiWFtyNLie9CI34iE7i > > f5vE-WS3dIewA$ ), adding ambiguity to that advertisement here doesn’t > make sense. The 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é > > > > > > > > Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 > > 254 > > 4814 > > > > > > > > > > > > *From: *Jorge Rabadan (Nokia) > > <jorge.rabadan=40nokia....@dmarc.ietf.org> > > *Date: *Friday, December 6, 2024 at 08:03 > > *To: *Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>, Ketan Talaulikar < > > ketant.i...@gmail.com> > > *Cc: *Wen Lin <w...@juniper.net>, bess-cha...@ietf.org < > > bess-cha...@ietf.org>, draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@ietf.org>, BESS <bess@ietf.org> > > *Subject: *[bess] Re: draft-ietf-bess-bgp-srv6-args missing on BESS > > wiki > > > > Hi Jeffrey, > > > > > > > > I didn’t think the second red text was necessary, but I don’t have a > > strong opinion about it and I’m 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 “is carried” > > > > > > > > Thanks. > > > > Jorge > > > > > > > > > > > > *From: *Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Date: *Thursday, December 5, 2024 at 2:47 PM > > *To: *Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Wen Lin < > > w...@juniper.net>, bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@ietf.org>, BESS <bess@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 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 > > second 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 first red change. > > > > > > > > Thanks. > > Jeffrey > > > > > > > > > > > > Juniper Business Use Only > > > > *From:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Sent:* Tuesday, November 26, 2024 2:04 PM > > *To:* Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc:* Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; Wen Lin < > > w...@juniper.net>; bess-cha...@ietf.org; > > draft-ietf-bess-bgp-srv6-a...@ietf.org; BESS <bess@ietf.org> > > *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 “why is ‘SHOULD’ used here”. > > 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 > > for > > SRv6 as specified in [RFC9252 > > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf > > -bess-bgp-srv6-args-02.html*RFC9252__;Iw!!NEt6yMaO-gk!FCDVMC3-GhKfDEX9 > > 5WOx_UrELB2SLZ4ok227AMmIW0EBnyt1uX9PbP_uSpaA6wD3NSdBOIR7uUtC8b-jiWOI1w > > $> > > ]." > > > > After a long discussion, now my understanding is that it’s not really > > to “indicate SRv6 support” – because the MAC/IP routes and the AD per > > EVI routes are sufficient in that already – it’s really for backward > > compatibility/consistency (perhaps it is more for consistency than for > > compatibility – unless an existing implementation stops working if it > > does not see the SID ::0 advertised). > > > > > > > > This may seem a nitpick, but since it took us quite some time to > > arrive at this conclusion (I hope we have a consensus now), I’d 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. ß new > > > > The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 > > Service ß deleted > > > > TLV indicates support for SRv6 as specified in [RFC9252]. > > > > Thanks. > > > > Jeffrey > > > > > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > > *Sent:* Monday, November 25, 2024 8:39 AM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Cc:* Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; Wen Lin < > > w...@juniper.net>; bess-cha...@ietf.org; > > draft-ietf-bess-bgp-srv6-a...@ietf.org; BESS <bess@ietf.org> > > *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 > document. > > > > > > > > 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 PM Jeffrey (Zhaohui) Zhang < > > zzh...@juniper.net> wrote: > > > > [+ BESS mailing list] > > > > > > > > Hi Jorge, > > > > > > > > Please see zzh> below. > > > > > > > > > > > > Juniper Business Use Only > > > > *From:* Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > > *Sent:* Friday, November 22, 2024 4:05 PM > > *To:* Wen Lin <w...@juniper.net>; Jeffrey (Zhaohui) Zhang < > > zzh...@juniper.net>; Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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. > > > > > > > > “but as you said “I don’t see the need to signal the support of SRv6 > > as a generic capability at the PE level”” > > > > > > > > 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’t > > 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 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 > > Zzh> routes > > have sufficient encapsulation information. Adding that to the per-ES > > route is really like an appendix. I can understand you want to do it > > for backward compatibility and/or consistency reasons – so I suggest the > following 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 ß 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. ß new > > > > The presence of BGP Prefix-SID Attribute carrying an SRv6 L2 > > Service ß deleted > > > > TLV indicates support for SRv6 as specified in [RFC9252]. > > > > > > > > Zzh> Does that make sense? This whole discussion started with my > > Zzh> question > > “why ‘SHOULD’ is used”. BTW, when this document goes through more > > reviews, there may be questions like “what if it is not included” > > (people like to ask that question with the SHOULD keyword). > > > > Zzh> Thanks. > > > > Zzh> Jeffrey > > > > > > > > Thanks! > > > > Jorge > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > *From: *Wen Lin <w...@juniper.net> > > *Date: *Friday, November 22, 2024 at 12:19 PM > > *To: *Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>, Jorge Rabadan > > (Nokia) <jorge.raba...@nokia.com>, Ketan Talaulikar > > <ketant.i...@gmail.com> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@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 > > <https://urldefense.com/v3/__http:/nok.it/ext__;!!NEt6yMaO-gk!AeF1ZC8p > > FkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQ > > zkNAPFkg$> > > 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’re 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 <zzh...@juniper.net> > > *Date: *Friday, November 22, 2024 at 2:49 PM > > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Wen Lin < > > w...@juniper.net>, Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@ietf.org> > > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > Hi Jorge, > > > > > > > > Here is what I think, point by point: > > > > · If we do not need to signal “I am using SRv6”, 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 “I don’t see the need > > to signal the support of SRv6 as a generic capability at the PE > > level”. The signaling does not convey any information if we do not > > need to signal “I am using SRv6”, and an ingress PE will use argument > > if and only if it is signaled 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 > > > > > > > > · If we do need to signal “I am using SRv6”, then because RFC7432 > > does not talk about ESI-0 type-1 routes for regular EVPN, we need to > > call it out that we’re using ESI-0 type-1 route (when there is no > > MHES) to signal “I am using SRv6”, and we need to say what RT to use – > > it’s an RT that gets the ESI-0 route to every PE. > > > > Jeffrey > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > *From:* Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > > *Sent:* Friday, November 22, 2024 1:47 PM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Wen Lin < > > w...@juniper.net>; Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 service TLV. > > > > > > > > That’s how it’s been implemented and deployed. So what how would you > > change the text above in red to clarify that? > > > > > > > > Thanks. > > > > Jorge > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > *From: *Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Date: *Friday, November 22, 2024 at 9:38 AM > > *To: *Wen Lin <w...@juniper.net>, Jorge Rabadan (Nokia) < > > jorge.raba...@nokia.com>, Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@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 > > <https://urldefense.com/v3/__http:/nok.it/ext__;!!NEt6yMaO-gk!AeF1ZC8p > > FkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQ > > zkNAPFkg$> > > 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’re > > 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 <w...@juniper.net> > > *Sent:* Friday, November 22, 2024 12:35 PM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Jorge Rabadan > > (Nokia) <jorge.raba...@nokia.com>; Ketan Talaulikar > > <ketant.i...@gmail.com> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 <zzh...@juniper.net> > > *Date: *Friday, November 22, 2024 at 12:30 PM > > *To: *Wen Lin <w...@juniper.net>, Jorge Rabadan (Nokia) < > > jorge.raba...@nokia.com>, Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@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 <w...@juniper.net> > > *Sent:* Friday, November 22, 2024 12:22 PM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Jorge Rabadan > > (Nokia) <jorge.raba...@nokia.com>; Ketan Talaulikar > > <ketant.i...@gmail.com> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 <zzh...@juniper.net> > > *Date: *Friday, November 22, 2024 at 10:56 AM > > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Ketan > > Talaulikar < ketant.i...@gmail.com>, Wen Lin <w...@juniper.net> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@ietf.org> > > *Subject: *RE: draft-ietf-bess-bgp-srv6-args missing on BESS wiki > > > > I don’t see the need to signal the support of SRv6 as a generic > > capability at the PE level. > > > > That’s my point. As a result, the red text should be removed 😊 > > > > > > > > > > > > Juniper Business Use Only > > > > *From:* Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > > *Sent:* Friday, November 22, 2024 10:55 AM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Ketan Talaulikar < > > ketant.i...@gmail.com>; Wen Lin <w...@juniper.net> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 > > 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 route that covers P and that route comes > > with the BGP Prefix SID and the SRv6 information. > > > > > > > > I don’t see the need to signal the support of SRv6 as a generic > > capability at the PE level. The current implementations do not use > > that. Same goes for other encapsulations supported by EVPN – MPLS, > MPLSoGRE, VXLAN, GENEVE... > > 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 <zzh...@juniper.net> > > *Date: *Friday, November 22, 2024 at 7:11 AM > > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Ketan > > Talaulikar < ketant.i...@gmail.com>, Wen Lin <w...@juniper.net> > > *Cc: *bess-cha...@ietf.org <bess-cha...@ietf.org>, > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@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 > > <https://urldefense.com/v3/__http:/nok.it/ext__;!!NEt6yMaO-gk!AeF1ZC8p > > FkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQ > > zkNAPFkg$> > > for additional information. > > > > > > > > Hi Jorge, > > > > > > > > That red text is about the following: > > > > > > > > Even if ESI filtering is not needed, to signal that the advertising > > router 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’d need explicitly call out the following for the purpose of > > signaling “I support SRv6” > > > > > > > > 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) <jorge.raba...@nokia.com> > > *Sent:* Friday, November 22, 2024 9:49 AM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Ketan Talaulikar < > > ketant.i...@gmail.com>; Wen Lin <w...@juniper.net> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 <zzh...@juniper.net> > > *Sent:* Friday, November 22, 2024 05:56 > > *To:* Ketan Talaulikar <ketant.i...@gmail.com>; Jorge Rabadan (Nokia) > > < jorge.raba...@nokia.com>; Wen Lin <w...@juniper.net> > > *Cc:* bess-cha...@ietf.org <bess-cha...@ietf.org>; > > draft-ietf-bess-bgp-srv6-a...@ietf.org < > > draft-ietf-bess-bgp-srv6-a...@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 > > <https://urldefense.com/v3/__http:/nok.it/ext__;!!NEt6yMaO-gk!AeF1ZC8p > > FkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQ > > zkNAPFkg$> > > for additional information. > > > > > > > > Hi Jorge, Wen, > > > > > > > > I was asking you on the side about type-1 per EVI route. With RFC7432 > > (for regular EVPN, not E-Tree), the type-1 route is only used for > > multi-homing case, and they’re advertised with non-0 ESIs. If there is > > no multi-homing, then they’re 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 the 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 <zzh...@juniper.net> > > *Sent:* Friday, November 15, 2024 10:20 AM > > *To:* Ketan Talaulikar <ketant.i...@gmail.com> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 or 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 > > not 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’s 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’s P-Tunnel Attribute > > > > Based on local provisioning (that all PEs support SRv6) > > > > > > > > Jeffrey > > > > > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > > *Sent:* Friday, November 15, 2024 6:10 AM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 AM Jeffrey (Zhaohui) Zhang < > > zzh...@juniper.net> wrote: > > > > Hi Ketan, > > > > > > > > Please see zzh> below. > > > > > > > > > > > > Juniper Business Use Only > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > > *Sent:* Tuesday, November 12, 2024 11:37 AM > > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > > *Cc:* bess-cha...@ietf.org; draft-ietf-bess-bgp-srv6-a...@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 PM Jeffrey (Zhaohui) Zhang < > > zzh...@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 > > following that is mentioned in the "backward compatibility" section: > > > > > > > > KT> This is indeed one of the issues - the procedure in RFC9252 (which > > KT> 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 > > KT> the > > example in figure 7 and placing it under the backward compatibility > > section draws special attention to it in terms of change of procedure. > > > > > > > > Zzh> The change of procedure (from bitwise logical-OR to filling the > > Zzh> Arg > > bits from the type-1 signaling), as per my understanding, is the key > > change in this document. As such, it should be mentioned at the very > > beginning of the document. > > > > > > > > Zzh> In addition, the backward compatibility section can be simply > > Zzh> changed > > 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 > > KT> 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 > > most 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 > > for > > SRv6 as specified in [RFC9252 > > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf > > -bess-bgp-srv6-args-02.html*RFC9252__;Iw!!NEt6yMaO-gk!FCDVMC3-GhKfDEX9 > > 5WOx_UrELB2SLZ4ok227AMmIW0EBnyt1uX9PbP_uSpaA6wD3NSdBOIR7uUtC8b-jiWOI1w > > $> > > ]." > > > > Zzh> The Type-1 route is advertised only for MHESes and a deployment > > Zzh> w/o > > MHES will not have type-1 routes so relying on the above is not > > robust. For comparison, type-3 routes are always present it is better > > to rely on that > > _______________________________________________ > BESS mailing list -- bess@ietf.org > To unsubscribe send an email to bess-le...@ietf.org >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
