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

[Ketan Talaulikar (ketant)]

Hi Haibo,

Thanks for your feedback and confirmation. Indeed the “alternate steering 
mechanism” is better. Will push this change in the next revision.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
Sent: 28 September 2021 15:31
To: Ketan Talaulikar (ketant) ; bess@ietf.org
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) ; Shraddha Hegde 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

I’m sorry I have missed your reply.

For SRv6 services, we may have two choice for service. Use SRv6 SID to do best 
effort, or use  to steering to a SRv6 Policy。
Also we may use both of them, but most time we are priority to use the SRv6 
Policy than fall-back to SRv6 best effort, while SRv6 Policy is down.
So I think maybe use “alternate steering mechanism” is better.  Or maybe I 
misunderstood the sentence?

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, September 16, 2021 4:55 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; 
bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have 
those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please 
suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

   I think the overall description is OK. But is it appropriate to use the 
word “fallback mechanism”?

Regards,
Haibo

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort 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.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) 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.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) 

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

[Wanghaibo (Rainsword)]

Hi Ketan,

I’m sorry I have missed your reply.

For SRv6 services, we may have two choice for service. Use SRv6 SID to do best 
effort, or use  to steering to a SRv6 Policy。
Also we may use both of them, but most time we are priority to use the SRv6 
Policy than fall-back to SRv6 best effort, while SRv6 Policy is down.
So I think maybe use “alternate steering mechanism” is better.  Or maybe I 
misunderstood the sentence?

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, September 16, 2021 4:55 PM
To: Wanghaibo (Rainsword) ; bess@ietf.org
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) ; Shraddha Hegde 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have 
those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please 
suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

   I think the overall description is OK. But is it appropriate to use the 
word “fallback mechanism”?

Regards,
Haibo

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort 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.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) 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.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
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 

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

[Ketan Talaulikar (ketant)]

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have 
those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please 
suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) ; bess@ietf.org
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) ; Shraddha Hegde 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

   I think the overall description is OK. But is it appropriate to use the 
word "fallback mechanism"?

Regards,
Haibo

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort 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.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) 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.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
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) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 19:20
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Rajesh M mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>; 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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org
Subject: RE: SRv6 BGP based 

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

[Ketan Talaulikar (ketant)]

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort 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.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) 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.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) 
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)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
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) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 19:20
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Rajesh M mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>; 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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 22, 2021 3:43 AM
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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
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 

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

[Aissaoui, Mustapha (Nokia - CA/Ottawa)]

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) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 19:20
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Rajesh M mailto:mraj...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>; 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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 22, 2021 3:43 AM
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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
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 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, 

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

[Ketan Talaulikar (ketant)]

< 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) 
Sent: 23 July 2021 19:20
To: Ketan Talaulikar (ketant) ; 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; 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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 22, 2021 3:43 AM
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; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
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 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 

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

[Shraddha Hegde]

Ketan,



"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."

[KT] Why should the fallback be only over best-effort locator? Why can't it be 
over another Flex-Algo, or some IP-IP tunnel or even perhaps an MPLS path. Why 
just this mechanism and that too is suggested to be mandated as a SHOULD? All 
these techniques and mechanisms would be implementation and more importantly 
deployment specific. Therefore, I do not agree with this text proposal.





I started off with one fallback scenario as to the kind of detail I am 
expecting in the draft.

Ofcourse all of the other fallback scenarios you mentioned need to be captured 
in detail too.

Implementations may choose what fallback mechanisms they support and which ones 
they do not

Support based on the software/hardware capabilities.



This fallback mechanism needs to inter-op between different vendors. If ingress 
is one vendor

And decides to send traffic with certain encapsulation that is not supported on 
the egress, packet will drop.

For example : you are talking about fallback on MPLS path. How is the packet 
going to be encapsulated in this scenario? Where would be the SRv6 service SID 
placed? If another vendor isn't aware of this and doesn't implement handling 
these encapsulations, it's not going to work.



I strongly insist fallback scenarios and details need to be covered in this 
document.

If its not possible to cover this level of detail, then I am ok to update the 
draft saying fallback is out of scope

For this document.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Thursday, July 22, 2021 1:44 PM
To: Shraddha Hegde 
Cc: spr...@ietf.org; bess@ietf.org; draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Hi Shraddha,

As clarified a short while ago on the same thread, the draft talks about two 
SRv6-based transport mechanisms. I believe your comments are not related to the 
SR Policy based steering mechanisms. We already have mechanisms defined for 
fallback in that case.

Since the draft is covering SRv6-based mechanisms, we have obviously no text in 
there for other forms of tunnelling between the PEs.

As has been clarified by others, there can be many different forms of 
reachability or tunnels setup. In the end though, it would be an implementation 
specific mechanism or a way to resolve the SRv6 Service SID over such a tunnel. 
E.g. a backup static route pointing over an IP-in-IP tunnel? Or set color 
extended community locally and steer over an SR Policy that uses best-effort. 
Or other such implementation-specific options via other forms of route-policy.

Please check inline below.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: 20 July 2021 15:26
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.

"

[KT] We have an edit change in the buffer on this text that we will post it 
once the submission window opens over the weekend. How BGP resolves is 
implementation specific and a local policy. E.g. it could be via a backup 
static route as indicated above or via some other mechanisms mentioned above. 
Also note that the usage is a SHOULD to allow implementation-specific 
mechanisms.



"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 

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

[Ketan Talaulikar (ketant)]

Hi Shraddha,

As clarified a short while ago on the same thread, the draft talks about two 
SRv6-based transport mechanisms. I believe your comments are not related to the 
SR Policy based steering mechanisms. We already have mechanisms defined for 
fallback in that case.

Since the draft is covering SRv6-based mechanisms, we have obviously no text in 
there for other forms of tunnelling between the PEs.

As has been clarified by others, there can be many different forms of 
reachability or tunnels setup. In the end though, it would be an implementation 
specific mechanism or a way to resolve the SRv6 Service SID over such a tunnel. 
E.g. a backup static route pointing over an IP-in-IP tunnel? Or set color 
extended community locally and steer over an SR Policy that uses best-effort. 
Or other such implementation-specific options via other forms of route-policy.

Please check inline below.

From: spring  On Behalf Of Shraddha Hegde
Sent: 20 July 2021 15:26
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.

"

[KT] We have an edit change in the buffer on this text that we will post it 
once the submission window opens over the weekend. How BGP resolves is 
implementation specific and a local policy. E.g. it could be via a backup 
static route as indicated above or via some other mechanisms mentioned above. 
Also note that the usage is a SHOULD to allow implementation-specific 
mechanisms.



"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."

[KT] Why should the fallback be only over best-effort locator? Why can't it be 
over another Flex-Algo, or some IP-IP tunnel or even perhaps an MPLS path. Why 
just this mechanism and that too is suggested to be mandated as a SHOULD? All 
these techniques and mechanisms would be implementation and more importantly 
deployment specific. Therefore, I do not agree with this text proposal.



Thanks,

Ketan





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 

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

[Ketan Talaulikar (ketant)]

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 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 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 mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>, 

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

[Robert Raszuk]

Jim,

The "policy" I had in mind was a simple cfg switch "fallback global" for
any SRv6 service originally set to say run over different IGP topology. Or
perhaps if more then two options are available, list the chain of
forwarding tables/topologies to be used as transport for a given SRv6
service.

Implementation may get even smarter and allow operator to set performance
based triggers to select such forwarding topologies from a flat pool.

If Shraddha has the same in mind not sure there is much to elaborate on
here :)

Best,
R.

On Tue, Jul 20, 2021 at 12:20 PM UTTARO, JAMES  wrote:

> *Comments In-Line..*
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *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.   *
>
> *[Jim U>] It would be helpful to provide an example of local policies and how 
> would/should said local policies be applied across a heterogeneous network.*
>
> *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 
> *Sent:* Tuesday, July 20, 2021 12:04 PM
> *To:* Shraddha Hegde 
> *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 
> 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 
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde 
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> bruno.decra...@orange.com; spr...@ietf.org; b...@ans.net; Srihari Sangli <
> 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 optimal service wise as using
> flex-algo, but this is form of tunneling. Hence I don't think your comment
> applies.
>
>
>
> Note that operator may also choose to use IP tunneling for best effort
> forwarding if SR best effort forwarding is not supported or enabled.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
> wrote:
>
> Hi Authors,
>
>
>
> There is a possibility of a usecase that wants to use flex-algo paths if
> 

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

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

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.

[Jim U>] It would be helpful to provide an example of local policies and how 
would/should said local policies be applied across a heterogeneous network.

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 optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

Note that operator may also choose to use IP tunneling for best effort 
forwarding if SR best effort forwarding is not supported or enabled.

Best,
R.




On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Authors,

There is a possibility of a usecase that wants to use flex-algo paths if 
available and if flex-algo paths
Are not available use best effort paths.


"When providing best-effort 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.
"

The current text says for best effort 

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

[Shraddha Hegde]

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 
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde 
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 optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

Note that operator may also choose to use IP tunneling for best effort 
forwarding if SR best effort forwarding is not supported or enabled.

Best,
R.




On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Authors,

There is a possibility of a usecase that wants to use flex-algo paths if 
available and if flex-algo paths
Are not available use best effort paths.


"When providing best-effort 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.
"

The current text says for best effort tunnels Srv6 service SID resolution 
SHOULD be checked and
I am told that (from previous mailing list exchanges) authors intend to update 
the text to make it applicable for flex-algo connectivity  as well.

It is not possible to support fallback on best effort tunnels if flex-algo SRv6 
service SIDs have to be resolved.
It is possible to support fallback to best effort in SRv6 if packets can be 
tunneled to egress PE  (destination address being PE's best effort END SID and 
service SID in the SRH)and
then do a service SID lookup 

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

[Robert Raszuk]

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  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 
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde 
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> bruno.decra...@orange.com; spr...@ietf.org; b...@ans.net; Srihari Sangli <
> 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 optimal service wise as using
> flex-algo, but this is form of tunneling. Hence I don't think your comment
> applies.
>
>
>
> Note that operator may also choose to use IP tunneling for best effort
> forwarding if SR best effort forwarding is not supported or enabled.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
> wrote:
>
> Hi Authors,
>
>
>
> There is a possibility of a usecase that wants to use flex-algo paths if
> available and if flex-algo paths
>
> Are not available use best effort paths.
>
>
>
> “When providing best-effort 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.
>
> “
>
>
>
> The current text says for best effort tunnels Srv6 service SID resolution
> SHOULD be checked and
>
> I am told that (from previous mailing list exchanges) authors intend to
> update the text to make it applicable for flex-algo connectivity  as well.
>
>
>
> It is not possible to support fallback on best effort tunnels if flex-algo
> SRv6 service SIDs have to be resolved.
>
> It is possible to support fallback to best effort in SRv6 if packets can
> be tunneled to egress PE  (destination address being PE’s best effort END
> SID and service SID in the SRH)and
>
> then do a service SID lookup on egress, in which case there is no need to
> resolve the SRv6 service SIDs on the ingress.
>
>
>
> It is not clear whether the authors intend to support these kind of
> tunnelling to egress cases for
>
> Best effort and flex-algo transport. If it not going to be supported, pls
> add text indicating clearly
>
> Tunnelling is not required to be supported and hence Fallback to best
> effort  is also not supported.
>
>
>
> If that is not the intention, Its reasonable to update the text to
> indicate SRv6 service SIDs need not be resolved
>
> If the ingress is tunneling the packet.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Aissaoui,
> Mustapha (Nokia - CA/Ottawa)
> *Sent:* Monday, July 19, 2021 7:34 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> rob...@raszuk.net; bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli ;
> bess@ietf.org; Shraddha Hegde 
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Rajesh,
>
> Also you can change the service SID for a subset of prefixes using a
> policy, to apply a flex-algo for example, but you do not want to change the
> next-hop for each new service SID.
>
>
>
> Mustapha.
>
>
>
> *From:* spring  *On Behalf Of *Rabadan, Jorge
> (Nokia - US/Mountain View)
> *Sent:* Monday, July 19, 2021 9:47 AM
> *To:* Rajesh M ; Rajesh M <
> mrajesh=40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) <
> ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <
> cfils...@cisco.com>; rob...@raszuk.net; 

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

[Aissaoui, Mustapha (Nokia - CA/Ottawa)]

Rajesh,
Also you can change the service SID for a subset of prefixes using a policy, to 
apply a flex-algo for example, but you do not want to change the next-hop for 
each new service SID.

Mustapha.

