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<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto: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<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto: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<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto: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<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>
Subject: RE: SRv6

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<mailto:bess@ietf.org>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 spr...@ietf.org<mailto: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<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto: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<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto: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<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>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net&l

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<mailto:spr...@ietf.org>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto: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<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>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net<mailto:b...@ans.net>; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto: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<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>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net<mailto:b...@ans.net>; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [spr

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<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>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net<mailto:b...@ans.net>; 
Srihari Sangli mailto:ssan...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
bess@ietf.org<mailto: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<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>
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)

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<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>
Cc: spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net<mailto:b...@ans.net>; 
Shr

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

[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>"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org<mailto:spr...@ietf.org>" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org<mailto: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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMOUxwCSPQ$>
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMMv4_vtIA$>

Thanks,
Ketan

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<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)

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>"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org<mailto:spr...@ietf.org>" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org<mailto:bess@iet

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

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

Thanks,
Ketan

From: Salih K A 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<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)

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>"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org<mailto:spr...@ietf.org>" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org<mailto: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<mailto:gdawra.i...@gmail.com>; Clarence Filsfils 
(cfilsfil) mailt

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

[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>"
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 "spr...@ietf.org<mailto:spr...@ietf.org>" 
mailto:spr...@ietf.org>>, 
"bess@ietf.org<mailto: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<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>
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 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<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>
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)

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:mr

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<mailto:spr...@ietf.org>; bess@ietf.org<mailto: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 

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<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>
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)

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<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>
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)

[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<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>
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)

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

T

Re: [bess] SRv6 / (SR)MPLS co-existence for bess

[Ketan Talaulikar (ketant)]

Hi Eduard,

I do believe that BGP ADD-PATH mechanism can be leveraged for co-existence. 
There are also other design approaches to achieve the same.

I am copying the authors of 
https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/ 
who were working to document these approaches.

Thanks,
Ketan

From: BESS  On Behalf Of Eduard Metz
Sent: 17 May 2021 13:46
To: bess@ietf.org
Subject: [bess] SRv6 / (SR)MPLS co-existence for bess

Hello,

Co-existence of multiple dataplane technologies to carry BESS services is 
useful for among others migration of one dataplane technology to another (e.g. 
(SR)MPLS to SRv6).

Can co-existence be achieved without changing current specifications, or would 
it require extensions / changes? For example as proposed in 
draft-ls-bess-srv6-mpls-coexisting-vpn.

I was thinking maybe the BGP ADD-PATH capability could be leveraged to achieve 
co-existence.

Would it be of interest to document co-existence cases and solutions?

Thanks!

cheers,
  Eduard
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your quick and detailed response. Please check inline below.

From: Gyan Mishra 
Sent: 17 April 2021 12:10
To: Ketan Talaulikar (ketant) 
Cc: Bocci, Matthew (Nokia - GB) ; bess@ietf.org; 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hi Ketan

Thanks you for your feedback on the draft.

Most of your comments have been mentioned on the ML are being addressed in the 
next draft update.

Responses in-line

Many Thanks!!

Gyan

On Sat, Apr 17, 2021 at 12:21 AM Ketan Talaulikar (ketant) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hello Authors,

A few comments/observations on this draft:


1. The BCP categorization does not seem right for this document and perhaps 
informational is better. Is this really something that has already seen 
widespread deployment such that the IETF community can say that it is the best 
“current” practice?

   Gyan> This draft addresses a real issue that has been discussed at NANOG and 
other operator groups around the world related to IXP major peering points 
where 1000s have IPv4 & IPv6 dual stacked peering exist and IPv4 address 
depletion have been a major issue issue for many years now.

Operators around the world are clamoring for a solution that can help with 
worldwide address IPv4 depletion issues at the IXP peering points.  With this 
solution IXPs as well as all infrastructure Core, DC PE-CE public or private 
can now utilize this solution and reap the benefits immediately on address 
space saving.  This can be used for IPv4 core or IPv6 core and I will clarify 
in the draft.  All infrastructure peering with this draft along with RFC 5565 
now becomes officially IPv6-Only.
[KT] I am not questioning the need for a design to address this problem space. 
It is real and relevant – something that the WG should take up. So thanks to 
the authors for bringing this up. Just emphasising it, in case anyone got a 
different impression from my initial response.

With this draft as it stands today as a BCP, the POC QA testing from the 5 
major vendors that make up almost 90%+ of the router and switch market share 
Cisco, Juniper, Arista, Nokia, Huawei, the idea is that all other vendors will 
follow suit and adopt this BCP and implement and support this solution to help 
with IPv4 address depletion issues faced by their customers.  We not trying to 
be not inclusive of all vendors, as it’s impossible to test every vendor.  With 
this  draft being a BCP, as strategy, we would now once this draft is published 
as a best practice be able create an industry shift momentum that now all 
operators all around the world including Verizon as well as other tier 1 
carriers as well as Tier 2 and 3 and all ISPs can use this solution immediately 
and start deployment once this draft becomes an RFC.  This will also help with 
the underlying goal of worldwide IPv6 proliferation.
[KT] This is my concern exactly and I think we perhaps differ on the definition 
of BCP. As also, differ on the use of IETF stream RFC as the means for 
publication of interop test results. I will suggest to the authors as well as 
the WG to consider using such a document for capturing the design as 
informational. More specifically, I will recommend somewhat on similar lines as 
RFC7938 or even draft-ietf-mpls-seamless-mpls (even though the later didn’t get 
to RFC). That, IMHO, would be valuable for everyone in the community (including 
vendors and operators).
2. do not think that the term “legacy” is appropriate for IPv4 and IPv4 based 
services.
Gyan> Understood. I can remove the word legacy

3. RFC5565 specifies the dual-stack PEs and IPv6-only P routers for delivering 
IPv4-based BGP services between the PEs via various mechanisms. This proposal 
brings that notion to the PE-CE link. The CE is dual-stack and the PE is 
IPv6-only. However, it is not describing how the forwarding plane works between 
PE and CE – an explanation or reference is required and without that clarity I 
am unable to understand how to actually deploy this.
Gyan> The next update will have a section that talks about IPv4 forwarding 
plane processing without an IPv4 address.  Both the PE and CE will not have an 
IPv4 address, but will be able to process and forward IPv4 packets.  The 
concept is very similar to the cisco “IPv6 enable” command where you don’t need 
an IPv6 address configured on the interface for IPv6 processing and forwarding. 
 Juniper and Nokia have tested and confirmed they have a CLI command for IPv4 
forwarding without an IPv6 address.  We are investigating a similar IPv4 
forwarding option with the other vendors including Cisco.  This is part of 
implementation space and each vendor will have their own existing knob if one 
exist or create a new knob for IPv4 forwarding without an IPv4 address.  The 
PE-CE IPv4 forwarding without an IPv4 address configured with all

Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Ketan Talaulikar (ketant)]

Hello Authors,

A few comments/observations on this draft:


  1.  The BCP categorization does not seem right for this document and perhaps 
informational is better. Is this really something that has already seen 
widespread deployment such that the IETF community can say that it is the best 
“current” practice?
  2.  I do not think that the term “legacy” is appropriate for IPv4 and IPv4 
based services.
  3.  RFC5565 specifies the dual-stack PEs and IPv6-only P routers for 
delivering IPv4-based BGP services between the PEs via various mechanisms. This 
proposal brings that notion to the PE-CE link. The CE is dual-stack and the PE 
is IPv6-only. However, it is not describing how the forwarding plane works 
between PE and CE – an explanation or reference is required and without that 
clarity I am unable to understand how to actually deploy this.
  4.  The document touches on IXP deployments, but again does not actually 
cover how the forwarding works nor provides references for how this proposal 
works for that deployment.
  5.  Is section 4 really required? Wouldn’t a simple reference to RFC8950 
suffice? The BGP signalling part for IPv4 over a single IPv6 peering and over 
IPv6 NH is already specified and covered in various Standards Track document 
(esp RFC8950) – so using their references rather than repeating them would be 
better.
  6.  If/when this gets published as an RFC, is the goal of this document to 
describe interop test results between specific vendors, OR is it do document 
the design, its operational considerations, and how it can be realized? E.g. 
RFC7938 – does something of that sorts. I do not think that IETF RFCs are good 
for documenting interop and it is better done via other “live” documents since 
these aspects change over course of time. It might even give an exclusionary 
impression for vendors not included in this document or those who might add 
this capability down the line. I’ve generally seen implementation status 
sections being taken out of Standards Track documents before publishing as RFC.
  7.  I would request the authors to explicitly clarify the Objective/Purpose 
of this draft in more precise and crisp manner in a section of its own so the 
WG knows what it is taking up. It might also help repeating the same throughout 
the document.
  8.  Finally, there is some language as follows in Sec 3 which perhaps needs 
to be revisiting?

   The test results published from this document provide concrete
   evidence that this is now the Best Practice for Edge peering.  The
   document will be the de-facto standard for operators to now use a
   single PE-CE Edge IPv6 peer to carry both IPv4 and IPv6 NLRI.

Would also request the WG and chairs to share their views on some of the above 
points – (1), (2), (6) and (7). Clarity on these points is, IMHO, important and 
necessary before the WG considers adoption of this document.

Thanks,
Ketan

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 13 April 2021 15:07
To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org; bess@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

This email begins a two-weeks WG adoption poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on April 27th 2021.

Regards,
Matthew and Stephane


[1] 
https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Document shepherd review of draft-ietf-bess-srv6-services-06

[Ketan Talaulikar (ketant)]

Hi Matthew,

Thanks for your review and your comments/feedback. We’ve just posted an update 
to the draft to address your comments.


https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-07

We’ve also adding clarification text related to the transposition scheme in 
this version in response to the discussion on the list : 
https://mailarchive.ietf.org/arch/msg/spring/PgmzeCB7APmfv8sizbGDs6ZqcrY/

Thanks,
Ketan

From: Bocci, Matthew (Nokia - GB) 
Sent: 01 April 2021 16:15
To: draft-ietf-bess-srv6-servi...@ietf.org
Cc: bess@ietf.org
Subject: Document shepherd review of draft-ietf-bess-srv6-services-06

Authors,

I am the document shepherd for this draft. As is customary, I have reviewed the 
document and have some comments below.

Please treat these as you would any other working group last call comments.

In general, the draft is clear and well written – thank you.

I have a few minor comments as follows.


  *   Terminology. The document is missing a terminology section. The 
introduction does define some terms e.g. SRv6 based BGP services, SRv6 SID, 
SRv6 Service SID, etc, and I think it would make sense to split these out into 
a terminology section.
  *   There are numerous cases where the definite article (‘a’, ‘the’ etc) is 
missing. Please go through the document carefully and insert as needed.
  *   Introduction: “SRv6 Service SID refers to an SRv6 SID associated with one 
of the service specific behaviors…” I think you mean ‘endpoint behaviors’ per 
RFC8986.
  *   Please expand all acronyms on first use, particularly ones specififc to 
SRv6 e.g. ‘SRH’.

If you can fix these, then I will proceed with the publication process.

Thanks

Matthew
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Document shepherd review of draft-ietf-bess-srv6-services-06

[Ketan Talaulikar (ketant)]

Hi Matthew,

Thanks for your review and your comments. We’ll work on addressing them and 
posting the draft update.

Thanks,
Ketan (on behalf of co-authors)

From: Bocci, Matthew (Nokia - GB) 
Sent: 01 April 2021 16:15
To: draft-ietf-bess-srv6-servi...@ietf.org
Cc: bess@ietf.org
Subject: Document shepherd review of draft-ietf-bess-srv6-services-06

Authors,

I am the document shepherd for this draft. As is customary, I have reviewed the 
document and have some comments below.

Please treat these as you would any other working group last call comments.

In general, the draft is clear and well written – thank you.

I have a few minor comments as follows.


  *   Terminology. The document is missing a terminology section. The 
introduction does define some terms e.g. SRv6 based BGP services, SRv6 SID, 
SRv6 Service SID, etc, and I think it would make sense to split these out into 
a terminology section.
  *   There are numerous cases where the definite article (‘a’, ‘the’ etc) is 
missing. Please go through the document carefully and insert as needed.
  *   Introduction: “SRv6 Service SID refers to an SRv6 SID associated with one 
of the service specific behaviors…” I think you mean ‘endpoint behaviors’ per 
RFC8986.
  *   Please expand all acronyms on first use, particularly ones specififc to 
SRv6 e.g. ‘SRH’.

If you can fix these, then I will proceed with the publication process.

Thanks

Matthew
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RTG-DIR review of draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Sasha,

Indeed your version is better and we’ll put that in on the next draft update.

Thanks,
Ketan

From: Alexander Vainshtein 
Sent: 10 March 2021 19:40
To: Ketan Talaulikar (ketant) 
Cc: draft-ietf-bess-srv6-services@ietf.org; bess@ietf.org; spr...@ietf.org; 
Swadesh Agrawal (swaagraw) ; Zafar Ali (zali) 
; rtg-...@ietf.org;  
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Ketan,
From my POV an even better version would be “Usage of multicast trees as 
P-tunnels is outside the scope of this document”.
But your proposed text is also OK with me.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, March 10, 2021 4:07 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
mailto:rtg-...@ietf.org>> 
mailto:rtg-...@ietf.org>>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

NOTICE: This email was received from an EXTERNAL sender.

Hi Sasha,

My apologies and I think I understand your point. Would the following text 
change convey the right meaning?

s/ The setup of multicast trees for use as P-tunnels is outside the scope of 
this document / The setup and usage of multicast trees as P-tunnels is outside 
the scope of this document

Thanks,
Ketan

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: 10 March 2021 16:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
mailto:rtg-...@ietf.org>> 
mailto:rtg-...@ietf.org>>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Ketan,
Lots of thanks for posting an updated version of the draft.

I have looked it up, and it seems that the majority of my review comments have 
been addressed.

I defer to the Routing ADs regarding my metadata comments.

One point that, IMHO, requires additional clarification, is restriction of EVPN 
to just ingress replication for delivery of BUM traffic.
As I see it, stating that “The setup of multicast trees for use as P-tunnels is 
outside the scope of this document”   does not fully address this issue 
because, to the best of my understanding, RFC 8986 does not define any endpoint 
behavior that could be used for delivery of EVPN BUM traffic via P2MP trees 
even if such were supported (seems pretty evident if aggregate multicast trees 
are used, but even non-aggregate multicast trees are not covered IMHO).

Please see also more comments to your responses inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, March 10, 2021 7:55 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
mailto:rtg-...@ietf.org>> 
mailto:rtg-...@ietf.org>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

NOTICE: This email was received from an EXTERNAL sender.

Hi Sasha,

Thanks a lot for your detailed review, your comments/feedback and for taking 
time for discussions with the co-authors for their resolution.

We’ve just posted an update of the draft to address your comments based on our 
discussions :


https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06<https://clicktime.symantec.com/3UsxW3phCpdUtwJLUsoiuXP6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-06>

Please see inline below for individual responses.

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: 29 January 2021 16:20
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:b

Re: [bess] RTG-DIR review of draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Sasha,

My apologies and I think I understand your point. Would the following text 
change convey the right meaning?

s/ The setup of multicast trees for use as P-tunnels is outside the scope of 
this document / The setup and usage of multicast trees as P-tunnels is outside 
the scope of this document

Thanks,
Ketan

From: Alexander Vainshtein 
Sent: 10 March 2021 16:15
To: Ketan Talaulikar (ketant) 
Cc: draft-ietf-bess-srv6-services@ietf.org; bess@ietf.org; spr...@ietf.org; 
Swadesh Agrawal (swaagraw) ; Zafar Ali (zali) 
; rtg-...@ietf.org;  
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Ketan,
Lots of thanks for posting an updated version of the draft.

I have looked it up, and it seems that the majority of my review comments have 
been addressed.

I defer to the Routing ADs regarding my metadata comments.

One point that, IMHO, requires additional clarification, is restriction of EVPN 
to just ingress replication for delivery of BUM traffic.
As I see it, stating that “The setup of multicast trees for use as P-tunnels is 
outside the scope of this document”   does not fully address this issue 
because, to the best of my understanding, RFC 8986 does not define any endpoint 
behavior that could be used for delivery of EVPN BUM traffic via P2MP trees 
even if such were supported (seems pretty evident if aggregate multicast trees 
are used, but even non-aggregate multicast trees are not covered IMHO).

Please see also more comments to your responses inline below.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, March 10, 2021 7:55 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
mailto:rtg-...@ietf.org>> 
mailto:rtg-...@ietf.org>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

NOTICE: This email was received from an EXTERNAL sender.

Hi Sasha,

Thanks a lot for your detailed review, your comments/feedback and for taking 
time for discussions with the co-authors for their resolution.

We’ve just posted an update of the draft to address your comments based on our 
discussions :


https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06<https://clicktime.symantec.com/3UsxW3phCpdUtwJLUsoiuXP6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-06>

Please see inline below for individual responses.

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: 29 January 2021 16:20
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Adding RTG-DIR – my apologies

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Cc: 
draft-ietf-bess-srv6-services@ietf.org<mailto:draft-ietf-bess-srv6-services@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>
Subject: RTG-DIR review of draft-ietf-bess-srv6-services-05

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://clicktime.symantec.com/3DNHqu2P3uB4FTvdUETxnRQ6H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir>

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-i

Re: [bess] RTG-DIR review of draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Sasha,

Thanks a lot for your detailed review, your comments/feedback and for taking 
time for discussions with the co-authors for their resolution.

We’ve just posted an update of the draft to address your comments based on our 
discussions :


https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06

Please see inline below for individual responses.

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: 29 January 2021 16:20
To: rtg-...@ietf.org
Cc: 
draft-ietf-bess-srv6-services@ietf.org;
 bess@ietf.org; spr...@ietf.org; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>; 
rtg-...@ietf.org
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Adding RTG-DIR – my apologies

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: rtg-...@ietf.org
Cc: 
draft-ietf-bess-srv6-services@ietf.org;
 bess@ietf.org; spr...@ietf.org; 
Swadesh Agrawal (swaagraw) mailto:swaag...@cisco.com>>; 
Zafar Ali (zali) mailto:z...@cisco.com>>
Subject: RTG-DIR review of draft-ietf-bess-srv6-services-05

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-bess-srv6-services-05
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 29-Jan-21
IETF LC End Date:  Not known
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved 
before publication.

Comments:
The draft is well written and it was relatively easy to grasp the main idea 
behind it. However, the draft has to be read in parallel with the SRv6 Network 
Programming 
draft
 due to a lot of references to specific SRv6 endpoint behaviors defined in this 
draft.

From my POV the draft introduces a new approach to providing BGP-based services 
over an IPv6-capable core that is quite different from the way such services 
have been provided over IP/MPLS cores .  It would be nice  if the authors could 
 present these differences in a more explicit way and clarify their impact on 
such issues as inter-AS/inter-domain services, scalability etc. However this is 
just a wish, not a concern.

I have presented my early comments to the authors and contributors to the 
draft, and we have hold a series of productive  discussions that, from my POV, 
resulted in reaching rough consensus regarding resolution of all the issues I 
have raised.

I have included my understanding of the authors’ responses in the body of the 
review (marked by italics), and will be waiting for the next revision of the 
draft for addressing these comments along the agreed upon lines.

I would like express my gratitude to Gaurav, Swadesh and Zafar  for their 
responsiveness and cooperation.

Major Issues: None found

Minor Issues:

  1.  It is quite common to say that the SRv6 dataplane is defined by RFC 8754m 
and this common statement is repeated in the first line of the SRv6 Services 
draft. However. I am not sure whether  RFC 8754, by and of itself,  is a 
sufficient reference for the SRv6 dataplane  for the purpose of this  document. 
My doubts are based on the following:
 *   RFC 8754 defines the Segment Routing header (SRH) and its handling
 *   The draft explicitly states that best-effort BGP-based services over 
an SRv6 domain can be provided without SRH – but they definitely would use the 
SRv6 dataplane
[KT] RFC8754 does indeed define the SRH and hence specifies the SRv6 data plane 
in conjunction with RFC8402. Even when SRH is not used (refer RFC 8754 Sec 
4.1.1 and RFC 8986 Sec 5.1 & 5.2), the processing follows RFC 8754 and RFC 8986 
since the IPv6 DA in the packet is set to the specific SRv6 SID. Hence, the 
references to these two specifications in addition to RFC8402.

My guess is that the  primary reference for the SRv6 dataplane for this draft 
is provided by the SRv6 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Aijun,

Did you actually mean to say that the title should be "SRv6-based BGP Overlay 
Services"? If so, I agree.

Thanks,
Ketan

From: BESS  On Behalf Of Aijun Wang
Sent: 09 December 2020 08:43
To: 'Bocci, Matthew (Nokia - GB)' ; 
draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi, All:

Support its publication.

One comments for the document:
Should the name of document be changed to "BGP based SRv6 overlay services" to 
reflect its actual scope?
This document discusses just the distribution of SRv6 service label 
distribution via BGP.  As also stated in the document, it also applies in the 
plain IPv6 forwarding environment.


Best Regards

Aijun Wang
China Telecom


From: bess-boun...@ietf.org 
mailto:bess-boun...@ietf.org>> On Behalf Of Bocci, 
Matthew (Nokia - GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: 
draft-ietf-bess-srv6-servi...@ietf.org;
 bess@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Haibo,

This is not a change but a clarification to avoid exactly those kind of issues.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
Sent: 03 December 2020 15:39
To: Ketan Talaulikar (ketant) ; Bocci, Matthew (Nokia - GB) 
; draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Ketan,

 Thanks for your reply.

RFC 8277 has clearly described that the label field is only 20 bits.

At the beginning, we consider it to use the 20-bits to do the transposition. 
But in some interconnection tests, some vendors are use the 24-bits to do the 
transposition.

So I’m worried about that the change may cause incompatible interop.

Regards，
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

Hi Haibo,

This clarification was explicitly added based on feedback that the authors 
received.

This document does not change the definition of the Label Field of RFC4364 and 
so it has always been 20 bits. There has been this text about 24-bit in other 
parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label 
was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, 
this was under-specified by RFC3107. There are implementations around that do 
not check/examine the BOS field and assume a single label. You can see some of 
this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible 
changes in the implemented version.
[cid:image001.png@01D6C98C.A575E620]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the 
prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

  b) Label:



 The Label field carries one or more labels (that corresponds to

 the stack of labels 
[MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).  Each 
label is encoded as 3

 octets, where the high-order 20 bits contain the label value,

 and the low order bit contains "Bottom of Stack" (as defined in

 [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  
but only 20 bits are used as the label value. So we may also use the entire 3 
octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to 
the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: 
draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew &a

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Haibo,

This clarification was explicitly added based on feedback that the authors 
received.

This document does not change the definition of the Label Field of RFC4364 and 
so it has always been 20 bits. There has been this text about 24-bit in other 
parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label 
was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, 
this was under-specified by RFC3107. There are implementations around that do 
not check/examine the BOS field and assume a single label. You can see some of 
this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) ; 
draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible 
changes in the implemented version.
[cid:image001.png@01D6C980.4EF05B20]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP], where the 
prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

  b) Label:



 The Label field carries one or more labels (that corresponds to

 the stack of labels 
[MPLS-ENCAPS]).  Each 
label is encoded as 3

 octets, where the high-order 20 bits contain the label value,

 and the low order bit contains "Bottom of Stack" (as defined in

 [MPLS-ENCAPS]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  
but only 20 bits are used as the label value. So we may also use the entire 3 
octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to 
the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: 
draft-ietf-bess-srv6-servi...@ietf.org;
 bess@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ketan Talaulikar (ketant)]

