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

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

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

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

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

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

Regards,
Mustapha.

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

Mustapha,

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

srihari…


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

[External Email. Be cautious of content]

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

Regards,
Mustapha.

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



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



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

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

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

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



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





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

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

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

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

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

“

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

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

SHOULD be governed by local policies.

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

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

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

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

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

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

Regards,
Mustapha.

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

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

Mustapha,

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

srihari…


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

[External Email. Be cautious of content]

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

Regards,
Mustapha.

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



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



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

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

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

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



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





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

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

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

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

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

“

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

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

SHOULD be governed by local policies.

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

Thx,
R.



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

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

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

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

Rgds
Sh

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

[Srihari Sangli]

Mustapha,

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

srihari…


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

[External Email. Be cautious of content]

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

Regards,
Mustapha.

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



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



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

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

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

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



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





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

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

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

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

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

“

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

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

SHOULD be governed by local policies.

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

Thx,
R.



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

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

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

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

Rgds
Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

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

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

Regards,
Mustapha.

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



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



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

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

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

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



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





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

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

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

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

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

"

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

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

SHOULD be governed by local policies.

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

Thx,
R.



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

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

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

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

Rgds
Shraddha



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

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated 
forwarding using SR. It may not be as optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

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

Best,
R.




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

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


"When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination ad

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

[Robert Raszuk]

Jim,

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

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

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

Best,
R.

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

> *Comments In-Line..*
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* spring  *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, July 20, 2021 5:56 AM
> *To:* Robert Raszuk 
> *Cc:* spr...@ietf.org; bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
>
>
> Good to know the intention is to support fallback for Srv6.
>
>
>
> The way current text is written, it implies service SID is always in the 
> destination address.
>
> And hence service SID should be resolvable. This is not the case when a 
> service SID
>
> Corresponding to flex-algo wants to fallback on best effort services. The 
> destination address cannot carry
>
> Service SID for fallback cases and hence it need not be resolved.
>
>
>
> I suggest that the authors add below text in bold to the draft.
>
>
>
>
>
> “When providing best-effort connectivity *or flex-algo connectivity* to the 
> egress PE,
>
> the ingress PE encapsulates the payload in an outer IPv6 header where the 
> destination
>
> address is the SRv6 Service SID associated with the related BGP route update.
>
>  Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
> Service SID
>
>  before considering the received prefix for the BGP best path computation.
>
> “
>
> “*In some cases a service prefix intending to use flex-algo paths may want 
> fallback on*
>
> *best effort paths when a flex-algo path isn’t available. The fallback 
> behavior *
>
> *SHOULD be governed by local policies.   *
>
> *[Jim U>] It would be helpful to provide an example of local policies and how 
> would/should said local policies be applied across a heterogeneous network.*
>
> *The destination address SHOULD contain the best-effort locator based END SID 
> *
>
> *of the egress PE and the SRH SHOULD contain the service SID. Service SID *
>
> *resolvability SHOULD NOT be checked on the ingress for this case*.”
>
>
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, July 20, 2021 12:04 PM
> *To:* Shraddha Hegde 
> *Cc:* spr...@ietf.org; bess@ietf.org
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Shraddha,
>
>
>
> > that authors don’t intend to support any form of tunnelling for SRv6
>
> > because it is not optimal. Is that the right read?
>
>
>
> Quite the opposite. It is the local operator's choice (not the draft
> authors) to decide to fall back to best effort or to drop.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde 
> wrote:
>
> Robert,
>
>
>
> What do you mean by SR? is it SR-MPLS or SRv6.
>
> My question is about draft-ietf-bess-srv6-services and applies only to
> SRv6.
>
>
>
> Let me repeat the question.
>
> Do the authors intend to support the case of fallback from SRv6 flex-algo
> to SRv6 best effort transport for SRv6
>
> Services or not?
>
>
>
> From your vague answer it appears that authors don’t intend to support any
> form of tunnelling for SRv6
>
> because it is not optimal. Is that the right read?
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde 
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> bruno.decra...@orange.com; spr...@ietf.org; b...@ans.net; Srihari Sangli <
> ssan...@juniper.net>; bess@ietf.org
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Shraddha,
>
>
>
> In an SR network fallback to best effort will also result in encapsulated
> forwarding using SR. It may not be as optimal service wise as using
> flex-algo, but this is form of tunneling. Hence I don't think your comment
> applies.
>
>
>
> Note that operator may also choose to use IP tunneling for best effort
> forwarding if SR best effort forwarding is not supported or enabled.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
> wrote:
>
> Hi Authors,
>
>
>
> There is a possibility of a usecase that wants to use flex-algo paths if
> availab

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

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

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



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



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

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

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

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



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





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

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

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

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

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

"

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

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

SHOULD be governed by local policies.

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

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

Thx,
R.



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

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

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

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

Rgds
Shraddha



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

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated 
forwarding using SR. It may not be as optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

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

Best,
R.




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

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


"When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.
"

The current text says for best effort tu

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

[Shraddha Hegde]

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



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

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

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

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



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





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

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

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

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

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

"

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

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

SHOULD be governed by local policies.

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

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

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





Rgds

Shraddha



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

[External Email. Be cautious of content]

Shraddha,

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

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

Thx,
R.



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

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

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

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

Rgds
Shraddha



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

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated 
forwarding using SR. It may not be as optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

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

Best,
R.




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

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


"When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.
"

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

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