From: spring  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, July 19, 2021 9:47 AM
To: Rajesh M ; Rajesh M 
; Ketan Talaulikar (ketant) 
; 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,

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 mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>, 
gdawra.i...@gmail.com 
mailto:gdawra.i...@gmail.com>>, Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>, 
rob...@raszuk.net 
mailto:rob...@raszuk.net>>, 
bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>, Rabadan, Jorge 
(Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Cc: spr...@ietf.org 
mailto:spr...@ietf.org>>, b...@ans.net 
mailto:b...@ans.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Srihari Sangli mailto:ssan...@juniper.net>>
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: 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; 
jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Gaurav Dawra]

+1 on Jorge and Robert. I don’t think we should mandate.

Gaurav

> On Jul 19, 2021, at 6:52 AM, Robert Raszuk  wrote:
> 
> 
> I agree with Jorge.. 
> 
> In fact I find the tone of the comment to be very inappropriate: 
> 
> > In case of best effort/flex algo we must mandate user to set corresponding 
> > locator as BGP nexthop for srv6 routes.
> 
> No we MUST not mandate anything to the user. 
> 
> We MUST provide flexibility to address all deployment cases user may have. 
> 
> Best,
> R.
> 
> 
> 
>> On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) 
>>  wrote:
>> 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 
>> Date: Monday, July 19, 2021 at 3:24 PM
>> To: Rajesh M , Ketan Talaulikar 
>> (ketant) , gdawra.i...@gmail.com , 
>> Clarence Filsfils (cfilsfil) , rob...@raszuk.net 
>> , bruno.decra...@orange.com , 
>> Rabadan, Jorge (Nokia - US/Mountain View) 
>> 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 Authors,
>> 
>>  
>> 
>> Please respond.
>> 
>>  
>> 
>> Thanks
>> 
>> Rajesh
>> 
>>  
>> 
>>  
>> 
>> Juniper Business Use Only
>> From: spring  On Behalf Of Rajesh M
>> Sent: Thursday, July 15, 2021 4:36 PM
>> To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
>> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
>> bruno.decra...@orange.com; jorge.raba...@nokia.com
>> Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
>> bess@ietf.org
>> 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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rajesh M]

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) 
Sent: Monday, July 19, 2021 7:17 PM
To: Rajesh M ; Rajesh M 
; 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)

[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 mailto:mraj...@juniper.net>>
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M 
mailto:mrajesh=40juniper@dmarc.ietf.org>>,
 Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>, 
gdawra.i...@gmail.com 
mailto:gdawra.i...@gmail.com>>, Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>, 
rob...@raszuk.net 
mailto:rob...@raszuk.net>>, 
bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>, Rabadan, Jorge 
(Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Cc: spr...@ietf.org 
mailto:spr...@ietf.org>>, b...@ans.net 
mailto:b...@ans.net>>, Shraddha Hegde 
mailto:shrad...@juniper.net>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Srihari Sangli mailto:ssan...@juniper.net>>
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: 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; 
jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Robert Raszuk]

I agree with Jorge..

In fact I find the tone of the comment to be very inappropriate:

*> In case of best effort/flex algo we must mandate user to set
corresponding locator as BGP nexthop for srv6 routes.*

*No we MUST not mandate anything to the user. *

*We MUST provide flexibility to address all deployment cases user may
have. *

*Best,*
*R.*



On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> 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 
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M , Ketan Talaulikar
> (ketant) , gdawra.i...@gmail.com ,
> Clarence Filsfils (cfilsfil) , rob...@raszuk.net <
> rob...@raszuk.net>, bruno.decra...@orange.com ,
> Rabadan, Jorge (Nokia - US/Mountain View) 
> *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 Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com;
> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com; jorge.raba...@nokia.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org
> *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
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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 
Date: Monday, July 19, 2021 at 3:24 PM
To: Rajesh M , Ketan Talaulikar (ketant) 
, gdawra.i...@gmail.com , Clarence 
Filsfils (cfilsfil) , rob...@raszuk.net 
, bruno.decra...@orange.com , 
Rabadan, Jorge (Nokia - US/Mountain View) 
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 Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring  On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
bruno.decra...@orange.com; jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rajesh M]

Hi Authors,

Please respond.

Thanks
Rajesh



Juniper Business Use Only
From: spring  On Behalf Of Rajesh M
Sent: Thursday, July 15, 2021 4:36 PM
To: Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com; 
Clarence Filsfils (cfilsfil) ; rob...@raszuk.net; 
bruno.decra...@orange.com; jorge.raba...@nokia.com
Cc: spr...@ietf.org; b...@ans.net; Shraddha Hegde ; 
bess@ietf.org
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rajesh M]

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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess