Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[Chengli (IP Technology Research)]

Hi all,

Yes,+1 to traffic steering and OAM.  As mentioned by Mach, Zafar and others,  
OAM is very important for SR to be deployed in a production network, and there 
are many works of OAM have been done. They should be added to Charter so that 
SR can be developed well since the fundamental SR mechanism is almost done for 
now.

I think operators will be happy to see SR can be deployed with rich OAM 
features in their  production networks.

Best regards
Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alex Bogdanov
Sent: Tuesday, March 20, 2018 2:37 AM
To: Dongjie (Jimmy) 
Cc: spring@ietf.org; spring-cha...@ietf.org; Shah, Himanshu ; 
bruno.decra...@orange.com; Bernier, Daniel ; Alvaro 
Retana (aretana) ; Jeff Tantsura ; 
Voyer, Daniel 
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

+1 to traffic steering  and OAM. I'd like to see operational statistics/traffic 
accounting get some much deserved attention(in the context of SRTE policies and 
other SR paths)

On Mon, Mar 19, 2018 at 7:23 AM Dongjie (Jimmy) 
> wrote:
Hi all,

I totally agree with Mach, Jeff and others that there is work to be done in OAM 
as there are more requirements to use SR for both existing and emerging 
applications.

SR-TE is another important area. The current SR-TE mainly focuses on steering 
traffic to particular SR paths, while TE can have a broader scope than that, 
for example, how to do resource partitioning (reservation) with SR needs to be 
discussed.  Actually this is already mentioned in the current charter:

o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs

I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu 
said, it could be beneficial to leverage the TE expertise from TEAS.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] 
On Behalf Of Voyer, Daniel
Sent: Monday, March 19, 2018 11:42 AM
To: Shah, Himanshu; Jeff Tantsura; Bernier, Daniel; 
bruno.decra...@orange.com; 
spring@ietf.org

Cc: Alvaro Retana (aretana); 
spring-cha...@ietf.org
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines

From: spring > on 
behalf of "Shah, Himanshu" >
Date: Sunday, March 18, 2018 at 9:23 PM
To: Jeff Tantsura >, 
Daniel Bernier >, Bruno 
Decraene >, 
"spring@ietf.org" 
>
Cc: "Alvaro Retana (aretana)" >, 
"spring-cha...@ietf.org" 
>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Agree with Jeff, without harping on all the good reasons already stated for 
SPRING WG charter extensions,
I would think that it would be beneficial to leverage TE expertise from TEAS WG 
to
progress SR-TE there for a cohesive, uniform solution for all tunneling schemes.

[DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. 
This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
[DV] 2- According to TEAS WG charter - 
https://datatracker.ietf.org/wg/teas/about/:
1. Definition of additional abstract service, link, and path
properties such as jitter, delay, and diversity. Extensions
to IGPs to advertise these properties, and extensions to
RSVP-TE to request and to accumulate these properties.

[DV] 3- also notice in the SPRING Charter - 
https://datatracker.ietf.org/wg/spring/about/:
o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering
[DV] Hence I believe “SRTE policy” is a key component of the SR Architecture 
and should pursued as part as the Architecture definition milestone of the 
SPRING WG.

Dan

IMHO...

Thanks,
Himanshu
From: spring > on 
behalf of Jeff Tantsura 
>
Date: Sunday, March 18, 2018 at 3:26 PM
To: "Bernier, Daniel" >, 
"bruno.decra...@orange.com" 

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[Zafar Ali (zali)]

Hi All,

I could not agree more with Dan.

As indicated by the text quoted by Dan from the Spring charter 
[https://datatracker.ietf.org/wg/spring/about/], SR Policy specification is not 
only part of the current Spring Charter; it is the basis of "source routing" 
and is the heart of the Spring WG. The SR architecture is incomplete without SR 
Policy specification in it. The work on SR Policies is part of the SR 
architecture deliverables and belongs to the Spring WG.

TEAS WG should review the work and provide comments. However, as shown by the 
text quoted by Dan [ https://datatracker.ietf.org/wg/teas/about/] SR policy 
specification is beyond the scope of TEAS WG.

Thanks

Regards … Zafar

From: spring  on behalf of "Voyer, Daniel" 

Date: Monday, March 19, 2018 at 11:42 AM
To: "Shah, Himanshu" , Jeff Tantsura 
, "Bernier, Daniel" , 
"bruno.decra...@orange.com" , "spring@ietf.org" 

Cc: "Alvaro Retana (aretana)" , "spring-cha...@ietf.org" 

Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines

From: spring  on behalf of "Shah, Himanshu" 

Date: Sunday, March 18, 2018 at 9:23 PM
To: Jeff Tantsura , Daniel Bernier 
, Bruno Decraene , 
"spring@ietf.org" 
Cc: "Alvaro Retana (aretana)" , "spring-cha...@ietf.org" 

Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Agree with Jeff, without harping on all the good reasons already stated for 
SPRING WG charter extensions,
I would think that it would be beneficial to leverage TE expertise from TEAS WG 
to
progress SR-TE there for a cohesive, uniform solution for all tunneling schemes.

[DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. 
This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
[DV] 2- According to TEAS WG charter - 
https://datatracker.ietf.org/wg/teas/about/:
1. Definition of additional abstract service, link, and path
properties such as jitter, delay, and diversity. Extensions
to IGPs to advertise these properties, and extensions to
RSVP-TE to request and to accumulate these properties.

[DV] 3- also notice in the SPRING Charter - 
https://datatracker.ietf.org/wg/spring/about/:
o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering
[DV] Hence I believe “SRTE policy” is a key component of the SR Architecture 
and should pursued as part as the Architecture definition milestone of the 
SPRING WG.

Dan

IMHO..

Thanks,
Himanshu
From: spring  on behalf of Jeff Tantsura 

Date: Sunday, March 18, 2018 at 3:26 PM
To: "Bernier, Daniel" , "bruno.decra...@orange.com" 
, "spring@ietf.org" 
Cc: Alvaro Retana , "spring-cha...@ietf.org" 

Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion

Hi,

I'm not going to repeat all the valid reasons to continue mentioned beforehand.
There's definitely work to be done in architecture and O areas as well as 
co-ordination of various activities across IETF.

Cheers,
Jeff
On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" 
 on behalf of 
daniel.bern...@bell.ca> wrote:

Hi,

I echo the need to continue the SPRING work on service-chaining. There is a 
growing interest to have a mechanism that operates at the forwarding plane 
level using source routing as an alternative to a dedicated service overlay. 
This will surely generate other related work such as automated service 
discovery, inter-domain chaining policies, parallelism versus sequential 
chaining, various control-plane implementations, etc.

Secondly, since there is a tight relation to SR chaining and TE policies, I 
believe there will is a lot of opportunities related to Path Awareness which is 
currently running in IRTF. Opportunities like, intent translation to SR 
policies, Policy requests or announcements between domains and host (probably 
app) level TE policy requests (e.g. how can an app receive a proper policy 
based on its requirements) ?

My humble operator 0.02 cents.

Daniel Bernier | Bell Canada

From: spring > 

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[Alex Bogdanov]

+1 to traffic steering  and OAM. I'd like to see operational
statistics/traffic accounting get some much deserved attention(in the
context of SRTE policies and other SR paths)


On Mon, Mar 19, 2018 at 7:23 AM Dongjie (Jimmy)  wrote:

> Hi all,
>
>
>
> I totally agree with Mach, Jeff and others that there is work to be done
> in OAM as there are more requirements to use SR for both existing and
> emerging applications.
>
>
>
> SR-TE is another important area. The current SR-TE mainly focuses on
> steering traffic to particular SR paths, while TE can have a broader scope
> than that, for example, how to do resource partitioning (reservation) with
> SR needs to be discussed.  Actually this is already mentioned in the
> current charter:
>
>
>
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network
> resources for VPNs
>
>
>
> I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu
> said, it could be beneficial to leverage the TE expertise from TEAS.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Monday, March 19, 2018 11:42 AM
> *To:* Shah, Himanshu; Jeff Tantsura; Bernier, Daniel;
> bruno.decra...@orange.com; spring@ietf.org
>
>
> *Cc:* Alvaro Retana (aretana); spring-cha...@ietf.org
>
> *Subject:* Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering
> discussion
>
>
>
> [DV] see inlines
>
>
>
> *From: *spring  on behalf of "Shah, Himanshu" <
> hs...@ciena.com>
> *Date: *Sunday, March 18, 2018 at 9:23 PM
> *To: *Jeff Tantsura , Daniel Bernier <
> daniel.bern...@bell.ca>, Bruno Decraene , "
> spring@ietf.org" 
> *Cc: *"Alvaro Retana (aretana)" , "
> spring-cha...@ietf.org" 
> *Subject: *Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering
> discussion
>
>
>
> Agree with Jeff, without harping on all the good reasons already stated
> for SPRING WG charter extensions,
>
> I would think that it would be beneficial to leverage TE expertise from
> TEAS WG to
>
> progress SR-TE there for a cohesive, uniform solution for all tunneling
> schemes.
>
>
>
> [DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as
> known. This is why the word “policy” was introduce with SRTE – “SRTE
> Policy”.
>
> [DV] 2- According to TEAS WG charter -
> https://datatracker.ietf.org/wg/teas/about/:
>
> 1. Definition of additional abstract service, link, and path
> properties such as jitter, delay, and diversity. Extensions
> to IGPs to advertise these properties, and
> *extensions to RSVP-TE *to request and to accumulate these properties.
>
>
>
> [DV] 3- also notice in the SPRING Charter -
> https://datatracker.ietf.org/wg/spring/about/:
>
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network
> resources for VPNs
> o Network path and node protection such as fast re-route
> o Network programmability
> o New OAM techniques
> o Simplification and reduction of network signalling
> components
> o Load balancing and *traffic engineering*
>
> [DV] Hence I believe “SRTE policy” is a key component of the SR
> Architecture and should pursued as part as the Architecture definition
> milestone of the SPRING WG.
>
>
>
> Dan
>
>
>
> IMHO..
>
>
>
> *Thanks,*
>
> *Himanshu*
>
> *From: *spring  on behalf of Jeff Tantsura <
> jefftant.i...@gmail.com>
> *Date: *Sunday, March 18, 2018 at 3:26 PM
> *To: *"Bernier, Daniel" , "
> bruno.decra...@orange.com" , "spring@ietf.org"
> 
> *Cc: *Alvaro Retana , "spring-cha...@ietf.org" <
> spring-cha...@ietf.org>
> *Subject: *[**EXTERNAL**] Re: [spring] SPRING - rechartering discussion
>
>
>
> Hi,
>
>
>
> I'm not going to repeat all the valid reasons to continue mentioned
> beforehand.
>
> There's definitely work to be done in architecture and O areas as well
> as co-ordination of various activities across IETF.
>
>
>
> Cheers,
>
> Jeff
>
> On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" <
> spring-boun...@ietf.org on behalf of daniel.bern...@bell.ca> wrote:
>
>
>
> Hi,
>
>
>
> I echo the need to continue the SPRING work on service-chaining. There
> is a growing interest to have a mechanism that operates at the forwarding
> plane level using source routing as an alternative to a dedicated service
> overlay. This will surely generate other related work such as automated
> service discovery, inter-domain chaining policies, parallelism versus
> sequential chaining, various control-plane implementations, etc.
>
>
>
> Secondly, since there is a tight relation to SR chaining and TE
> policies, I believe there will is a lot of opportunities related to Path
> Awareness which is currently running in IRTF. 

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

Hi,

I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially 
when the dataplane is involved. I would personally prefer to get the resources 
allocated to NSH rather than MPLS based SFCs.
This is not just a matter of operator preference, as if vendor#1 prioritizes 
MPLS SFC and vendor#2 prioritizes NSH, multiple operators may get stuck for a 
while when operating a multivendor network.

Whatever the encaps is, the operational team will have to ramp up on the SFC 
architecture and on the associated controlplane. The encaps/dataplane is a 
small part of the operational side.

I’m personally in favor to focus on NSH even if I’m an MPLS geek. We already 
have running SFCs that are based on bess-service-chaining as an interim 
solution.


Brgds,

Stephane


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 14:25
To: UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian 
Farrel
Cc: mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[mohamed.boucadair]

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say 

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[Dongjie (Jimmy)]

Hi all,

I totally agree with Mach, Jeff and others that there is work to be done in OAM 
as there are more requirements to use SR for both existing and emerging 
applications.

SR-TE is another important area. The current SR-TE mainly focuses on steering 
traffic to particular SR paths, while TE can have a broader scope than that, 
for example, how to do resource partitioning (reservation) with SR needs to be 
discussed.  Actually this is already mentioned in the current charter:

o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs

I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu 
said, it could be beneficial to leverage the TE expertise from TEAS.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Voyer, Daniel
Sent: Monday, March 19, 2018 11:42 AM
To: Shah, Himanshu; Jeff Tantsura; Bernier, Daniel; bruno.decra...@orange.com; 
spring@ietf.org
Cc: Alvaro Retana (aretana); spring-cha...@ietf.org
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines

From: spring > on 
behalf of "Shah, Himanshu" >
Date: Sunday, March 18, 2018 at 9:23 PM
To: Jeff Tantsura >, 
Daniel Bernier >, Bruno 
Decraene >, 
"spring@ietf.org" 
>
Cc: "Alvaro Retana (aretana)" >, 
"spring-cha...@ietf.org" 
>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Agree with Jeff, without harping on all the good reasons already stated for 
SPRING WG charter extensions,
I would think that it would be beneficial to leverage TE expertise from TEAS WG 
to
progress SR-TE there for a cohesive, uniform solution for all tunneling schemes.

[DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. 
This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
[DV] 2- According to TEAS WG charter - 
https://datatracker.ietf.org/wg/teas/about/:
1. Definition of additional abstract service, link, and path
properties such as jitter, delay, and diversity. Extensions
to IGPs to advertise these properties, and extensions to
RSVP-TE to request and to accumulate these properties.

[DV] 3- also notice in the SPRING Charter - 
https://datatracker.ietf.org/wg/spring/about/:
o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering
[DV] Hence I believe “SRTE policy” is a key component of the SR Architecture 
and should pursued as part as the Architecture definition milestone of the 
SPRING WG.

Dan

IMHO..

Thanks,
Himanshu
From: spring > on 
behalf of Jeff Tantsura 
>
Date: Sunday, March 18, 2018 at 3:26 PM
To: "Bernier, Daniel" >, 
"bruno.decra...@orange.com" 
>, 
"spring@ietf.org" 
>
Cc: Alvaro Retana >, 
"spring-cha...@ietf.org" 
>
Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion

Hi,

I'm not going to repeat all the valid reasons to continue mentioned beforehand.
There's definitely work to be done in architecture and O areas as well as 
co-ordination of various activities across IETF.

Cheers,
Jeff
On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" 
 on behalf of 
daniel.bern...@bell.ca> wrote:

Hi,

I echo the need to continue the SPRING work on service-chaining. There is a 
growing interest to have a mechanism that operates at the forwarding plane 
level using source routing as an alternative to a dedicated service overlay. 
This will surely generate other related work such as automated service 
discovery, inter-domain chaining policies, parallelism versus sequential 
chaining, various control-plane implementations, etc.

Secondly, since there is a tight relation to SR chaining and TE policies, I 
believe there will is a lot of opportunities related 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES ; Henderickx, Wim (Nokia - BE/Antwerp) 
; Robert Raszuk ; Adrian Farrel 

Cc: mpls ; SPRING WG List ; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[mohamed.boucadair]

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES ; Henderickx, Wim (Nokia - BE/Antwerp) 
; Robert Raszuk ; Adrian Farrel 

Cc: mpls ; SPRING WG List ; s...@ietf.org; 
b...@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; b...@ietf.org; 
s...@ietf.org
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: > on behalf of Robert Raszuk 
>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[mohamed.boucadair]

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; b...@ietf.org; 
s...@ietf.org
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: > on behalf of Robert Raszuk 
>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" 
>, mpls 
>, SPRING WG List 
>, 
"s...@ietf.org" >, 
"b...@ietf.org" >
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

> That proxy may be a bump in the wire between the SFF and SF

I am not so sure about that ... If this would be just "bump in the wire" you 
would have zero guarantees that all packets which need to go via given function 
will actually hit that bump - so this is far from a reliable network service.

There must be associated control plane component attracting traffic to such 
bump.

That mechanism with basic MPLS (where labels by based MPLS architecture are of 
local significance) is available with L3VPN extensions as already progressing 
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you 
state "interim" ?

No one really addressed that question 

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) ; Robert 
Raszuk ; Adrian Farrel 
Cc: mpls ; SPRING WG List ; s...@ietf.org; 
b...@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; b...@ietf.org; 
s...@ietf.org
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: > on behalf of Robert Raszuk 
>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" 
>, mpls 
>, SPRING WG List 
>, 
"s...@ietf.org" >, 
"b...@ietf.org" >
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

> That proxy may be a bump in the wire between the SFF and SF

I am not so sure about that ... If this would be just "bump in the wire" you 
would have zero guarantees that all packets which need to go via given function 
will actually hit that bump - so this is far from a reliable network service.

There must be associated control plane component attracting traffic to such 
bump.

That mechanism with basic MPLS (where labels by based MPLS architecture are of 
local significance) is available with L3VPN extensions as already progressing 
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you 
state "interim" ?

No one really addressed that question yet and I think it is a critical one to 
make any further judgement  as to the future of this individual submission.

Cheers,
R.



On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel 
> wrote:
Hi Wim,

Thanks for reading the draft so carefully.

> Adrian, on replacement of NSH. You will have to change the SF with this 
> proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which 
> SF(s)
> support MPLS?

This is not about "replacing" the NSH. As you'll see from point 2, below, this 
is about providing an interim / migration technology.

Clearly (and I think you agree) in the case where an SF is not SFC-aware, a 
proxy must be used. That proxy may be a bump in the wire between the SFF and 
SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the 
first two options are available. In the case of a VNF, all three options exist.

Now, let us recall where we are starting from. There are PNFs and there are 
VNFs built to look like PNFs. These SFs do not support MPLS or NSH.

Similarly, there are routers that do not support the NSH.

Now, of course, we 

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[Voyer, Daniel]

[DV] see inlines

From: spring  on behalf of "Shah, Himanshu" 

Date: Sunday, March 18, 2018 at 9:23 PM
To: Jeff Tantsura , Daniel Bernier 
, Bruno Decraene , 
"spring@ietf.org" 
Cc: "Alvaro Retana (aretana)" , "spring-cha...@ietf.org" 

Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Agree with Jeff, without harping on all the good reasons already stated for 
SPRING WG charter extensions,
I would think that it would be beneficial to leverage TE expertise from TEAS WG 
to
progress SR-TE there for a cohesive, uniform solution for all tunneling schemes.

[DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. 
This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
[DV] 2- According to TEAS WG charter - 
https://datatracker.ietf.org/wg/teas/about/:
1. Definition of additional abstract service, link, and path
properties such as jitter, delay, and diversity. Extensions
to IGPs to advertise these properties, and extensions to
RSVP-TE to request and to accumulate these properties.

[DV] 3- also notice in the SPRING Charter - 
https://datatracker.ietf.org/wg/spring/about/:
o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering
[DV] Hence I believe “SRTE policy” is a key component of the SR Architecture 
and should pursued as part as the Architecture definition milestone of the 
SPRING WG.

Dan

IMHO..

Thanks,
Himanshu
From: spring  on behalf of Jeff Tantsura 

Date: Sunday, March 18, 2018 at 3:26 PM
To: "Bernier, Daniel" , "bruno.decra...@orange.com" 
, "spring@ietf.org" 
Cc: Alvaro Retana , "spring-cha...@ietf.org" 

Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion

Hi,

I'm not going to repeat all the valid reasons to continue mentioned beforehand.
There's definitely work to be done in architecture and O areas as well as 
co-ordination of various activities across IETF.

Cheers,
Jeff
On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" 
 on behalf of 
daniel.bern...@bell.ca> wrote:

Hi,

I echo the need to continue the SPRING work on service-chaining. There is a 
growing interest to have a mechanism that operates at the forwarding plane 
level using source routing as an alternative to a dedicated service overlay. 
This will surely generate other related work such as automated service 
discovery, inter-domain chaining policies, parallelism versus sequential 
chaining, various control-plane implementations, etc.

Secondly, since there is a tight relation to SR chaining and TE policies, I 
believe there will is a lot of opportunities related to Path Awareness which is 
currently running in IRTF. Opportunities like, intent translation to SR 
policies, Policy requests or announcements between domains and host (probably 
app) level TE policy requests (e.g. how can an app receive a proper policy 
based on its requirements) ?

My humble operator 0.02 cents.

Daniel Bernier | Bell Canada

From: spring > on 
behalf of bruno.decra...@orange.com 
>
Sent: Monday, March 5, 2018 11:59 AM
To: spring@ietf.org
Cc: Alvaro Retana (aretana); 
spring-cha...@ietf.org
Subject: [spring] SPRING - rechartering discussion

Hello WG,

now that nearly all the core documents are in the hands of IESG or beyond, 
we think it is time to (re)discuss rechartering.
We brought up that question few meetings ago and the feedback, at that  
time, was that the WG at least needs to be maintained to discuss the extensions 
following deployment feedback.

But we need also identify technical directions.

In order to initiate the discussion we are proposing some high level items 
but we'd like to make clear a few points before:
 * these are only proposals; what might end-up as the next steps for SPRING 
will be what the WG is willing to work on (which includes having cycles for 
that).
 * what the WG might be rechartered to do is not necessarily limited to 
that; so other proposals are welcome.

 So, we thought of the following:

 * general architectural 

Re: [spring] SPRING - rechartering discussion

[Adrian Farrel]

Yes, OAM, please!
 
There has been some discussion recently about where new SR-related work should 
be done :-)
 
I wonder whether a task for the WG would be to provide clearer coordination of 
the related work in other WGs. Maybe that is a "cookbook", maybe it is just a 
WG wiki. But it seems to me that there is SR work in 10 (count them!) WGs and 
that is not a recipe for a stable and well-managed technology.
 
Adrian
 
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: 19 March 2018 06:48
To: Zafar Ali (zali); Martin Horneffer; spring-cha...@ietf.org
Cc: spring@ietf.org; martin.vigour...@nokia.com; Alvaro Retana 
Subject: Re: [spring] SPRING - rechartering discussion
 

Hi all,

I completely agree with Ali and Martin here, OAM is very important tool for a 
technology to be deployed in a production network, we see more and more 
requirements in this area. I support the idea to add the  OAM milestone to the 
new charter.

Best regards,
Mach
发件人：Zafar Ali (zali)
收件人：Martin Horneffer,spring-cha...@ietf.org,
抄 送：spring@ietf.org,martin.vigour...@nokia.com,Alvaro Retana,
时间：2018-03-18 02:12:03
主 题：Re: [spring] SPRING - rechartering discussion
 
Dear WG Chairs, 

I completely agree with Martin. To add, the task for "New OAM techniques" is 
not only explicitly mentioned in the existing charter 
(https://datatracker.ietf.org/doc/charter-ietf-spring/) but there is a current 
milestone associated with it, "Specify the OAM mechanisms needed to support 
SPRING." 

At the moment the WG has only defined basic ping, traceroute and probing tools. 
From the initial deployments experiences of segment routing, SPs are coming up 
with the new requirements for operation and management, performance monitoring, 
connectivity verification and traffic accounting, etc. There are numerous 
individual contributions in this area listed in the following (see 
https://datatracker.ietf.org/wg/spring/documents/ for detailed list): 

+ draft-ali-spring-sr-traffic-accounting-00. Martin specifically mentioned 
the requirement for traffic accounting. We requested a presentation slot where 
we planned to ask for WG adaptation, but due to time constraint, it did not fit 
the agenda. 
+ draft-hegde-spring-traffic-accounting-for-sr-paths-01 is also addressing 
requirement outlined by Martin. It was presented at the last IETF and was 
subject to engaging discussion on the mailing list. 
+ draft-ali-spring-srv6-oam-00 is on Spring WG agenda Friday, and we plan 
to ask for WG adaptation. 
+ draft-gandhi-spring-sr-mpls-pm-00 requested a slot, but due to time 
constraint, it did not fit the agenda. 
+ draft-ali-spring-srv6-pm-02 also requested a slot, but due to time 
constraint, it did not make it to the agenda. 
+ draft-ali-spring-bfd-sr-policy-00 and draft-mirsky-spring-bfd-05 are on 
Spring agenda for discussion on Friday. 
+ draft-cheng-spring-mpls-path-segment-01
+ draft-fioccola-spring-flow-label-alt-mark-01 
+ draft-li-spring-passive-pm-for-srv6-np-00 

In summary, as you can see that there is a tremendous interest in the SPRING 
OAM area, which is in the existing charter and a current milestone. I would 
like to request WG chair to complete this work in the existing milestone or add 
a new milestone for it. 

Thanks

Regards ... Zafar

On 3/17/18, 8:19 PM, "spring on behalf of Martin Horneffer" 
 wrote:

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into 
production networks, I get the strong feeling that SPRING is not done 
with the conclusion of the core documents. As the technology gets closer 
to production use, unforeseen topics and issues appear that need to be 
discussed and - in many cases - standardized. I do see the need for 
documents of the "operators' requirements" style.

Conflict resolution was one good example. Others are about traffic 
steering and traffic and/or performance measurement und monitoring.

Probably not all networks have the same requirement as ours, but maybe 
there are others that feel like us: we cannot afford to transport 
sginificant huge amounts of traffic if we cannot measure it. Measure it 
in a way that is suitable to generate traffic matrices and and allows to 
offline simulate the whole network.
Same for traffic steering: how can I actually differentiate the traffic 
and have the routers choose the right segment lists for every packet?

While I'm having very good discussions with multiple vendors about these 
topics, I really think this is something that needs to be standardized. 
And in this case it means, in my eyes, that the charter of the SPRING wg 
must be enhanced in some way to allow this kind of discussion and 
standardization.


Best regards, Martin


Am 05.03.18 um 17:59 schrieb 

Re: [spring] SPRING - rechartering discussion

[Loa Andersson]

Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into 
production networks, I get the strong feeling that SPRING is not done 
with the conclusion of the core documents. As the technology gets closer 
to production use, unforeseen topics and issues appear that need to be 
discussed and - in many cases - standardized. I do see the need for 
documents of the "operators' requirements" style.


I take that you don't entirely agree with the "core documents almost
done" in the mail that Marin and Bruno sent starting up the
re-chartering discussion. I think I see your point and the things you
point at certainly needs to be addressed.

Sorry if I misunderstand what you are saying. I don't see the "not
completed" as a reason not take the discussion and actually recharter.
Working do this quite often, since more understanding of the area is
gained through the work done, but at the same time we also see a shift
in focus that we need to capture.

/Loa

--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

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

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[mohamed.boucadair]

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: > on behalf of Robert Raszuk 
>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" 
>, mpls 
>, SPRING WG List 
>, 
"s...@ietf.org" >, 
"b...@ietf.org" >
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

> That proxy may be a bump in the wire between the SFF and SF

I am not so sure about that ... If this would be just "bump in the wire" you 
would have zero guarantees that all packets which need to go via given function 
will actually hit that bump - so this is far from a reliable network service.

There must be associated control plane component attracting traffic to such 
bump.

That mechanism with basic MPLS (where labels by based MPLS architecture are of 
local significance) is available with L3VPN extensions as already progressing 
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you 
state "interim" ?

No one really addressed that question yet and I think it is a critical one to 
make any further judgement  as to the future of this individual submission.

Cheers,
R.



On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel 
> wrote:
Hi Wim,

Thanks for reading the draft so carefully.

> Adrian, on replacement of NSH. You will have to change the SF with this 
> proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which 
> SF(s)
> support MPLS?

This is not about "replacing" the NSH. As you'll see from point 2, below, this 
is about providing an interim / migration technology.

Clearly (and I think you agree) in the case where an SF is not SFC-aware, a 
proxy must be used. That proxy may be a bump in the wire between the SFF and 
SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the 
first two options are available. In the case of a VNF, all three options exist.

Now, let us recall where we are starting from. There are PNFs and there are 
VNFs built to look like PNFs. These SFs do not support MPLS or NSH.

Similarly, there are routers that do not support the NSH.

Now, of course, we would all love to sell major upgrades so that every 
component of the network is SFC-aware. But we would also like to start 
deploying SFC into existing network infrastructure.

So your question misses the point. The question to ask is which brownfield 
routers and SFs support NSH?

Cheers,
Adrian
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING - rechartering discussion

[Mach Chen]

Hi all,

I completely agree with Ali and Martin here, OAM is very important tool for a 
technology to be deployed in a production network, we see more and more 
requirements in this area. I support the idea to add the  OAM milestone to the 
new charter.

Best regards,
Mach
发件人：Zafar Ali (zali)
收件人：Martin Horneffer,spring-cha...@ietf.org,
抄 送：spring@ietf.org,martin.vigour...@nokia.com,Alvaro Retana,
时间：2018-03-18 02:12:03
主 题：Re: [spring] SPRING - rechartering discussion

Dear WG Chairs,

I completely agree with Martin. To add, the task for "New OAM techniques" is 
not only explicitly mentioned in the existing charter
(https://datatracker.ietf.org/doc/charter-ietf-spring/) but there is a current 
milestone associated with it, "Specify the OAM mechanisms needed to support 
SPRING."

At the moment the WG has only defined basic ping, traceroute and probing tools. 
From the initial deployments experiences of segment routing, SPs are coming up 
with the new requirements for operation and management, performance monitoring, 
connectivity verification and traffic accounting, etc. There are numerous 
individual contributions in this area listed in the following (see 
https://datatracker.ietf.org/wg/spring/documents/ for detailed list):

+ draft-ali-spring-sr-traffic-accounting-00. Martin specifically mentioned 
the requirement for traffic accounting. We requested a presentation slot where 
we planned to ask for WG adaptation, but due to time constraint, it did not fit 
the agenda.
+ draft-hegde-spring-traffic-accounting-for-sr-paths-01 is also addressing 
requirement outlined by Martin. It was presented at the last IETF and was 
subject to engaging discussion on the mailing list.
+ draft-ali-spring-srv6-oam-00 is on Spring WG agenda Friday, and we plan 
to ask for WG adaptation.
+ draft-gandhi-spring-sr-mpls-pm-00 requested a slot, but due to time 
constraint, it did not fit the agenda.
+ draft-ali-spring-srv6-pm-02 also requested a slot, but due to time 
constraint, it did not make it to the agenda.
+ draft-ali-spring-bfd-sr-policy-00 and draft-mirsky-spring-bfd-05 are on 
Spring agenda for discussion on Friday.
+ draft-cheng-spring-mpls-path-segment-01
+ draft-fioccola-spring-flow-label-alt-mark-01
+ draft-li-spring-passive-pm-for-srv6-np-00

In summary, as you can see that there is a tremendous interest in the SPRING 
OAM area, which is in the existing charter and a current milestone. I would 
like to request WG chair to complete this work in the existing milestone or add 
a new milestone for it.

Thanks

Regards ... Zafar

On 3/17/18, 8:19 PM, "spring on behalf of Martin Horneffer" 
 wrote:

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into
production networks, I get the strong feeling that SPRING is not done
with the conclusion of the core documents. As the technology gets closer
to production use, unforeseen topics and issues appear that need to be
discussed and - in many cases - standardized. I do see the need for
documents of the "operators' requirements" style.

Conflict resolution was one good example. Others are about traffic
steering and traffic and/or performance measurement und monitoring.

Probably not all networks have the same requirement as ours, but maybe
there are others that feel like us: we cannot afford to transport
sginificant huge amounts of traffic if we cannot measure it. Measure it
in a way that is suitable to generate traffic matrices and and allows to
offline simulate the whole network.
Same for traffic steering: how can I actually differentiate the traffic
and have the routers choose the right segment lists for every packet?

While I'm having very good discussions with multiple vendors about these
topics, I really think this is something that needs to be standardized.
And in this case it means, in my eyes, that the charter of the SPRING wg
must be enhanced in some way to allow this kind of discussion and
standardization.


Best regards, Martin


Am 05.03.18 um 17:59 schrieb bruno.decra...@orange.com:
> Hello WG,
>
> now that nearly all the core documents are in the hands of IESG or 
beyond, we think it is time to (re)discuss rechartering.
> We brought up that question few meetings ago and the feedback, at that  
time, was that the WG at least needs to be maintained to discuss the extensions 
following deployment feedback.
>
> But we need also identify technical directions.
>
> In order to initiate the discussion we are proposing some high level 
items but we'd like to make clear a few points before:
>   * these are only proposals; what might end-up as the next steps for 
SPRING will be what the WG is willing to work on (which includes having cycles 
for that).
>   * what the WG might be rechartered to do is