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