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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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]<mailto:[e-mail]>>
Sent: Monday, November 25, 2024 8:39 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
[+ BESS mailing list]

Hi Jorge,

Please see zzh> below.



Juniper Business Use Only
From: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 4:05 PM
To: Wen Lin <[e-mail]<mailto:[e-mail]>>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 12:19 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 2:49 PM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Wen Lin <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 1:47 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 9:38 AM
To: Wen Lin <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 12:35 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 12:30 PM
To: Wen Lin <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 12:22 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 10:56 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>, Wen Lin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 10:55 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Friday, November 22, 2024 at 7:11 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>, Wen Lin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 9:49 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 22, 2024 05:56
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 15, 2024 10:20 AM
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, November 15, 2024 6:10 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Hi Ketan,

Please see zzh> below.



Juniper Business Use Only
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 12, 2024 11:37 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Sunday, November 3, 2024 5:47 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>