Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Bernier, Daniel]

Hi,

As a contributor I support the adoption and not aware of any IPR

Thanks

Dan Bernier

From: "Bocci, Matthew (Nokia - GB)" 
Date: Monday, November 30, 2020 at 12:15 PM
To: "draft-ietf-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05
Resent-From: 

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

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.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Bernier, Daniel]

Hi,


As co-author I approve adoption. I am also unaware of any undisclosed IPR


Cheers,


Dan B?


From: BESS  on behalf of Bocci, Matthew (Nokia - GB) 

Sent: Friday, September 27, 2019 6:59 AM
To: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [EXT][bess] WG adoption and IPR poll for 
draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures 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.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

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 <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 <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> on behalf of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
<mohamed.boucad...@orange.com<mailto: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<mailto:bess@ietf.org>; 
s...@ietf.org<mailto: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<mailto:s...@ietf.org>; 
bess@ietf.org<mailto: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 &l

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,