[bess] IPR statement on draft-ietf-bess-vpls-multihoming

[Kireeti Kompella]

Hi all,

This is to declare as an author that I am not aware of any IPR relevant to this 
draft that has not already been declared. 

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

Re: [bess] About draft-ietf-bess-evpn-igmp-mld-proxy

[Ali Sajassi (sajassi)]

Hi Jorge,

Please refer to my comments inline marked w/ "Ali>"

On 3/21/18, 1:59 AM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Ali and authors,

As discussed during the BESS session, these are the points that I think 
should be addressed in draft-ietf-bess-evpn-igmp-mld-proxy before WG LC:



1) Fast Leave text addition

There are quite a few igmp-snooping implementations in the market that 
support a “Fast Leave” mechanism. EVPN should incorporate/document this too, 
since it is a pretty common use-case.

Implementations allow the use of "Fast Leave" when the IGMP host is 
directly connected to the PE/NVE or the directly connected CE does igmp-proxy 
(and only in those cases). Fast Leave is a local administrative option on each 
AC, that, if enabled, allows the removal of a (x,G) state immediately after the 
reception of an IGMP Leave message for the (x,G). 

Ali> But the option of "fast-leave" requires for the PE to do host tracking and 
in case of IGMPv2, if there are more than one hosts is sitting behind an AC, it 
is difficult to do host-tracking because of the report suppression in IGMPv2 !! 
So, if used, it needs to be used with caution for only a single host for 
IGMPv2. I can add this "fast-tracking" as an option (MAY) but with the caveats 
that it has !!

In the email below, I was suggesting that in some cases the IGMP Leave 
synch route can be avoided; however Mankamana made me see that, in the Fast 
Leave procedure, the PE receiving the IGMP Leave on the ES' AC, should always 
send an IGMP Leave sync route with an indication that the (x,G) state must be 
removed immediately. Mankamana suggested MRT=0 (Max Response Time=0) in the 
route could give that indication to the other PEs in the ES.

Ali> Yes, fast-leave (if used) still need to be synchronized among multi-homing 
PEs (

Authors, can you please add text about Fast Leave?

Ali> Since majority of existing implementation support "fast-leave", we can add 
it as an option (MAY) with the caveats that I described above. 



2) Conflicting text about advertising SMET route when there are local 
sources


"3.2 PE with mixed of attached hosts/VMs and multicast source

The main difference in here is that when PE2 receives IGMPv3 Join
   from H7 for (S2,G2), it does not advertises it in BGP because PE2
   knows that S2 is attached to its local AC."

[JORGE] the above is contradicting this previous statement:

"When the first hop PE receives an IGMPv3 Join for (S,G) on a given
   BD, it advertises the corresponding EVPN Selective Multicast Ethernet
   Tag (SMET) route regardless of whether the source (S) is attached to
   itself or not in order to facilitate the source move in the future."

[JORGE] I tend to agree with the latter statement. It simplifies the 
procedure.

Ali> Since EVPN inherently supports workload mobility, the latter should be the 
default mode of operation. I guess, we can have an option (MAY) for the former 
one.



3) Confusing text in section 7.1.1 about local-bias:

"The Originator Router Address is the IP address of Router Originating
   the prefix. It should be noted that using the "Originating Router's
   IP address" field is needed for local-bias procedures and may be
   needed for building inter-AS multicast underlay tunnels where BGP
   next hop can get over written."

While I agree with the need for this field in Inter-AS, but why would you 
need to check the SMET originating-ip for local bias?

Ali> It is just inter-AS.



4) Minor one: description of Maximum Response Time and Sequence number 
missing in section 7.3 and 7.3.1.

Although both are roughly explained in section 4.2, the description of the 
fields and allowed values is missing in the section that describes the IGMP 
Leave synch route.

Ali> We'll add it.

Cheers,
Ali





The below email captures the points I made during the adoption, but they 
are no longer valid anyway, so please, disregard. However the above points are 
the ones I think should be addressed now.

Thank you!
Jorge



-Original Message-
From: "Rabadan, Jorge (Nokia - US)" 
Date: Thursday, February 9, 2017 at 8:30 AM
To: Thomas Morin , "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-igmp-mld-pr...@ietf.org" 

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

[Bernier, Daniel]

​Hi Med,


Please see inline


Cheers


Daniel Bernier


From: mohamed.boucad...@orange.com 
Sent: Wednesday, March 21, 2018 5:06 AM
To: Bernier, Daniel
Cc: mpls; SPRING WG List; bess@ietf.org; s...@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Hi Daniel,

I’m afraid that the comparison with DC routing is misleading here. It is still 
possible to use your favorite transport encapsulation with the approach 
endorsed by the IETF in 8300.

DB> ​But that means in that case I must use RFC8300, my view is there is an 
option for RFC8300 but there CAN be others.

Re-using NSH instead of mimic it in each individual transport protocol is much 
more pragmatic. It avoids wasting extra specification in defining exactly the 
same set of information for each of one’s favorite transport encapsulating 
protocol.

DB> ​This is where I am not convinced there is a need to mimic NSH operations 
altogether. But we can sit together this week and discuss.

Tests (including regression tests) are required anyway even in the case you 
mentioned.

DB> Doing testing including regression on software is way less impactful than 
sending technicians to swap out linecards on devices.

Cheers,
Med

De : Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Envoyé : mercredi 21 mars 2018 00:53
À : BOUCADAIR Mohamed IMT/OLN; 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
Objet : Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


+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 > on behalf of 
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]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES 

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

[mohamed.boucadair]

Hi Daniel,

I’m afraid that the comparison with DC routing is misleading here. It is still 
possible to use your favorite transport encapsulation with the approach 
endorsed by the IETF in 8300.

Re-using NSH instead of mimic it in each individual transport protocol is much 
more pragmatic. It avoids wasting extra specification in defining exactly the 
same set of information for each of one’s favorite transport encapsulating 
protocol.

Tests (including regression tests) are required anyway even in the case you 
mentioned.

Cheers,
Med

De : Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Envoyé : mercredi 21 mars 2018 00:53
À : BOUCADAIR Mohamed IMT/OLN; 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
Objet : Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


+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 > on behalf of 
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]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; 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

> 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 

[bess] About draft-ietf-bess-evpn-igmp-mld-proxy

[Rabadan, Jorge (Nokia - US/Mountain View)]

Ali and authors,

As discussed during the BESS session, these are the points that I think should 
be addressed in draft-ietf-bess-evpn-igmp-mld-proxy before WG LC:


1) Fast Leave text addition

There are quite a few igmp-snooping implementations in the market that support 
a “Fast Leave” mechanism. EVPN should incorporate/document this too, since it 
is a pretty common use-case.

Implementations allow the use of "Fast Leave" when the IGMP host is directly 
connected to the PE/NVE or the directly connected CE does igmp-proxy (and only 
in those cases). Fast Leave is a local administrative option on each AC, that, 
if enabled, allows the removal of a (x,G) state immediately after the reception 
of an IGMP Leave message for the (x,G). 

In the email below, I was suggesting that in some cases the IGMP Leave synch 
route can be avoided; however Mankamana made me see that, in the Fast Leave 
procedure, the PE receiving the IGMP Leave on the ES' AC, should always send an 
IGMP Leave sync route with an indication that the (x,G) state must be removed 
immediately. Mankamana suggested MRT=0 (Max Response Time=0) in the route could 
give that indication to the other PEs in the ES.

Authors, can you please add text about Fast Leave?


2) Conflicting text about advertising SMET route when there are local sources


"3.2 PE with mixed of attached hosts/VMs and multicast source

The main difference in here is that when PE2 receives IGMPv3 Join
   from H7 for (S2,G2), it does not advertises it in BGP because PE2
   knows that S2 is attached to its local AC."

[JORGE] the above is contradicting this previous statement:

"When the first hop PE receives an IGMPv3 Join for (S,G) on a given
   BD, it advertises the corresponding EVPN Selective Multicast Ethernet
   Tag (SMET) route regardless of whether the source (S) is attached to
   itself or not in order to facilitate the source move in the future."

[JORGE] I tend to agree with the latter statement. It simplifies the procedure.


3) Confusing text in section 7.1.1 about local-bias:

"The Originator Router Address is the IP address of Router Originating
   the prefix. It should be noted that using the "Originating Router's
   IP address" field is needed for local-bias procedures and may be
   needed for building inter-AS multicast underlay tunnels where BGP
   next hop can get over written."

While I agree with the need for this field in Inter-AS, but why would you need 
to check the SMET originating-ip for local bias?


4) Minor one: description of Maximum Response Time and Sequence number missing 
in section 7.3 and 7.3.1.

Although both are roughly explained in section 4.2, the description of the 
fields and allowed values is missing in the section that describes the IGMP 
Leave synch route.




The below email captures the points I made during the adoption, but they are no 
longer valid anyway, so please, disregard. However the above points are the 
ones I think should be addressed now.

Thank you!
Jorge



-Original Message-
From: "Rabadan, Jorge (Nokia - US)" 
Date: Thursday, February 9, 2017 at 8:30 AM
To: Thomas Morin , "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01

I support this document for WG adoption.

Having said that, I made a few observations to the authors, and I believe 
they agreed to make some changes in the next revision. The main things that I 
believe should be reflected in the next rev after WG adoption are:

1- Simplified BGP route encoding
I discussed with the authors that the Join and Leave synch behavior may 
have been achieved with a single route type, as opposed to the proposed two 
types (type 7 and 8). 
The authors believe it is better to keep both, which is ok, but: 
a) the route type 8 – IGMP leave synch route – should be simplified: the 
max response time and sequence number fields in the route introduce an 
unnecesary complexity and should be removed. 
b) Route type 8 should be optional since: i) It is actually not needed for 
IGMPv1 and 2) It is not needed either if a fast leave mechanism is used (see 
point 2).

2- Fast Leave addition to the draft
There are quite a few igmp-snooping implementations in the market that 
support a “Fast Leave” mechanism. EVPN should incorporate/document this too.
Implementations allow the use of "Fast Leave" when the IGMP host is 

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

[stephane.litkowski]

Hi Daniel,

You may need to introduce new hardware as well for SRTE to handle the number of 
labels to push.
If your hardware is flexible (network processors), there is a chance that it 
can also handle NSH.

Now if you want just to use SR policies to perform a kind of service chaining, 
is there something really specific to develop ? Can’t you do this today with 
the “existing” SRTE machinery and SIDs that are available: you need Node-SID 
for transport compression, and a SID to forward to the VNF (similar to the EPE 
SID).

Brgds,

Stephane


From: Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Sent: Wednesday, March 21, 2018 00:53
To: BOUCADAIR Mohamed IMT/OLN; 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


+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 > on behalf of 
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]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; 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

> 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 

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

[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  on behalf of 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]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; 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

> 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
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx,