Re: [bess] draft-ietf-bess-service-chaining

[Stuart Mackie]

Hi Wim,

Stephane had alerted me to these comments you made a while ago, but which I 
missed at the time. Sorry for the delay in getting back to you.

*   The doc is much focused on the VRF constructions and architecture, but in 
some use cases we need to program the SF, which is not always clear and we 
should be a bit more explicit about it in the draft
SM> Agreed that programming the SF will almost always be required, but there 
isn’t any standard way of doing this. I can add a comment to that effect.
*   If a SF is L2 vs L3 we need to program the static NH and IP@ a bit 
different and we should clarify this
SM> I don’t think there is any difference for L3 routes  between L2 and L3 SFs 
– at a service egress the next hop is the forwarder where the next service is 
running with a label that identifies the ingress interface. There is a 
difference in that the VRF has to add an Ethernet header before sending into an 
L2 SF, which for non-transparent would be that of the ingress SF interface 
(known from when the SF was instantiated). For an L2 transparent service, the 
ingress VRF would put the MAC address of the egress forwarder (which since they 
can all be the same, would be the simplest), and then the egress forwarder 
rewrites the L2 destination if forwarding out of the service chain. I’ll add 
some detail on this.
*   A question I have is if in this architecture a SFF could be shared using 
the same interface/sub-interface with other service chains or not. Based on 
this it would also be good to document the things the SFC architecture allows 
and are supported or not with this proposal.
SM> Sharing can be done for transparent L2 SFs, where VLANs can be used to 
identify which virtual network a packet came from (already supported in 
Contrail), and for L3 SFs could potentially be supported using next-table 
policies in VRFs (similar to floating IP addresses). However, that depends on 
service chains being tied to subnets, which isn’t the scenario that is usually 
discussed in mobility applications where the chosen service chain is based on 
subscriber/application. I can add a couple of sentences on this.

Regards

Stuart
-914 886 2534

From: "Henderickx, Wim (Nokia - BE/Antwerp)" 
Date: Monday, November 5, 2018 at 2:17 AM
To: "draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: draft-ietf-bess-service-chaining
Resent-From: 
Resent-To: , , , 
, , 
Resent-Date: Monday, November 5, 2018 at 2:17 AM

Attached were my comments which I sent at the time which were not addressed so 
far in the doc.
Would be good if we can incorporate them before WG last call

https://www.ietf.org/mail-archive/web/bess/current/msg00791.html

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

Re: [bess] Comment on draft-ietf-bess-service-chaining-06

[Stuart Mackie]

Hi Andy,

I‘m struggling to make the connection, since draft-ietf-bess-service-chaining 
is specifically about how to do service chaining without needing a new protocol 
like NSH, so SFF labels would never be used.

In draft-ietf-bess-service-chaining , if MPLS transport were used between 
Service Function Forwarders, a label would be allocated for a SF interface when 
a route pointing to it is installed (by the controller). This would be 
advertised to the controller and from there sent to the forwarders with egress 
interfaces for the previous SF in the chain. The label would be used at the 
bottom of the MPLS stack as is done normally.

Cheers

Stuart
-914 886 2534

From: "Andrew G. Malis" 
Date: Tuesday, December 4, 2018 at 5:10 PM
To: "bess@ietf.org" , 
"draft-ietf-bess-service-chain...@ietf.org" 

Cc: "draft-ietf-mpls-sfc-encapsulat...@ietf.org" 

Subject: Comment on draft-ietf-bess-service-chaining-06
Resent-From: 
Resent-To: , , , 
, , 
Resent-Date: Tuesday, December 4, 2018 at 5:10 PM

I just read the new revision of draft-ietf-bess-service-chaining. Although the 
draft doesn't use the RFC 8300 NSH, it could very easily take advantage of 
features provided by the NSH (such as metadata) by adding NSH over MPLS as 
defined in draft-ietf-mpls-sfc-encapsulation to the list of encapsulations 
listed in section 2.5. And this draft provides an excellent label distribution 
mechanism for NSH over MPLS. It would make a lot of sense to add a reference to 
draft-ietf-mpls-sfc-encapsulation in the list of encapsulations in section 2.5.

Thanks,
Andy

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

[Stuart Mackie]

Support as contributor – I am not aware of any undisclosed IPR.

Stuart
-914 886 2534

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, January 21, 2019 at 5:06 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-nsh-bgp-control-plane [1].



This poll runs until *the 4th of February*.



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.



We have several IPRs already disclosed.



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.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/



[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_



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

[bess] SFC using virtual netoworking draft

[Stuart Mackie]

Hi,

Glad to see BESS formed to hold all of the BGP-enabled services work.

We have a draft that possibly falls in scope of this working group. In summary 
it describes how to use BGP-enabled virtual networking to achieve service 
function chaining without changing existing device functionality or protocols. 
Obviously this work should receive review in the SFC working group, but it also 
is very relevant to BESS.

You can find the draft at 
http://datatracker.ietf.org/doc/draft-mackie-sfc-using-virtual-networking

Thanks,

Stuart
……..

Stuart Mackie
SDN/NFV Architect

+1 914 886 2534

[cid:70EF7949-8F60-4BA3-B5D8-C21D88FEDB77]
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

[Stuart Mackie]

As co-author, I support adoption of this draft. I am not aware of any IPR 
relating to this draft apart from that filed by Ericsson and reported to the 
IETF at the following URL:

- 
https://datatracker.ietf.org/ipr/search/?draft=draft-fm-bess-service-chaining&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent=
 


Stuart
-914 886 2534






On 2/22/16, 11:58 AM, "BESS on behalf of Martin Vigoureux" 
 wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-fm-bess-service-chaining-02 [1] as a working group Document.
>
>Please state on the list if you support adoption or not (in both cases, 
>please also state the reasons).
>
>This poll runs until *the 7th of March*.
>
>Note that IPR has been disclosed against an earlier version of this 
>document:
>https://datatracker.ietf.org/ipr/2284/
>
>Yet, we are *coincidentally* also polling for knowledge of any other
>IPR that applies to this draft, 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 a document author or contributor please
>respond to this email and indicate whether or not you are aware of any
>relevant IPR.
>
>The draft will not be adopted until a response has been received from
>each author and contributor.
>
>If you are not listed as an author or 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 & Thomas
>bess chairs
>
>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

[Stuart Mackie]

As a contributer, I support adoption.

I am not aware of any undisclosed IPR that applies to this document.

Stuart
-914 886 2534

From: BESS  on behalf of Tony Przygienda 

Date: Monday, March 6, 2017 at 12:02 PM
To: Martin Vigoureux 
Cc: "draft-mackie-bess-nsh-bgp-control-pl...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

+1 adoption

On Mon, Mar 6, 2017 at 3:55 AM, Martin Vigoureux 
mailto:martin.vigour...@nokia.com>> wrote:
Hello working group,

This email starts a two-week call for adoption on 
draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a 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 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.

IPR has been disclosed against this Document [2].

If you are not listed as an Author or 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 & Thomas
bess chairs

[1] https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane

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



--
We’ve heard that a million monkeys at a million keyboards could produce the 
complete works of Shakespeare; now, thanks to the Internet, we know that is not 
true.
—Robert Wilensky
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Poll to park almost dead WG documents

[Stuart Mackie]

We would like continue draft-ietf-l3vpn-end-system.

It provides a useful description of the architecture, but the current draft is 
prescriptive/normative about the content of XMPP stanzas. We would like to 
change this to showing the XMPP stanzas as examples of how a solution could be 
implemented.

I will submit an updated draft, at which point it should be ready for adoption.

Stuart
-914 886 2534
From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Thursday, March 22, 2018 at 6:09 AM
To: "bess@ietf.org" 
Subject: [bess] Poll to park almost dead WG documents

Hi WG,

During our meeting in London we have started to get a status on some WG 
documents that have expired.
It looks that some documents does not have support and editor anymore.

This email starts a two weeks poll to hear from you:

-  If you would like to see the documents progressing or not

-  If you volunteer to take over the work on one or more of these 
documents

Please provide your feedback on a per document basis to the list by replying to 
this email.

* The poll ends April 9th *

Please note that by default the document will be parked. To get them alive 
again, we need a  significant amount of support as well as one or more 
volunteer to take over the work. Without those conditions being cleared, a 
document will be parked.

We absolutely need your feedback as we do not want to park a work which has 
still an interest for the working group.

Here is the list of documents we are polling for:

-  draft-ietf-bess-mvpn-pe-ce

-  draft-ietf-bess-virtual-pe

-  draft-ietf-bess-end-system-requirements

-  draft-ietf-bess-evpn-trill

-  draft-ietf-l3vpn-end-system


Thanks for your help,

Best Regards,

Stephane & Matthew

_



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