Hi Matthew/Stephane,

I support the publication of this draft as standards track RFC. As a co-author, 
I am not aware of any IPR other than the one that has already been disclosed on 
the draft.

I would also like to report Cisco having implementations of this draft for 
L3VPN (IPv4/IPv6), Internet v4/v6 and EVPN services. Some of these 
implementations are already shipping and deployed in production networks.

Some of these implementation and deployment details have been captured in 
https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/

Thanks,
Ketan

From: Bocci, Matthew (Nokia - GB) 
Sent: 30 November 2020 22:46
To: draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-15.txt

[Ketan Talaulikar (ketant)]

Thanks Adrian for incorporating these changes as per our off-list discussion.

Thanks,
Ketan

-Original Message-
From: BESS  On Behalf Of Adrian Farrel
Sent: 15 June 2020 18:54
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-15.txt

BESS,

This revision adopts the text and registry change as just discussed on list 
with Ketan.

Thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: 15 June 2020 13:05
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP Control Plane for the Network Service Header
in Service Function Chaining
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-15.txt
Pages   : 69
Date: 2020-06-15

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC Address Family
   Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
   two route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-15
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-15


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and Implementation Poll for draft-ietf-bess-rfc5549revision-00

[Ketan Talaulikar (ketant)]

Support.

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 06 January 2020 23:23
To: bess@ietf.org
Subject: [bess] WG Last Call and Implementation Poll for 
draft-ietf-bess-rfc5549revision-00

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-rfc5549revision-00.

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 20th January 2019.

We have only just completed an IPR poll on the draft prior to adoption in 
December 2019, so I will not run another one now.

There is currently no IPR disclosed.

We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations of the modified protocol described in 
this draft.

 Thank you,

Matthew

[1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Ketan Talaulikar (ketant)]

Support adoption of this document.

Thanks,
Ketan

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 27 November 2019 18:07
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Ketan Talaulikar (ketant)]

Also, not aware of any IPR related to the draft other than the one already 
disclosed.

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 01 October 2019 22:57
To: 'Bocci, Matthew (Nokia - GB)' ; 
draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: RE: [bess] WG adoption and IPR poll for 
draft-dawra-bess-srv6-services-02

Hello,

I support the adoption of this document. It covers Internet, L3VPN and EVPN 
services over SRv6 dataplane.

There are already implementations of this draft across multiple vendors as well 
as deployments at multiple operators.

Thanks,
Ketan

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Bocci, Matthew (Nokia - GB)
Sent: 27 September 2019 16:30
To: 
draft-dawra-bess-srv6-servi...@ietf.org<mailto:draft-dawra-bess-srv6-servi...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Ketan Talaulikar (ketant)]

Hello,

I support the adoption of this document. It covers Internet, L3VPN and EVPN 
services over SRv6 dataplane.

There are already implementations of this draft across multiple vendors as well 
as deployments at multiple operators.

Thanks,
Ketan

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 27 September 2019 16:30
To: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess