Re: [bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[Ali Sajassi (sajassi)]

Support as a co-author. I am not aware of any undisclosed IPR.

Cheers,
Ali

From: "stephane.litkow...@orange.com" 
Date: Monday, February 18, 2019 at 7:53 AM
To: "draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
Resent-From: 
Resent-To: , Cisco Employee , 
, , , 
, 
Resent-Date: Monday, February 18, 2019 at 7:53 AM


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[Jeff Tantsura]

Yes/support

Cheers,
Jeff
On Feb 18, 2019, 7:53 AM -0800, stephane.litkow...@orange.com, wrote:
> This email begins a two-week poll for adoption of 
> draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.
>
> Regards,
> Stephane and Matthew
>
> [1] 
> https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/
>
> _
>
> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[Mankamana Mishra (mankamis)]

Support the adoption.

Thanks
Mankamana


From: "stephane.litkow...@orange.com" 
Date: Monday, February 18, 2019 at 7:53 AM
To: "draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
Resent-From: 
Resent-To: , , 

Resent-Date: Monday, February 18, 2019 at 7:53 AM


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

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

As co-author, I support this document for adoption.
Not aware of any relevant IPR.

Thank you.
Jorge

From: "stephane.litkow...@orange.com" 
Date: Monday, February 18, 2019 at 4:53 PM
To: "draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Monday, February 18, 2019 at 4:53 PM


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[John E Drake]

Support.  I'm not aware of any IPR.

Yours Irrespectively,

John

From: stephane.litkow...@orange.com 
Sent: Monday, February 18, 2019 10:53 AM
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[UTTARO, JAMES]

As co-author

Support.

Not aware of any undisclosed IPR.

Thanks,
  Jim Uttaro

From: stephane.litkow...@orange.com 
Sent: Monday, February 18, 2019 10:53 AM
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[stephane.litkowski]

This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_

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] A question on using EVPN label and Alias label in load balancing

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

Ok, let me elaborate.

A remote PE sending known unicast traffic to any PE attached to the all-active 
Ethernet Segment (non-DF or DF, it’s irrelevant here!), has to use a label that 
identifies the Broadcast Domain at the egress PE for a MAC lookup (if MAC-based 
forwarding) or a label that identifies the egress ES (MPLS-based forwarding 
model).



Either way, it may happen that the ingress aliasing hash for a flow to MAC1, 
decides to send the unicast packet to a PE, PE2 that never advertised MAC1, but 
it is attached to the same ES; hence the only label available is the A-D per 
EVI route label.

If there is a MAC/IP route _and_ an A-D per-EVI route for the same ES and 
next-hop, the label should be the same anyway in case of MAC-based forwarding, 
and even in case of MPLS-based forwarding with label per ES. I can only see 
different labels if the egress PE forwarding model was label per MAC, which I 
don’t think there is any implementation like that out there. Bottom line, I 
would use the label from the A-D per-EVI route since, there might not be MAC/IP 
route for all the next-hops in the ES.







From: Muthu Arul Mozhi Perumal 

Date: Monday, February 18, 2019 at 3:29 PM

To: "Rabadan, Jorge (Nokia - US/Mountain View)" 

Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing



Believe Jaikumar's question is, whether it is allowed per RFC 7432 to send 
known unicast traffic to a non-DF PE (for load balancing in all active 
multihoming scenario) using alias label when the non-DF PE has advertised a 
MAC/IP route with an EVPN label for the destination MAC. In other words, would 
sending known unicast traffic using alias label when there is a MAC/IP route 
for the destination MAC be a violation of RFC 7432 in the above scenario and is 
expected to cause any interop. issue?



Regards,

Muthu



On Mon, Feb 18, 2019 at 7:24 PM Rabadan, Jorge (Nokia - US/Mountain View) 
 wrote:

It “sounds” to me that Jaikumar’s question might be related to comparing 
MPLS-based vs MAC-based forwarding models.

RFC8388 may help, sections 6-8.



My 2 cents.



Thx

Jorge



From: BESS  on behalf of Jide Akintola 
mailto:40yahoo@dmarc.ietf.org>

Date: Monday, February 18, 2019 at 1:23 PM

To: "mailto:bess@ietf.org; , Jaikumar Somasundaram 


Cc: Jide Akintola 

Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing



Hi Jaikumar,



You need to make a distinction between Alias label and several other EVPN 
routes labels defined in the RFC7432. Kindly check that RFC for the route 
encoding and their different usage/function.



As detailed in my previous email, alias label is a "hint" to the remote PE to 
load balance traffic, they are not used to do the actual traffic load balance.





Many thanks.



Cheers,



Jide





On Monday, 18 February 2019, 11:48:21 GMT, Jaikumar Somasundaram 
 wrote:





Thanks a lot Jide, for the reply.

Please find my response below [Jai]



Thanks & Regards

Jaikumar S



From: Jide Akintola 

Sent: Monday, February 18, 2019 5:00 PM

To: mailto:bess@ietf.org; Jaikumar Somasundaram 


Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing



Hi Jaikumar,



As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes..



Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.



In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.



For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.

[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. 
I see the only difference between EPN label and Alias label is that Mac look up 
will happen but Alias label does not expect the MAC entry to be present and so 
no MAC lookup is required

and simply forward it on the ESI port/link. Please correct me if something is 
not right.





There are some optimization done 

Re: [bess] A question on using EVPN label and Alias label in load balancing

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

It “sounds” to me that Jaikumar’s question might be related to comparing 
MPLS-based vs MAC-based forwarding models.
RFC8388 may help, sections 6-8.

My 2 cents.

Thx
Jorge

From: BESS  on behalf of Jide Akintola 

Date: Monday, February 18, 2019 at 1:23 PM
To: "bess@ietf.org" , Jaikumar Somasundaram 

Cc: Jide Akintola 
Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing

Hi Jaikumar,

You need to make a distinction between Alias label and several other EVPN 
routes labels defined in the RFC7432. Kindly check that RFC for the route 
encoding and their different usage/function.

As detailed in my previous email, alias label is a "hint" to the remote PE to 
load balance traffic, they are not used to do the actual traffic load balance.


Many thanks.

Cheers,

Jide


On Monday, 18 February 2019, 11:48:21 GMT, Jaikumar Somasundaram 
 wrote:



Thanks a lot Jide, for the reply.

Please find my response below [Jai]



Thanks & Regards

Jaikumar S



From: Jide Akintola 
Sent: Monday, February 18, 2019 5:00 PM
To: bess@ietf.org; Jaikumar Somasundaram 
Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing



Hi Jaikumar,



As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes..

Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.

[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. 
I see the only difference between EPN label and Alias label is that Mac look up 
will happen but Alias label does not expect the MAC entry to be present and so 
no MAC lookup is required

and simply forward it on the ESI port/link. Please correct me if something is 
not right.


There are some optimization done by some vendor using proxy advertisement via 
PE2 to mitigate traffic loss for cases where say PE3 only learns MAC1 from say 
PE1 and say you lost PE1.



Many thanks.

Cheers,

Jide





On Monday, 18 February 2019, 10:08:02 GMT, Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>> 
wrote:





Hi All,

 --

 ||

  PORT1 |  DEVICE1   |PORT3

   --| PE1|-

   |  1/5|  2.2.2.2   | 1/4 |

   | || |

   | -- |

   |PORT1  |PORT2   |PORT2

--| ++--

 ||| |||
|

 | DEVICE4|| ||PORT1   | DEVICE4
|

 | (CE1)  || |   DEVICE3  || (CE2)  
|

 | Multi-home || | PE3 |   PORT3| Single 
home|

 ||| |   4.4.4.4  ||
|

--| ++--

   |PORT2  |1/1|PORT3

   |   |PORT2  | 1/6

   | --|

   | |||

   |   PORT1 |  DEVICE2   ||

   --|PE2 |-

1/4  |  3.3.3.3   |PORT3

 ||1/4

 --



Let’s say CE1 is connected to PE1 and PE2 (all-active case)

and PE1 and PE2 learn same MAC1 entry (say different destination)

PE3 will learn MAC1 from both PE1 and PE2 with their respective

EVPN label (Assume BGP ECMP is enabled). As part of load balancing,

should PE3 always use EVPN label to send the frame destined to MAC1

or can Alias label also be used? what is the need of using EVPN label?



Thanks & Regards

Jaikumar S



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

Re: [bess] A question on using EVPN label and Alias label in load balancing

[Jide Akintola]

Hi Jaikumar,
You need to make a distinction between Alias label and several other EVPN 
routes labels defined in the RFC7432. Kindly check that RFC for the route 
encoding and their different usage/function.
As detailed in my previous email, alias label is a "hint" to the remote PE to 
load balance traffic, they are not used to do the actual traffic load balance.


Many thanks. 
 
Cheers, 
 
Jide 

On Monday, 18 February 2019, 11:48:21 GMT, Jaikumar Somasundaram 
 wrote:  
 
 #yiv1165875085 #yiv1165875085 -- _filtered #yiv1165875085 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1165875085 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv1165875085 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1165875085 
{font-family:Verdana;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv1165875085 
{font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;} _filtered #yiv1165875085 
{font-family:Old;panose-1:2 5 6 4 5 5 5 2 2 4;}#yiv1165875085 #yiv1165875085 
p.yiv1165875085MsoNormal, #yiv1165875085 li.yiv1165875085MsoNormal, 
#yiv1165875085 div.yiv1165875085MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 a:link, #yiv1165875085 span.yiv1165875085MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv1165875085 a:visited, #yiv1165875085 
span.yiv1165875085MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv1165875085 
p.yiv1165875085msonormal0, #yiv1165875085 li.yiv1165875085msonormal0, 
#yiv1165875085 div.yiv1165875085msonormal0 
{margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 p.yiv1165875085msonormal, #yiv1165875085 li.yiv1165875085msonormal, 
#yiv1165875085 div.yiv1165875085msonormal 
{margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 p.yiv1165875085msochpdefault, #yiv1165875085 li.yiv1165875085msochpdefault, 
#yiv1165875085 div.yiv1165875085msochpdefault 
{margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 span.yiv1165875085msohyperlink {}#yiv1165875085 
span.yiv1165875085msohyperlinkfollowed {}#yiv1165875085 
span.yiv1165875085emailstyle17 {}#yiv1165875085 p.yiv1165875085msonormal1, 
#yiv1165875085 li.yiv1165875085msonormal1, #yiv1165875085 
div.yiv1165875085msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 p.yiv1165875085msonormal2, #yiv1165875085 li.yiv1165875085msonormal2, 
#yiv1165875085 div.yiv1165875085msonormal2 
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 span.yiv1165875085msohyperlink1 
{color:#0563C1;text-decoration:underline;}#yiv1165875085 
span.yiv1165875085msohyperlinkfollowed1 
{color:#954F72;text-decoration:underline;}#yiv1165875085 
span.yiv1165875085emailstyle171 
{font-family:Consolas;color:windowtext;}#yiv1165875085 
p.yiv1165875085msochpdefault1, #yiv1165875085 li.yiv1165875085msochpdefault1, 
#yiv1165875085 div.yiv1165875085msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv1165875085
 span.yiv1165875085EmailStyle30 
{font-family:Consolas;color:#0070C0;}#yiv1165875085 .yiv1165875085MsoChpDefault 
{font-size:10.0pt;} _filtered #yiv1165875085 {margin:1.0in 1.0in 1..0in 
1.0in;}#yiv1165875085 div.yiv1165875085WordSection1 {}#yiv1165875085 
Thanks a lot Jide, for the reply.
 
Please find my response below [Jai]
 
  
 
Thanks & Regards
 
Jaikumar S
 
  
 
From: Jide Akintola  
Sent: Monday, February 18, 2019 5:00 PM
To: bess@ietf.org; Jaikumar Somasundaram 
Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing
 
  
 
HiJaikumar,
 
  
 
As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes.

Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.
 
[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. 
I see the only difference between EPN label and Alias label is that Mac look up 
will happen but Alias 

Re: [bess] A question on using EVPN label and Alias label in load balancing

[Jaikumar Somasundaram]

Thanks a lot Jide, for the reply.
Please find my response below [Jai]

Thanks & Regards
Jaikumar S

From: Jide Akintola 
Sent: Monday, February 18, 2019 5:00 PM
To: bess@ietf.org; Jaikumar Somasundaram 
Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing

Hi Jaikumar,

As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes.

Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.
[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. 
I see the only difference between EPN label and Alias label is that Mac look up 
will happen but Alias label does not expect the MAC entry to be present and so 
no MAC lookup is required
and simply forward it on the ESI port/link. Please correct me if something is 
not right.


There are some optimization done by some vendor using proxy advertisement via 
PE2 to mitigate traffic loss for cases where say PE3 only learns MAC1 from say 
PE1 and say you lost PE1.

Many thanks.

Cheers,

Jide


On Monday, 18 February 2019, 10:08:02 GMT, Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>> 
wrote:



Hi All,

 --

 ||

  PORT1 |  DEVICE1   |PORT3

   --| PE1|-

   |  1/5|  2.2.2.2   | 1/4 |

   | || |

   | -- |

   |PORT1  |PORT2   |PORT2

--| ++--

 ||| |||
|

 | DEVICE4|| ||PORT1   | DEVICE4
|

 | (CE1)  || |   DEVICE3  || (CE2)  
|

 | Multi-home || | PE3 |   PORT3| Single 
home|

 ||| |   4.4.4.4  ||
|

--| ++--

   |PORT2  |1/1|PORT3

   |   |PORT2  | 1/6

   | --|

   | |||

   |   PORT1 |  DEVICE2   ||

   --|PE2 |-

1/4  |  3.3.3.3   |PORT3

 ||1/4

 --



Let’s say CE1 is connected to PE1 and PE2 (all-active case)

and PE1 and PE2 learn same MAC1 entry (say different destination)

PE3 will learn MAC1 from both PE1 and PE2 with their respective

EVPN label (Assume BGP ECMP is enabled). As part of load balancing,

should PE3 always use EVPN label to send the frame destined to MAC1

or can Alias label also be used? what is the need of using EVPN label?



Thanks & Regards

Jaikumar S


___
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] A question on using EVPN label and Alias label in load balancing

[Jide Akintola]

Hi Jaikumar,
As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes.

Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.

There are some optimization done by some vendor using proxy advertisement via 
PE2 to mitigate traffic loss for cases where say PE3 only learns MAC1 from say 
PE1 and say you lost PE1.

Many thanks. 
 
Cheers, 
 
Jide 

On Monday, 18 February 2019, 10:08:02 GMT, Jaikumar Somasundaram 
 wrote:  
 
  
Hi All,
 
 --
 
 |    |
 
  PORT1 |  DEVICE1   |PORT3
 
   --| PE1    |-
 
   |  1/5    |  2.2.2.2   | 1/4 |
 
   | |    | |
 
   | -- |
 
   |PORT1  |PORT2   |PORT2
 
--    | ++    
-- 
 
 |    |    | |    |    |    
|
 
 | DEVICE4    |    | |    |PORT1   | DEVICE4    
|
 
 | (CE1)  |    | |   DEVICE3  || (CE2)  
|
 
 | Multi-home |    | | PE3 |   PORT3| Single 
home|
 
 |    |    |     |   4.4.4.4  |    |    
|
 
--    | ++    
--  
 
   |PORT2  |1/1    |PORT3
 
   |   |PORT2  | 1/6
 
   |     --    |
 
   | |    |    |
 
   |   PORT1 |  DEVICE2   |    |
 
   --|    PE2 |-
 
    1/4  |  3.3.3.3   |PORT3
 
 |    |1/4
 
 --
 
  
 
Let’s say CE1 is connected to PE1 and PE2 (all-active case)
 
and PE1 and PE2 learn same MAC1 entry (say different destination)
 
PE3 will learn MAC1 from both PE1 and PE2 with their respective
 
EVPN label (Assume BGP ECMP is enabled). As part of load balancing,
 
should PE3 always use EVPN label to send the frame destined to MAC1
 
or can Alias label also be used? what is the need of using EVPN label?
 
  
 
Thanks & Regards
 
Jaikumar S
 
  
 ___
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

[bess] A question on using EVPN label and Alias label in load balancing

[Jaikumar Somasundaram]

Hi All,
 --
 ||
  PORT1 |  DEVICE1   |PORT3
   --| PE1|-
   |  1/5|  2.2.2.2   | 1/4 |
   | || |
   | -- |
   |PORT1  |PORT2   |PORT2
--| ++--
 ||| |||
|
 | DEVICE4|| ||PORT1   | DEVICE4
|
 | (CE1)  || |   DEVICE3  || (CE2)  
|
 | Multi-home || | PE3 |   PORT3| Single 
home|
 ||| |   4.4.4.4  ||
|
--| ++--
   |PORT2  |1/1|PORT3
   |   |PORT2  | 1/6
   | --|
   | |||
   |   PORT1 |  DEVICE2   ||
   --|PE2 |-
1/4  |  3.3.3.3   |PORT3
 ||1/4
 --

Let's say CE1 is connected to PE1 and PE2 (all-active case)
and PE1 and PE2 learn same MAC1 entry (say different destination)
PE3 will learn MAC1 from both PE1 and PE2 with their respective
EVPN label (Assume BGP ECMP is enabled). As part of load balancing,
should PE3 always use EVPN label to send the frame destined to MAC1
or can Alias label also be used? what is the need of using EVPN label?

Thanks & Regards
Jaikumar S

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

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[stephane.litkowski]

Hi WG,

The document has been updated to fulfil the comments raised by the WG.
The document is now ready to go to the next step.

Brgds,



From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Thursday, January 31, 2019 03:25
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hi Stephane,

I have addressed all the comments from the people you mentioned in your email 
below as well as some additional comment received after WGLC ended. I will 
check in a new rev. shortly.

Cheers,
Ali

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

Date: Monday, September 3, 2018 at 1:23 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 

Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

The document has a good level of support to progress. However there are several 
comments raised that have not been answered yet.

Authors,

Could you please address the comments that have been raised on the list (from 
Acee, Krysztof, and Luc Andre) ?


Thanks,

Stephane


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Wednesday, August 08, 2018 16:04
To: bess@ietf.org
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_



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.

_



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.

_

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 

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

[stephane.litkowski]

Hi,

The WGLC has ended.
A new revision of the draft is required based on the discussions.

Authors,

Please publish the new revision, so we can proceed to the next step.

Brgds,


From: Andrew G. Malis [mailto:agma...@gmail.com]
Sent: Monday, January 28, 2019 15:37
To: John E Drake
Cc: Henderickx, Wim (Nokia - BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; 
bess@ietf.org; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

Thanks, much appreciated.

And for Stephane and Matthew, seeing as I just contributed some text, I'm not 
aware of any IPR associated with this draft.

Cheers,
Andy


On Mon, Jan 28, 2019 at 8:07 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Andy,

We’ll add it to the next revision.  Thanks for your help.

Yours Irrespectively,

John

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Sunday, January 27, 2019 11:48 AM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) 
mailto:wim.henderi...@nokia.com>>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

Thanks for confirming, that makes me very comfortable with the readability of 
your draft, seeing as I was able to get it right the first time. :-)

I'd like to request the addition of the following text (or similar, feel free 
to edit for readability and/or correctness), after which I'll be happy to 
support publication of the draft.


7.8 Support for MPLS-Encapsulated NSH Packets

[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC packets using 
the NSH over an MPLS transport network. Signaling MPLS encapsulation of SFC 
packets using the NSH is also supported by this document by using the "BGP 
Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 (representing 
"MPLS Label Stack") from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" 
registry defined in [I-D.ietf-idr-tunnel-encaps], and also using the "SFP 
Traversal With MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" 
with bit 0 set and bit 1 cleared.


BTW, draft-ietf-mpls-sfc-encapsulation has already been submitted to the IESG 
for publication, so adding the reference won't add any delay to this draft.

Thanks again,
Andy


On Sun, Jan 27, 2019 at 10:19 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Andy,

That sounds right.

Yours Irrespectively,

John

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Friday, January 25, 2019 6:32 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) 
mailto:wim.henderi...@nokia.com>>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

So, in order to support draft-ietf-mpls-sfc-encapsulation, looking at 
draft-ietf-idr-tunnel-encaps, you would use the value 10 from the "BGP Tunnel 
Encapsulation Attribute Sub-TLVs" registry, and also from your draft use the 
SFP Traversal With MPLS Label Stack TLV and the SPI/SI Representation sub-TLV 
with bit 0 set and bit 1 cleared? I just want to make sure I correctly read the 
details.

Thanks,
Andy

On Tue, Jan 22, 2019 at 1:15 PM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Wim,

The subject draft was designed w/ NSH in mind.  We added an MPLS representation 
of the NSH later, which is the subject of the first draft you referenced, below.

The way the subject draft is written, the representation of the NSH  and the 
type of transport tunnel can change on a hop-by-hop basis at the discretion of 
the selected next-hop SFF.  This is through the use of the encapsulation 
attribute, which gives us a very open-ended framework in which to work.

I think the latter two drafts you referenced, below, are actually supported 
already but what needs to be written down is exactly what an SFF needs to 
advertise in the encapsulation attribute in order to support them.

I would be happy to work on this w/ anyone else who is interested.

Yours Irrespectively,

John

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Tuesday, January 22, 2019 12:00 PM
To: stephane.litkow...@orange.com; 
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

I need to get into more details, but the current draft is written with 
draft-ietf-mpls-sfc-04 dataplane in mind. I believe that the draft can be 
useful with other dataplanes like: draft-ietf-mpls-sfc-encapsulation and 
draft-guichard-spring-nsh-s
So