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

2018-03-21 Thread Bernier, Daniel 
t;mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; 
UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim (Nokia - 
BE/Antwerp) <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert 
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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 : mpl

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

2018-03-21 Thread mohamed.boucadair 
us encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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,

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

2018-03-21 Thread stephane.litkowski 
th various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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.

T

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

2018-03-21 Thread Bernier, Daniel 
+1 to Jim and Avinash


Same challenge on our side.


Our network is built upon a MPLS data plane. My current "network appliances" 
are connected to MPLS devices and service instantiation done through static 
pseudowires. It will be easier for me to introduce SRTE policy capabilities 
through software upgrades instead of certifying and introducing new hardware to 
enable a newer encap.


And by the time we get to leverage contextual metadata between functions, most 
probably, these will have also evolved (micro-services, hw/sw disaggregation) 
and new ways of conveying that metadata will have been proposed.


Thanks,


PS: I am also wondering why it is so badly seen to look at alternatives to NSH 
SFC while at the same time we introduce new WG to discuss DC routing (RIFT, 
LSVR, ...). If we accept multiplicity in that space, and I think we should, 
then we should allow it in chain composition and programming.


Cheers,


Daniel Bernier



From: mpls <mpls-boun...@ietf.org> on behalf of mohamed.boucad...@orange.com 
<mohamed.boucad...@orange.com>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, 
Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; bess@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com<mailto:ar9...@att.com>>; BOUCADAIR Mohamed 
IMT/OLN <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; 
UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim (Nokia - 
BE/Antwerp) <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert 
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@o

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

2018-03-20 Thread mohamed.boucadair 
Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com<mailto:ar9...@att.com>>; BOUCADAIR Mohamed 
IMT/OLN <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; 
UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim (Nokia - 
BE/Antwerp) <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert 
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

W

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

2018-03-20 Thread UTTARO, JAMES 
I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com>; BOUCADAIR Mohamed IMT/OLN 
<mohamed.boucad...@orange.com>; UTTARO, JAMES <ju1...@att.com>; Henderickx, Wim 
(Nokia - BE/Antwerp) <wim.henderi...@nokia.com>; Robert Raszuk 
<rob...@raszuk.net>; Adrian Farrel <adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re

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

2018-03-20 Thread Robert Raszuk 
Jim & Avinash,

Please let's observe that Adrian removed any references to Segment Routing.
What this means that the current proposal is based on vanilla MPLS labels
which by base MPLS architecture have **local significance*. *

You can't assume that out of the sudden label has domain wide or global
meaning with SR references removed any more.

If so this draft in question is not required to dynamically signal a label
bound by operator to given service in a control plane. Just like you
advertise any other label which has local meaning by the node advertising
it. As we pointed out draft-ietf-bess-service-chaining-04 is one option to
signal this. They may be other options, but you either treat label as local
or as domain wide. You can't pretend that under the umbrella of doing
former you are effectively doing latter without admitting it.

Best,
Robert.


On Tue, Mar 20, 2018 at 12:29 PM, UTTARO, JAMES  wrote:

> *I guess I am not being clear.*
>
>
>
> *The issue as I see it is that I do not require NSH to realize the
> creation of simple chains. I simply need SR to realize the chain. Why is
> the IETF forcing me to adopt technology that I do not need, while at the
> same time reducing the number of vendors that I may use in my network as
> this encap will have to be supported by traditional OEMs and others looking
> to get into the business.*
>
>
>
> *TBC I am not against NSH it addresses use cases where dynamic complex
> chains are required. The reality of my world is that I have lots of simpler
> chains i.e FW, LB  and do not need the additional OPEX and CAPEX  costs
> associated with deploying NSH. *
>
>
>
> *Jim Uttaro*
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

2018-03-20 Thread stephane.litkowski 
For simple service chains, policy routing works fine as well (this was what was 
used before bess-service-chaining has come). It becomes a nightmare when the 
service chains are complex.

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Tuesday, March 20, 2018 11:35
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR 
Mohamed IMT/OLN; Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim whats wrong with this draft:
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04

It provides simple service chaining using MPLS techniques


From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski 
<stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>, 
"LINGALA, AVINASH" <ar9...@att.com<mailto:ar9...@att.com>>, "mohamed. 
boucadair" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>, 
"Henderickx, Wim (Nokia - BE/Antwerp)" 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>, Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>, SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>, 
"s...@ietf.org<mailto:s...@ietf.org>" <s...@ietf.org<mailto:s...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com<mailto:ar9...@att.com>>; BOUCADAIR Mohamed 
IMT/OLN <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; 
UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim (Nokia - 
BE/Antwerp) <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert 
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net&g

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

2018-03-20 Thread Henderickx, Wim (Nokia - BE/Antwerp) 
Jim whats wrong with this draft:
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04

It provides simple service chaining using MPLS techniques


From: "UTTARO, JAMES" <ju1...@att.com>
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski <stephane.litkow...@orange.com>, "LINGALA, AVINASH" 
<ar9...@att.com>, "mohamed. boucadair" <mohamed.boucad...@orange.com>, 
"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderi...@nokia.com>, Robert 
Raszuk <rob...@raszuk.net>, Adrian Farrel <adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>, SPRING WG List <spr...@ietf.org>, "s...@ietf.org" 
<s...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com>; BOUCADAIR Mohamed IMT/OLN 
<mohamed.boucad...@orange.com>; UTTARO, JAMES <ju1...@att.com>; Henderickx, Wim 
(Nokia - BE/Antwerp) <wim.henderi...@nokia.com>; Robert Raszuk 
<rob...@raszuk.net>; Adrian Farrel <adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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,

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

2018-03-20 Thread Henderickx, Wim (Nokia - BE/Antwerp) 
Jim and a few others started to document how we can use MPLS as transport to 
support service chaining with NSH.
The draft needs a lot of work and is right now focussed on SR but will also 
work on any MPLS transport: LDP, RSVP, SPRING, etc etc + how to use in 
IP-VPN/EVPN.
We will refine it and update it but for reference:
https://tools.ietf.org/html/draft-guichard-sfc-nsh-sr-00


From: Stephane Litkowski <stephane.litkow...@orange.com>
Date: Tuesday, 20 March 2018 at 10:24
To: "LINGALA, AVINASH" <ar9...@att.com>, "mohamed. boucadair" 
<mohamed.boucad...@orange.com>, "UTTARO, JAMES" we <ju1...@att.com>, 
"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderi...@nokia.com>, Robert 
Raszuk <rob...@raszuk.net>, Adrian Farrel <adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>, SPRING WG List <spr...@ietf.org>, "s...@ietf.org" 
<s...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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

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

2018-03-20 Thread stephane.litkowski 
> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] 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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@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,

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

2018-03-19 Thread 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; bess@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; 
bess@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; 
bess@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; 
bess@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; 
bess@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