[bess] Re: draft-ietf-bess-bgp-srv6-args missing on BESS wiki

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]>
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://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-split-horizon-11#section-2.2)
> 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  |  [e-mail]  |  Tel: [phone]
> 4814
>
>
>
>
>
> *From: *Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]>
> *Date: *Friday, December 6, 2024 at 08:03
> *To: *Jeffrey (Zhaohui) Zhang <[e-mail]>, Ketan Talaulikar <
> [e-mail]>
> *Cc: *Wen Lin <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, BESS <[e-mail]>
> *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 <[e-mail]>
> *Date: *Thursday, December 5, 2024 at 2:47 PM
> *To: *Ketan Talaulikar <[e-mail]>
> *Cc: *Jorge Rabadan (Nokia) <[e-mail]>, Wen Lin <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>, BESS <[e-mail]>
> *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 <[e-mail]>
> *Sent:* Tuesday, November 26, 2024 2:04 PM
> *To:* Ketan Talaulikar <[e-mail]>
> *Cc:* Jorge Rabadan (Nokia) <[e-mail]>; Wen Lin <
> [e-mail]>; [e-mail];
> [e-mail]; BESS <[e-mail]>
> *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-GhKfDEX95WOx_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 <[e-mail]>
> *Sent:* Monday, November 25, 2024 8:39 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Jorge Rabadan (Nokia) <[e-mail]>; Wen Lin <
> [e-mail]>; [e-mail];
> [e-mail]; BESS <[e-mail]>
> *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 <
> [e-mail]> wrote:
>
> [+ BESS mailing list]
>
>
>
> Hi Jorge,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Jorge Rabadan (Nokia) <[e-mail]>
> *Sent:* Friday, November 22, 2024 4:05 PM
> *To:* Wen Lin <[e-mail]>; Jeffrey (Zhaohui) Zhang <
> [e-mail]>; Ketan Talaulikar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 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 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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 12:19 PM
> *To: *Jeffrey (Zhaohui) Zhang <[e-mail]>, Jorge Rabadan (Nokia)
> <[e-mail]>, Ketan Talaulikar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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!AeF1ZC8pFkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQzkNAPFkg$>
> 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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 2:49 PM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>, Wen Lin <
> [e-mail]>, Ketan Talaulikar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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) <[e-mail]>
> *Sent:* Friday, November 22, 2024 1:47 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Wen Lin <
> [e-mail]>; Ketan Talaulikar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 9:38 AM
> *To: *Wen Lin <[e-mail]>, Jorge Rabadan (Nokia) <
> [e-mail]>, Ketan Talaulikar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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!AeF1ZC8pFkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQzkNAPFkg$>
> 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 <[e-mail]>
> *Sent:* Friday, November 22, 2024 12:35 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Jorge Rabadan (Nokia)
> <[e-mail]>; Ketan Talaulikar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 12:30 PM
> *To: *Wen Lin <[e-mail]>, Jorge Rabadan (Nokia) <
> [e-mail]>, Ketan Talaulikar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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 <[e-mail]>
> *Sent:* Friday, November 22, 2024 12:22 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Jorge Rabadan (Nokia)
> <[e-mail]>; Ketan Talaulikar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 10:56 AM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>, Ketan Talaulikar <
> [e-mail]>, Wen Lin <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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) <[e-mail]>
> *Sent:* Friday, November 22, 2024 10:55 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Ketan Talaulikar <
> [e-mail]>; Wen Lin <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Date: *Friday, November 22, 2024 at 7:11 AM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>, Ketan Talaulikar <
> [e-mail]>, Wen Lin <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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!AeF1ZC8pFkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQzkNAPFkg$>
> 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) <[e-mail]>
> *Sent:* Friday, November 22, 2024 9:49 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Ketan Talaulikar <
> [e-mail]>; Wen Lin <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Sent:* Friday, November 22, 2024 05:56
> *To:* Ketan Talaulikar <[e-mail]>; Jorge Rabadan (Nokia) <
> [e-mail]>; Wen Lin <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>
> *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!AeF1ZC8pFkGdRCchLDn7CuW-sQuYiuvLLspI1e4CBDt_oKoD8gDUGQeYR88PbyMsXOq0SqSKkNA5CQzkNAPFkg$>
> 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 <[e-mail]>
> *Sent:* Friday, November 15, 2024 10:20 AM
> *To:* Ketan Talaulikar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Sent:* Friday, November 15, 2024 6:10 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <
> [e-mail]> wrote:
>
> Hi Ketan,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Tuesday, November 12, 2024 11:37 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <
> [e-mail]> 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 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 section
> 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 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 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 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-GhKfDEX95WOx_UrELB2SLZ4ok227AMmIW0EBnyt1uX9PbP_uSpaA6wD3NSdBOIR7uUtC8b-jiWOI1w$>
> ]."
>
> 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. For
> 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 or
> others on this thread clarify/correct me.
>
>
>
>
> BTW, should "is carried" be removed from the above? Otherwise, it does not
> 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.  …
>
>
>
>  Zzh> It’s more natural to point out ahead of the steps that different 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 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 transposition is used.
>
> Zzh> Because of the following:
>
>
>
>    … 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 <[e-mail]>
> Sent: Sunday, November 3, 2024 5:47 AM
> To: [e-mail]
> Cc: [e-mail]
> 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 during
> interop for the WG RFC9252.
>
>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/MDpZsTSaYv9AAfQenspGqEZA7NY/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgRev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbtV-bB7iA$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/MDpZsTSaYv9AAfQenspGqEZA7NY/__;!!NEt6yMaO-gk!A1ZuctuyKwod3SQxthy_1ldkgRev1nD2fTWFAGXqpdtMd1cloApBDL4ksVdtH6n-KRJYCAeeIbhVNbtV-bB7iA$>
>
> That was in March 2024. I hope our position on the Q is being tracked :-)
>
> Thanks,
> Ketan
>
> ---------- Forwarded message ---------
> From: Ketan Talaulikar <[e-mail]>
> Date: Sun, Nov 3, 2024 at 10:41 AM
> Subject: Re: [bess] I-D Action: draft-ietf-bess-bgp-srv6-args-02.txt
> To: <[e-mail]>
>
>
> 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 AM <[e-mail]> 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
> <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
> <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=
> <https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=>
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>