Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

From: Salih K A <[email-masked]>
Date: Thu, 22 Jul 2021 08:32:22 +0000

Hi Ketan,

1 clarification query:

With flex algo and SRTE policies, service routes can carry color extended communities.
Now for the ingress, how to decide whether to resolve over SRv6 Service SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
In a domain both can be present & operators may want fallbacks as well if one is not available. So, I think it’s better to clarify that to avoid ambiguity.

Thanks,
Salih
From: spring <[email-masked]> on behalf of "Ketan Talaulikar (ketant)" <ketant=[email-masked]>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Resending with individual email addressed trimmed

From: Ketan Talaulikar (ketant)
Sent: 22 July 2021 13:13
To: Rajesh M <[email-masked]>; Rajesh M <mrajesh=[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; [email-masked]; Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>; [email-masked]; Srihari Sangli <[email-masked]>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Rajesh,

My apologies for the delay in my response. However, some of my co-authors and other WG members have already clarified this point. Let me try to summarize.

The draft covers two SRv6 based mechanisms for the transport of services between SRv6 PEs. (1) using SR Policy based steering (i.e. for service routes with Color Extended Communities) using the H.encap construct along with a list of SRv6 segments  and the other (2) using H.encap with just the SRv6 Service SID in the IPv6 DA.

As mentioned in the draft, it is required to verify the reachability of the SRv6 Service SID before the mechanism (2) can be used. This is an explicit clarification for verification of reachability. In an MPLS-VPN scenario, if the egress PE NH’s IP route is reachable at the ingress PE but without an MPLS label, such a path cannot be used. This is semantically similar.

The mechanism (1) is different since the routing to the egress PE is via SR Policy and hence the requirement for verification of reachability of the SRv6 Service SID is not there.

There is no mandate for the setting of the NH since that is left to deployment design.

I hope this helps in addition to the various clarifications already provided by others.

Thanks,
Ketan

From: Rajesh M <[email-masked]<mailto:[email-masked]>>
Sent: 22 July 2021 12:09
To: Rajesh M <mrajesh=[email-masked]<mailto:mrajesh=[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Srihari Sangli <[email-masked]<mailto:[email-masked]>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Could Authors respond to this ?

Juniper Business Use Only
From: Rajesh M <mrajesh=[email-masked]<mailto:mrajesh=[email-masked]>>
Sent: Monday, July 19, 2021 7:28 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Rajesh M <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Srihari Sangli <[email-masked]<mailto:[email-masked]>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

For best effort service, flex algo – Resolve SRv6 Service SID for forwarding.
For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.

There is no unification here, it’s better to unify.
Any other solution is OK.

Thanks
Rajesh

Juniper Business Use Only
From: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 19, 2021 7:17 PM
To: Rajesh M <[email-masked]<mailto:[email-masked]>>; Rajesh M <mrajesh=[email-masked]<mailto:mrajesh=[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Srihari Sangli <[email-masked]<mailto:[email-masked]>>
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the locator, but there are cases in which the next-hop address is not part of the locator prefix, and there are implementations already allowing that, so I don’t agree the document should mandate what you are suggesting.

Thanks.
Jorge

From: Rajesh M <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M <mrajesh=[email-masked]<mailto:mrajesh=[email-masked]>>, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Srihari Sangli <[email-masked]<mailto:[email-masked]>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Hi Authors,

Please respond.

Thanks
Rajesh

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi All,

As per this draft, this is how resolution must work.

1)For Non Intent service Route:
if BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding.

2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):
BGP next hop is not reachable return.
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully resolves then return.
Resolve BGP next hop for forwarding (in case above is not success).

Using Service SID (overlay),for resolution is definitely not recommended.

Instead in case of srv6, we always resolve on BGP nexthop. This will be in line with BGP legacy.
In case of best effort/flex algo we must mandate user to set corresponding locator as BGP nexthop for srv6 routes.
I think this is a reasonable mandate.

Thanks
Rajesh

Juniper Business Use Only

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 22 Jul 2021 08:55:29 +0000

Hi Salih,

Could you please check the following regarding the choice/fallback when using SR Policy based steering?

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8

Thanks,
Ketan

From: Salih K A <[email-masked]>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Rajesh M <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

1 clarification query:

Thanks,
Salih
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Ketan Talaulikar (ketant)" <ketant=[email-masked]<mailto:ketant=[email-masked]>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

From: Ketan Talaulikar (ketant)
Sent: 22 July 2021 13:13
To: Rajesh M <[email-masked]<mailto:[email-masked]>>; Rajesh M <mrajesh=[email-masked]<mailto:mrajesh=[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Clarence Filsfils (cfilsfil) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Srihari Sangli <[email-masked]<mailto:[email-masked]>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Rajesh,

Thanks,
Ketan

Hi All,

Thanks
Rajesh

Hi Rajesh,

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh

---

From: Rajesh M <[email-masked]>
Date: Thu, 22 Jul 2021 09:14:20 +0000

Hi Ketan,

As per CAR draft - For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy):

So below must be the rules right ?
BGP next hop is not reachable return (just for reachability).
Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfully resolves then return.
Resolve BGP next hop for forwarding either by CAR or by SR-policy (in case above is not success).

Thanks
Rajesh

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Thursday, July 22, 2021 2:25 PM
To: Salih K A <[email-masked]>; Rajesh M <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Salih,

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!UVtxbzzcrG5uslNvEdjH34VnBanX7PHCCU487ZgaxyKBxCr8lhxEKIxQD-4i7eL9$>
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!UVtxbzzcrG5uslNvEdjH34VnBanX7PHCCU487ZgaxyKBxCr8lhxEKIxQD9V3qgJv$>

Thanks,
Ketan

From: Salih K A <[email-masked]<mailto:[email-masked]>>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Rajesh M <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

1 clarification query:

With flex algo and SRTE policies, service routes can carry color extended communities.
Now for the ingress, how to decide whether to resolve over SRv6 Service SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
In a domain both can be present & operators may want fallbacks as well if one is not available. So, I think it's better to clarify that to avoid ambiguity.

Thanks,
Salih

Hi Rajesh,

As mentioned in the draft, it is required to verify the reachability of the SRv6 Service SID before the mechanism (2) can be used. This is an explicit clarification for verification of reachability. In an MPLS-VPN scenario, if the egress PE NH's IP route is reachable at the ingress PE but without an MPLS label, such a path cannot be used. This is semantically similar.

Thanks,
Ketan

Hi All,

For best effort service, flex algo - Resolve SRv6 Service SID for forwarding.
For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.

There is no unification here, it's better to unify.
Any other solution is OK.

Thanks
Rajesh

Hi Rajesh,

The draft is written so that the next-hop address MAY be covered by the locator, but there are cases in which the next-hop address is not part of the locator prefix, and there are implementations already allowing that, so I don't agree the document should mandate what you are suggesting.

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 22 Jul 2021 09:47:18 +0000

Hi Rajesh,

I think there might be some confusion here with the mix-up between a draft which is past WGLC and an individual draft? Would it be possible to keep their discussions on separate threads?

However, since I am an author on both, I would like to clarify is that "the rules" are merely being used as an example in the BGP CAR draft : https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-02#section-3

Whether we form WG consensus on codifying this preference as a "default" still remains to be seen. Irrespective, when it comes to such things there might be operators that would like to have some policy control.

If we just focus on the SR Policy based steering then we have the following in SR Policy draft (https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4) that I had pointed to below. This indicates a preference for steering over SR Policy using color extended community.

Thanks,
Ketan

From: Rajesh M <[email-masked]>
Sent: 22 July 2021 14:44
To: Ketan Talaulikar (ketant) <[email-masked]>; Salih K A <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

Thanks
Rajesh

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 22, 2021 2:25 PM
To: Salih K A <[email-masked]<mailto:[email-masked]>>; Rajesh M <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Salih,

Thanks,
Ketan

Hi Ketan,

1 clarification query:

Thanks,
Salih

Hi Rajesh,

Thanks,
Ketan

Hi All,

Thanks
Rajesh

Hi Rajesh,

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh

---

From: Salih K A <[email-masked]>
Date: Thu, 22 Jul 2021 10:05:12 +0000

Thanks, Ketan.

This indicates a preference for steering over SR Policy while using color extended community.
Then specify color only bits etc modes for specifying fallbacks if required. Currently it doesn’t talk about flex (but mention mostly IGP path to the next-hop N) and hence it need not necessarily pick SRv6 flex algo paths.

Are we suggesting only if some indication comes the fallback will happen to flex algo? OR can we define an order like:
SRv6 policy (using BGP NH)
SRv6 Flex (using SRv6 Service SID)

and a mention of local policy which can override if required.

Regards,
Salih
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thursday, July 22, 2021 at 2:25 PM
To: Salih K A <[email-masked]>, Rajesh M <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Salih,

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMOUxwCSPQ$>
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMMv4_vtIA$>

Thanks,
Ketan

Hi Ketan,

1 clarification query:

Thanks,
Salih

Hi Rajesh,

Thanks,
Ketan

Hi All,

Thanks
Rajesh

Hi Rajesh,

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 22 Jul 2021 10:41:15 +0000

Hi Salih,

The preference for steering over SR Policy applies to both SR-MPLS and SRv6. So we are covered from that perspective.

I get the impression that this email discussion thread about “fallback” is about when sending over a non-SR Policy based steering mechanism. That too, I get the impression is that it is specifically about the scenario where there might not be a reachability via IGP FlexAlgo for the egress PE’s Locator from which the SRv6 service SID is allocated from.

To me (and few other WG members), an alternate path or tunnel mechanism to reach the egress PE is something that is deployment specific and can be implemented via various mechanisms. While Shraddha has proposed a mechanism for this, I’ve also described a new other ways – there will be more. While the draft currently does not discuss this, it does not preclude any of these mechanisms either.

The draft is currently done with WGLC and is in our AD (Martin’s) Q for his review. The question for the WG is if we do really need to clarify something about this “FlexAlgo fallback” case and if so, come up with some proposed text. IMHO details of such fallback mechanisms are outside the scope of this document and we can say so if that helps.

Thanks,
Ketan

From: Salih K A <[email-masked]>
Sent: 22 July 2021 15:35
To: Ketan Talaulikar (ketant) <[email-masked]>; Rajesh M <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Thanks, Ketan.

Regards,
Salih
From: "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 22, 2021 at 2:25 PM
To: Salih K A <[email-masked]<mailto:[email-masked]>>, Rajesh M <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Salih,

Thanks,
Ketan

Hi Ketan,

1 clarification query:

Thanks,
Salih

Hi Rajesh,

Thanks,
Ketan

Hi All,

Thanks
Rajesh

Hi Rajesh,

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Jul 2021 13:49:03 +0200

IMO we could add to the draft a statement that implementation MUST/SHOULD
support fallback to any available forwarding plane. But I am not sure if
this will not turn out against some implementations which may have problem
with that.

Order of such fallback is a policy/cfg decision.

Likewise before considering any forwarding plane use a data plane
reachability to the endpoint must be validated/tested - that should go
without saying but as we know there are implementations which only rely on
a control plane which is proven in action to be a rather poor method. There
are number of reasons where presence in RIB/inet does is not the same as
data plane reachability .

Thx,
Robert.

On Thu, Jul 22, 2021 at 12:41 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Salih,
>
>
>
> The preference for steering over SR Policy applies to both SR-MPLS and
> SRv6. So we are covered from that perspective.
>
>
>
> I get the impression that this email discussion thread about “fallback” is
> about when sending over a non-SR Policy based steering mechanism. That too,
> I get the impression is that it is specifically about the scenario where
> there might not be a reachability via IGP FlexAlgo for the egress PE’s
> Locator from which the SRv6 service SID is allocated from.
>
>
>
> To me (and few other WG members), an alternate path or tunnel mechanism to
> reach the egress PE is something that is deployment specific and can be
> implemented via various mechanisms. While Shraddha has proposed a mechanism
> for this, I’ve also described a new other ways – there will be more. While
> the draft currently does not discuss this, it does not preclude any of
> these mechanisms either.
>
>
>
> The draft is currently done with WGLC and is in our AD (Martin’s) Q for
> his review. The question for the WG is if we do really need to clarify
> something about this “FlexAlgo fallback” case and if so, come up with some
> proposed text. IMHO details of such fallback mechanisms are outside the
> scope of this document and we can say so if that helps.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A <[email-masked]>
> *Sent:* 22 July 2021 15:35
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Rajesh M <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Thanks, Ketan.
>
>
>
> Then specify color only bits etc modes for specifying fallbacks if
> required. Currently it doesn’t talk about flex (but mention mostly IGP path
> to the next-hop N) and hence it need not necessarily pick SRv6 flex algo
> paths.
>
>
>
> Are we suggesting only if some indication comes the fallback will happen
> to flex algo? OR can we define an order like:
>
> *From: *"Ketan Talaulikar (ketant)" <[email-masked]>
> *Date: *Thursday, July 22, 2021 at 2:25 PM
> *To: *Salih K A <[email-masked]>, Rajesh M <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Salih,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMOUxwCSPQ$>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMMv4_vtIA$>
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A <[email-masked]>
> *Sent:* 22 July 2021 14:02
> *To:* Ketan Talaulikar (ketant) <ketant=[email-masked]>;
> Rajesh M <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Ketan,
>
>
>
> 1 clarification query:
>
>
>
> Now for the ingress, how to decide whether to resolve over SRv6 Service
> SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
>
> In a domain both can be present & operators may want fallbacks as well if
> one is not available. So, I think it’s better to clarify that to avoid
> ambiguity.
>
>
>
> Thanks,
> Salih
>
> *From: *spring <[email-masked]> on behalf of "Ketan Talaulikar
> (ketant)" <ketant=[email-masked]>
> *Date: *Thursday, July 22, 2021 at 1:19 PM
> *To: *Rajesh M <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> *From:* Ketan Talaulikar (ketant)
> *Sent:* 22 July 2021 13:13
> *To:* Rajesh M <[email-masked]>; Rajesh M <
> mrajesh=[email-masked]>; Rabadan, Jorge (Nokia -
> US/Mountain View) <[email-masked]>; [email-masked];
> Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>;
> [email-masked]; Srihari Sangli <[email-masked]>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Rajesh,
>
>
>
> My apologies for the delay in my response. However, some of my co-authors
> and other WG members have already clarified this point. Let me try to
> summarize.
>
>
>
> The draft covers two SRv6 based mechanisms for the transport of services
> between SRv6 PEs. (1) using SR Policy based steering (i.e. for service
> routes with Color Extended Communities) using the H.encap construct along
> with a list of SRv6 segments  and the other (2) using H.encap with just the
> SRv6 Service SID in the IPv6 DA.
>
>
>
> As mentioned in the draft, it is required to verify the reachability of
> the SRv6 Service SID before the mechanism (2) can be used. This is an
> explicit clarification for verification of reachability. In an MPLS-VPN
> scenario, if the egress PE NH’s IP route is reachable at the ingress PE but
> without an MPLS label, such a path cannot be used. This is semantically
> similar.
>
>
>
> The mechanism (1) is different since the routing to the egress PE is via
> SR Policy and hence the requirement for verification of reachability of the
> SRv6 Service SID is not there.
>
>
>
> *From:* Rajesh M <[email-masked]>
> *Sent:* 22 July 2021 12:09
> *To:* Rajesh M <mrajesh=[email-masked]>; Rabadan, Jorge
> (Nokia - US/Mountain View) <[email-masked]>; Ketan Talaulikar
> (ketant) <[email-masked]>; [email-masked]; Clarence Filsfils
> (cfilsfil) <[email-masked]>; [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>;
> [email-masked]; Srihari Sangli <[email-masked]>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *From:* Rajesh M <mrajesh=[email-masked]>
> *Sent:* Monday, July 19, 2021 7:28 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>;
> Rajesh M <[email-masked]>; Ketan Talaulikar (ketant) <
> [email-masked]>; [email-masked]; Clarence Filsfils (cfilsfil) <
> [email-masked]>; [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>;
> [email-masked]; Srihari Sangli <[email-masked]>
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
>
> *Sent:* Monday, July 19, 2021 7:17 PM
> *To:* Rajesh M <[email-masked]>; Rajesh M <
> mrajesh=[email-masked]>; Ketan Talaulikar (ketant) <
> [email-masked]>; [email-masked]; Clarence Filsfils (cfilsfil) <
> [email-masked]>; [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>;
> [email-masked]; Srihari Sangli <[email-masked]>
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Rajesh,
>
>
>
> The draft is written so that the next-hop address MAY be covered by the
> locator, but there are cases in which the next-hop address is not part of
> the locator prefix, and there are implementations already allowing that, so
> I don’t agree the document should mandate what you are suggesting.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Rajesh M <[email-masked]>
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M <mrajesh=[email-masked]>, Ketan Talaulikar
> (ketant) <[email-masked]>, [email-masked] <[email-masked]>,
> Clarence Filsfils (cfilsfil) <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>,
> Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>,
> Shraddha Hegde <[email-masked]>, [email-masked] <[email-masked]>,
> Srihari Sangli <[email-masked]>
> *Subject: *RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
> Hi Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; [email-masked];
> Clarence Filsfils (cfilsfil) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>;
> [email-masked]
> *Subject:* [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> *Using Service SID (overlay),for resolution is definitely not recommended.*
>
>
>
> *Instead in case of srv6, we always resolve on BGP nexthop. This will be
> in line with BGP legacy.*
>
> *In case of best effort/flex algo we must mandate user to set
> corresponding locator as BGP nexthop for srv6 routes.*
>
> *I think this is a reasonable mandate.*
>
>
>
> Thanks
>
> Rajesh
>
>
>

---

From: Rajesh M <[email-masked]>
Date: Fri, 23 Jul 2021 02:36:42 +0000

Hi Ketan,

   When the BGP route received at an ingress PE is colored with an

   extended color community and is being steered over a valid SRv6

   Policy associated with SID list <S1, S2, S3> as described in

   Section 8 of [I-D.ietf-spring-segment-routing-policy<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-07#ref-I-D.ietf-spring-segment-routing-policy>], then the

   effective SR Policy is <S1, S2, S3-Service-SID>.

Here can we mention explicitly  S3, S3-service-SID must be from same locator ?

Thanks
Rajesh

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Thursday, July 22, 2021 3:17 PM
To: Rajesh M <[email-masked]>; Salih K A <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Rajesh,

However, since I am an author on both, I would like to clarify is that "the rules" are merely being used as an example in the BGP CAR draft : https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-02#section-3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-02*section-3__;Iw!!NEt6yMaO-gk!QpmAhrQu3XtRvL-K3ie5uADSr_7c9EN1s9JGDl42uucq-R4nlzHztLWN8jTwa0Yk$>

If we just focus on the SR Policy based steering then we have the following in SR Policy draft (https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!QpmAhrQu3XtRvL-K3ie5uADSr_7c9EN1s9JGDl42uucq-R4nlzHztLWN8rnjKtKk$>) that I had pointed to below. This indicates a preference for steering over SR Policy using color extended community.

Thanks,
Ketan

From: Rajesh M <[email-masked]<mailto:[email-masked]>>
Sent: 22 July 2021 14:44
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Salih K A <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

Thanks
Rajesh

Hi Salih,

Thanks,
Ketan

Hi Ketan,

1 clarification query:

Thanks,
Salih

Hi Rajesh,

Thanks,
Ketan

Hi All,

Thanks
Rajesh

Hi Rajesh,

Thanks.
Jorge

Please respond.

Thanks
Rajesh

Hi All,

Thanks
Rajesh