Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

[Vinod N Kumar]

Support.

RPF 6513 Section 10.2 talks about pushing information about Active-Sources from 
MSDP to MVPN. This Draft defines the other way communication & nicely plugs the 
existing gaps in MVPN/MSDP Deployments.


Regards,
Vinod Kumar.

From: BESS  on behalf of "A, Keshava" 
Date: Monday, March 12, 2018 at 1:39 PM
To: Susan Hares , "bess@ietf.org" 
Cc: "A, Keshava" 
Subject: Re: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support.

Problem statement is valid.
Treating one protocol (MVPN SA)  output as an input trigger to another protocol 
(MSDP)  needs to be discussed more..


/keshava

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 08, 2018 12:34 AM
To: bess@ietf.org
Subject: Re: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support.  This is an necessary topic and a good start for the work.

Sue

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, February 26, 2018 7:02 AM
To: stephane.litkow...@orange.com; 
bess@ietf.org
Subject: Re: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support as co-author. I am not aware of related IPRs.

This is a simple solution to a practical problem for some MVPN/MSDP deployment 
scenarios.

Thanks.
Jeffrey

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, February 26, 2018 3:01 AM
To: bess@ietf.org
Subject: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01


Hello working group,



This email starts a two-week call for adoption on

draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group 
Document.



Please state on the list if you support the adoption or not (in both cases, 
please also state the reasons).



This poll runs until *the 19th of March*.



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

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



Currently no IPR has been disclosed against this Document.



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



Thank you



(Martin), Matthew, Stéphane

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

[Usman Latif]

Support.

This seems like a much simpler approach for MVPN and MSDP interop

Regards,
Usman

On 12 Mar 2018, at 12:09 pm, A, Keshava 
> wrote:

Support.

Problem statement is valid.
Treating one protocol (MVPN SA)  output as an input trigger to another protocol 
(MSDP)  needs to be discussed more..


/keshava

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 08, 2018 12:34 AM
To: bess@ietf.org
Subject: Re: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support.  This is an necessary topic and a good start for the work.

Sue

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, February 26, 2018 7:02 AM
To: stephane.litkow...@orange.com; 
bess@ietf.org
Subject: Re: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support as co-author. I am not aware of related IPRs.

This is a simple solution to a practical problem for some MVPN/MSDP deployment 
scenarios.

Thanks.
Jeffrey

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, February 26, 2018 3:01 AM
To: bess@ietf.org
Subject: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01


Hello working group,



This email starts a two-week call for adoption on

draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group 
Document.



Please state on the list if you support the adoption or not (in both cases, 
please also state the reasons).



This poll runs until *the 19th of March*.



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

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



Currently no IPR has been disclosed against this Document.



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



Thank you



(Martin), Matthew, Stéphane

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

___
BESS mailing list
BESS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE=XOYa1F39-mj4cWWKyHF229vMHtUvgY6HOk9ufdfixWw=N4G4PXyJu3n-YIWfpWdTNxzrLnKf1vPc2kgSwmGh-iM=
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[NAPIERALA, MARIA H]

I also would like to point out that the service chain forwarding defined by 
draft-ietf-bess-service-chaining is based on original IP packet header. This 
allows to attract the traffic into the chain based on existence of a route to 
the traffic destination. In other words, it allows to insert service chains 
from a routed network.

Maria


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Nokia - 
BE/Antwerp)
Sent: Sunday, March 18, 2018 4:02 PM
To: Robert Raszuk ; Adrian Farrel 
Cc: mpls ; bess@ietf.org; s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

I echo robert’s comment, while I agree that draft-ietf-bess-service-chaining is 
useful work, we should not define yet another data-plane for it.


From: > on behalf of Robert Raszuk 
>
Date: Sunday, 18 March 2018 at 14:27
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" 
>, mpls 
>, "s...@ietf.org" 
>, "bess@ietf.org" 
>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Adrian,

> draft-farrel-mpls-sfc provides another transition tool on the migration to 
> RFC 8300.

Very honestly to me it looks like a road block to faster adoption of NSH not as 
help to migrate to RFC 8300 in any way.

> It allows SFFs to be built as a minor mod to existing routers before there is 
> forwarding plane support for the NSH.

I don't agree with that. "MPLS support" in today's equipment is basic three 
label operations IMPOSE, POP & SWAP. I don't see how hardware which can support 
those three mechanisms can effectively play any role in what one would expect 
from NSH alternative.

And as I mentioned before there is no such a thing like MPLS *only* networks. 
One company tried to build MPLS only (without IP forwarding) router but they 
dropped that plan. So basic IP can carry NSH front ended packet to whichever 
device can process NSH headers.

Adding equivalent processing of now both NSH and MPLS headers (far from basic 
pop,swap, impose) operations does not seems like a useful standards and 
technology investment at this point.

Best,
Robert.







On Sun, Mar 18, 2018 at 11:10 AM, Adrian Farrel 
> wrote:
Wim and Robert,

[Dropping SPRING at this point as (as previously discussed) we have taken / are 
taking SR out of this document]

I think that draft-ietf-bess-service-chaining is really important work: it 
expresses a technique that is implemented and shipping.

On the other hand, this approach is not fully consistent with RFC 7665.

But it does describe an actual SFC technology. Whether it remains in the field 
or is a migration technology only time (and operators) will tell.

Now, if we want to support RFC 7665 and RFC 8300 and use a control plane to 
discover the SFFs and to which SFs they provide access and to install 
"forwarding state" for SFPs, then we also have 
draft-ietf-bess-nsh-bgp-control-plane.

That draft was originally written with RFC 8300 in mind, but with the addition 
of one sub-TLV to indicate the encoding, it also supports 
draft-farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc 
attempts to model RFC 8300 as much as possible.

And that brings us back to "Where do we end up, what transition tools should we 
have, and how many steps to transition are there?"

draft-farrel-mpls-sfc provides another transition tool on the migration to RFC 
8300. It allows SFFs to be built as a minor mod to existing routers before 
there is forwarding plane support for the NSH.

But I want to reiterate that the discussion of wat encoding the SF supports is 
a red herring (certainly in the context of RFC 7665). An SF is either 
"SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support the SFC 
encoding (such as NSH) or it can't. But also, an SF is either locally attached 
to the SFF or not. A local attachment is (of course) easier to operate and 
allows "bump in the wire" proxies very easily. A remote attached SF is (IMHO) 
attached via a tunnel.

The question of "remotely attached SFs" is one that should concern all 
implementations of RFC 7665 because no one (as yet) has worked on a protocol to 
bind SFs to SFFs. Robert is right that providing bump in the wire proxy for 
remotely attached SFs means that it is hard to know/control what goes where. 
But that problem exists to some extent for any remotely attached SF. For that 
reason (among others) I would implement the proxy as part of the SFF.

Cheers,
Adrian

From: Henderickx, Wim (Nokia - BE/Antwerp) 

Re: [bess] [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; 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 

Re: [bess] [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; 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 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; 
bess@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: [bess] [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; 
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 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; 
bess@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; 
bess@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi 

Re: [bess] [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; 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 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; 
bess@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; 
bess@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: [bess] [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; 
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 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; 
bess@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; 
bess@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; bess@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: [bess] [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; bess@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; 
bess@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; bess@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" >, 
"bess@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: [bess] [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; 
bess@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; bess@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" >, 
"bess@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: [bess] [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; bess@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" >, 
"bess@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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess