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

2021-07-24 Thread Gyan Mishra 
Hi Shraddha

I agree the fallback mechanisms are important to operators but as there are
many complex scenarios related to fallback and some of which include SRv6
to SR-MPLS interworking, I agree that this is important and as such can be
captured in a separate document that defines all the permutations in detail.

As this SRv6 BGP overlay services specification is critical for operators
as it’s in WGLC I think it should proceed to publication.

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 12:40 PM Aissaoui, Mustapha (Nokia - CA/Ottawa) <
mustapha.aissa...@nokia.com> wrote:

> That is great. Thank you.
>
>
>
> Mustapha.
>
>
>
> *From:* Ketan Talaulikar (ketant) 
> *Sent:* Friday, July 23, 2021 11:08 AM
> *To:* Aissaoui, Mustapha (Nokia - CA/Ottawa) 
> *Cc:* spr...@ietf.org; Shraddha Hegde ;
> bess@ietf.org; draft-ietf-bess-srv6-servi...@ietf.org
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> < trimming list to mostly mailers >
>
>
>
> Hi Mustapha,
>
>
>
> I agree.
>
>
>
> Also after seeing Shraddha’s latest email, the coverage and details for
> the fallback mechanisms that she seems to be looking for is quite vast and
> better tackled in a separate document since this one has completed its
> WGLC. Some of those concepts are applicable for MPLS as well and not SRv6
> specific.
>
>
>
> We (authors) will work on some text proposal and get back to the WG next
> week.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Aissaoui, Mustapha (Nokia - CA/Ottawa) <
> mustapha.aissa...@nokia.com>
> *Sent:* 23 July 2021 19:20
> *To:* Ketan Talaulikar (ketant) ; Rajesh M <
> mraj...@juniper.net>; Rajesh M ; Rabadan, Jorge
> (Nokia - US/Mountain View) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> rob...@raszuk.net; bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli ;
> Shraddha Hegde ; bess@ietf.org
> *Subject:* RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Ketan,
>
> I believe it will be worth expanding the text in
> draft-ietf-bess-srv6-services to describe the two types of transport more
> consistently and along the lines of what you wrote below. Also, I would
> propose that we move away from terminology like best-effort service and
> instead just mention shortest path forwarding in base topology or in
> flex-algo topology.
>
>
>
> Mustapha.
>
>
>
> *From:* spring  *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Thursday, July 22, 2021 3:43 AM
> *To:* Rajesh M ; Rajesh M <
> mrajesh=40juniper@dmarc.ietf.org>; Rabadan, Jorge (Nokia -
> US/Mountain View) ; gdawra.i...@gmail.com;
> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli ;
> Shraddha Hegde ; bess@ietf.org
> *Subject:* Re: [spring] 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 
> *Sent:* 22 July 2021 12:09
> *To:* Rajesh M ; Rabadan, Jorge
> (Nokia - US/Mountain View) ; Ketan Talaulikar
> (ketant) ; gdawra.i...@gmail.com; Clarence Filsfils
> (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org; Srihari Sangli 
> *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 
> *Sent:* Monday, July 19, 2021 7:28 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Ketan Talaulikar (ketant) <
> ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <
> cfils...@cisco.com>;

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

2021-07-22 Thread Rajesh M 
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  as described in

   Section 8 of 
[I-D.ietf-spring-segment-routing-policy],
 then the

   effective SR Policy is .

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

Thanks
Rajesh





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

[External Email. Be cautious of content]

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 mailto:mraj...@juniper.net>>
Sent: 22 July 2021 14:44
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Salih K A mailto:sa...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

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) mailto:ket...@cisco.com>>
Sent: Thursday, July 22, 2021 2:25 PM
To: Salih K A mailto:sa...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

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 mailto:sa...@juniper.net>>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Rajesh M mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
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

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

2021-07-22 Thread Robert Raszuk 
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) 
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 
> *Sent:* 22 July 2021 15:35
> *To:* Ketan Talaulikar (ketant) ; Rajesh M <
> mraj...@juniper.net>
> *Cc:* draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org;
> bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> 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)" 
> *Date: *Thursday, July 22, 2021 at 2:25 PM
> *To: *Salih K A , Rajesh M 
> *Cc: *"draft-ietf-bess-srv6-servi...@ietf.org" <
> draft-ietf-bess-srv6-servi...@ietf.org>, "spr...@ietf.org" <
> spr...@ietf.org>, "bess@ietf.org" 
> *Subject: *RE: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 
> *Sent:* 22 July 2021 14:02
> *To:* Ketan Talaulikar (ketant) ;
> Rajesh M 
> *Cc:* draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org;
> bess@ietf.org
> *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
>
> *From: *spring

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

2021-07-22 Thread Ketan Talaulikar (ketant) 
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 
Sent: 22 July 2021 15:35
To: Ketan Talaulikar (ketant) ; Rajesh M 
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

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)" mailto:ket...@cisco.com>>
Date: Thursday, July 22, 2021 at 2:25 PM
To: Salih K A mailto:sa...@juniper.net>>, Rajesh M 
mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

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 mailto:sa...@juniper.net>>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Rajesh M mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
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
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
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

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

2021-07-22 Thread Salih K A 
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)" 
Date: Thursday, July 22, 2021 at 2:25 PM
To: Salih K A , Rajesh M 
Cc: "draft-ietf-bess-srv6-servi...@ietf.org" 
, "spr...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

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 
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) ; Rajesh M 

Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; bess@ietf.org
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
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
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 mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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

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

2021-07-22 Thread Ketan Talaulikar (ketant) 
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 
Sent: 22 July 2021 14:44
To: Ketan Talaulikar (ketant) ; Salih K A 
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

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) mailto:ket...@cisco.com>>
Sent: Thursday, July 22, 2021 2:25 PM
To: Salih K A mailto:sa...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

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 mailto:sa...@juniper.net>>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Rajesh M mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
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
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
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 mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde

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

2021-07-22 Thread Rajesh M 
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) 
Sent: Thursday, July 22, 2021 2:25 PM
To: Salih K A ; Rajesh M 
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

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 mailto:sa...@juniper.net>>
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Rajesh M mailto:mraj...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; bess@ietf.org
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
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
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 mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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

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

2021-07-22 Thread Ketan Talaulikar (ketant) 
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 
Sent: 22 July 2021 14:02
To: Ketan Talaulikar (ketant) ; Rajesh M 

Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; bess@ietf.org
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
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M mailto:mraj...@juniper.net>>
Cc: 
"draft-ietf-bess-srv6-servi...@ietf.org"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
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 mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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 mailto:mraj...@juniper.net>>
Sent: 22 July 2021 12:09
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Ketan Talaulikar 
(ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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 
mailto:mrajesh=40juniper@dmarc.ietf.org>>
Sent: Monday, July 19, 2021 7:28 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Rajesh M 
mailto:mraj...@juniper.net>>; Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net;

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

2021-07-22 Thread Salih K A 
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  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, July 22, 2021 at 1:19 PM
To: Rajesh M 
Cc: "draft-ietf-bess-srv6-servi...@ietf.org" 
, "spr...@ietf.org" , 
"bess@ietf.org" 
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 ; Rajesh M 
; Rabadan, Jorge (Nokia - US/Mountain 
View) ; gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) ; rob...@raszuk.net; bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org; Srihari Sangli 
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 mailto:mraj...@juniper.net>>
Sent: 22 July 2021 12:09
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Ketan Talaulikar 
(ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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 
mailto:mrajesh=40juniper@dmarc.ietf.org>>
Sent: Monday, July 19, 2021 7:28 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Rajesh M 
mailto:mraj...@juniper.net>>; Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org; Srihari Sangli 
mailto:ssan...@juniper.net>>
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) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, July 19, 2021 7:17 PM
To: Rajesh M mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>;
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
rob...@raszuk.net; 
bruno.decra...@orange.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde

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

2021-07-21 Thread Aissaoui, Mustapha (Nokia - CA/Ottawa) 
Hi Shraddha,
do you agree this is about switching between shortest path (in base topology or 
flex-algo topology) and SRv6 policy?

You can describe a fallback strategy but the need to resolve or not the service 
SID is orthogonal and is only dictated by the use of shortest path forwarding 
or SRv6 policy.

Mustapha.
Sent from my iPhone

On Jul 21, 2021, at 5:16 AM, Shraddha Hegde  wrote:


I agree with Jim that fallback needs to be discussed in the draft .

The current draft mandates the resolvability of the service SID. The fact that 
when flex-algo is allowed to
Fallback to best effort,  service SID resolvability is not required  because 
service SID corresponds to flex-algo locator in this case.This is an important 
aspect that needs to be addressed in the draft.

Rgds
Shraddha



Juniper Business Use Only
From: UTTARO, JAMES 
Sent: Tuesday, July 20, 2021 10:59 PM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; 
Srihari Sangli ; Shraddha Hegde ; 
Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6 
service in conjunction with an underlay SLA”. I would propose to change these 
to “SRv6 service using shortest path in base or a flex-algo topology” and “SRv6 
service using SRv6 policy” respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an

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

2021-07-21 Thread Shraddha Hegde 
I agree with Jim that fallback needs to be discussed in the draft .

The current draft mandates the resolvability of the service SID. The fact that 
when flex-algo is allowed to
Fallback to best effort,  service SID resolvability is not required  because 
service SID corresponds to flex-algo locator in this case.This is an important 
aspect that needs to be addressed in the draft.

Rgds
Shraddha



Juniper Business Use Only
From: UTTARO, JAMES 
Sent: Tuesday, July 20, 2021 10:59 PM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; 
Srihari Sangli ; Shraddha Hegde ; 
Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: RE: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to "SRv6 service with best-effort connectivity" and to "SRv6 
service in conjunction with an underlay SLA". I would propose to change these 
to "SRv6 service using shortest path in base or a flex-algo topology" and "SRv6 
service using SRv6 policy" respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph "When providing best-effort 
connectivity..." where it specifically talks about fallback to best-effort and 
if so, perform the resolvability check on the service-SID. Going by what you 
are saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari...


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





"When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer IPv6 header where the 
destination

address is the SRv6 Service SID associated with the related BGP route update.

 Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
Service SID

 before considering the received prefix for the BGP best path computation.

"

"In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths

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

2021-07-20 Thread UTTARO, JAMES 
Comments In-Line..

Thanks,
  Jim Uttaro

From: spring  On Behalf Of Aissaoui, Mustapha (Nokia - 
CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli ; Shraddha Hegde 
; Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6 
service in conjunction with an underlay SLA”. I would propose to change these 
to “SRv6 service using shortest path in base or a flex-algo topology” and “SRv6 
service using SRv6 policy” respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer IPv6 header where the 
destination

address is the SRv6 Service SID associated with the related BGP route update.

 Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
Service SID

 before considering the received prefix for the BGP best path computation.

“

“In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths when a flex-algo path isn’t available. The fallback behavior

SHOULD be governed by local policies.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case.”





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don’t intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) 
to decide to

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

2021-07-20 Thread Aissaoui, Mustapha (Nokia - CA/Ottawa) 
Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6 
service in conjunction with an underlay SLA”. I would propose to change these 
to “SRv6 service using shortest path in base or a flex-algo topology” and “SRv6 
service using SRv6 policy” respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.

Regards,
Mustapha.

From: Srihari Sangli 
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) ; 
Shraddha Hegde ; Robert Raszuk 

Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer IPv6 header where the 
destination

address is the SRv6 Service SID associated with the related BGP route update.

 Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
Service SID

 before considering the received prefix for the BGP best path computation.

“

“In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths when a flex-algo path isn’t available. The fallback behavior

SHOULD be governed by local policies.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case.”





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don’t intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) 
to decide to fall back to best effort or to drop.

Thx,
R.



On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Robert,

What do you mean by SR? is it SR-MPLS or SRv6.
My question is about draft-ietf-bess-srv6-services and applies only to SRv6.

Let me repeat the question.
Do the authors intend to support the case of fallback from SRv6 flex-algo to 
SRv6 best effort transport for SRv6
Services or not?

From your vague answer it appears that authors don’t intend to support any form 
of tunnelling for SRv6
because it is not optimal. Is that the right read?

Rgds

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

2021-07-20 Thread Srihari Sangli 
Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring  On Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo connectivity to the 
egress PE,

the ingress PE encapsulates the payload in an outer IPv6 header where the 
destination

address is the SRv6 Service SID associated with the related BGP route update.

 Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
Service SID

 before considering the received prefix for the BGP best path computation.

“

“In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths when a flex-algo path isn’t available. The fallback behavior

SHOULD be governed by local policies.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case.”





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don’t intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) 
to decide to fall back to best effort or to drop.

Thx,
R.



On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Robert,

What do you mean by SR? is it SR-MPLS or SRv6.
My question is about draft-ietf-bess-srv6-services and applies only to SRv6.

Let me repeat the question.
Do the authors intend to support the case of fallback from SRv6 flex-algo to 
SRv6 best effort transport for SRv6
Services or not?

From your vague answer it appears that authors don’t intend to support any form 
of tunnelling for SRv6
because it is not optimal. Is that the right read?

Rgds
Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 11:17 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Rabadan, 
Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Rajesh M 
mailto:mraj...@juniper.net>>; Rajesh M 
mailto:40juniper@dmarc.ietf.org>>; 
Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
bruno.decra...@orange.com; 
spr...@ietf.org; b...@ans.net; 
Srihari Sangli mailto:ssan...@juniper.net>>; 
bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated 
forwarding using SR. It may not be as