Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt

[Sami Boutros]

Hi Jeff,

I’m not aware of any known public deployed implementations.

Yes, we are ready for WGLC.

Thanks,

Sami
> On Nov 1, 2023, at 2:05 PM, Jeff Tantsura  wrote:
> 
> Sami and team,
> 
> Friendly reminder, would appreciate your response.
> 
> Given no changes between last couple of versions, are we ready to go towards 
> WGLC?
> 
> Thanks,
> Jeff  
> 
>> On May 27, 2023, at 3:20 AM, Jeff Tantsura  wrote:
>> 
>> Dear authors,
>> 
>> Are there any known implementations of the draft?
>> 
>> Thanks,
>> Jeff
>> 
>>> On May 27, 2023, at 1:48 AM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This Internet-Draft is a work item of the BGP Enabled ServiceS
>>> (BESS) WG of the IETF.
>>> 
>>> Title   : EVPN control plane for Geneve
>>> Authors : Sami Boutros
>>> Ali Sajassi
>>> John Drake
>>> Jorge Rabadan
>>> Sam Aldrin
>>> Filename: draft-ietf-bess-evpn-geneve-06.txt
>>> Pages   : 10
>>> Date: 2023-05-26
>>> 
>>> Abstract:
>>> This document describes how Ethernet VPN (EVPN) control plane can be
>>> used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
>>> Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
>>> solutions.
>>> 
>>> EVPN control plane can also be used by Network Virtualization Edges
>>> (NVEs) to express Geneve tunnel option TLV(s) supported in the
>>> transmission and/or reception of Geneve encapsulated data packets.
>>> 
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/
>>> 
>>> There is also an htmlized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-06
>>> 
>>> A diff from the previous version is available at:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-geneve-06
>>> 
>>> Internet-Drafts are also available by rsync at 
>>> rsync.ietf.org::internet-drafts
>>> 
>>> 
>>> ___
>>> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Please send slot request for BESS IETF 117

[Sami Boutros]

Hi Mankamana,

Can I get 5 to 10 mins to present an update on

draft-boutros-bess-elan-services-over-sr-04 


Thanks,

Sami

> On Jun 30, 2023, at 7:32 AM, Mankamana Mishra (mankamis) 
>  wrote:
> 
> All, 
> Primary agenda has been posted. Please send me slot request for IETF 117.
>  
> Mankamana  
> ___
> 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] Issues w/ draft-boutros-bess-elan-services-over-sr

[Sami Boutros]

Hi Ali,

The draft doesn’t state neither 1 or 2 below. I’m not sure if we are looking at 
the same draft.

Here is the text in the draft introduction

   The goal of the proposed approach is to greatly simplify control
   plane functions and minimize the amount of control plane messages PE
   nodes have to process.  In this version of the document, we assume
   Segment Routing (SR) underlay network.  A future version of this
   document will generalize the underlay network to both classical MPLS
   and SR technologies.

   The proposed approach does not require PW, and hence the control
   plane complexity and message overhead associated with signaling and
   maintaining PWs are eliminated.

Our goal is to simplify:

1- The control plane by signaling very few messages possibly 1 message per node 
to signal all ELAN services configured on that node, presenting each ELAN 
service as 1 bit in the control plane message.

2- The data plane by setting up much less control plane elements like PWs, 
tunnels etc., and more importantly leveraging SR redundancy mechanisms of any 
cast SID to remove the need of any overlay convergence or redundancy mechanisms.

Not sure if any the stuff u listed below can address any of the above!

Thanks,

Sami

> On Nov 19, 2020, at 12:21 PM, Ali Sajassi (sajassi) 
>  wrote:
> 
> Sami,
>  
> Since we didn’t have time to discuss the issues during the BESS meeting, let 
> me explain and elaborate them here:
>  
> The draft states the following two main objectives for its purpose but both 
> have been addressed already !!
>  
> Reducing # of PWs in VPLS:
> VPLS (both BGP and LDP) is a 20-year old technology which is getting 
> deprecated and many providers (SP, DC, and EN) are moving toward EVPN. 
> However, a few years after VPLS (about 15 years ago) we introduced PBB-VPLS 
> (RFCs 7041 and 7080) to address the PW scale issues along with few other 
> things.
> Reducing # of EVPN MAC route advertisements:
> This may have been an issue 10 years ago and that’s why we introduced 
> simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN 
> uses data-plane learning and it uses concepts of service-id, source B-MAC 
> (for MAC learning) and destination B-MAC (for BUM ID), and same concepts are 
> used in your draft. Furthermore RFC 7623 supports All-Active multi-homing as 
> well as Single-Active with all the improvements that came later including 
> per-ISID c-mac flushing that Jorge presented during the call. Needless to say 
> that PBB-EVPN is transport agnostic and can work with SR, MPLS, TE, etc.
>  
> So,  my question is that: what is the point of this draft? Are you trying to 
> have a bit more compressed header over what we currently have in PBB-EVPN 
> because in terms of functionality, I don’t see much difference. However, I 
> see even more issues than PBB-EVPN such as IRB handling  and Unequal 
> load-balancing  for an ES.
>  
> The idea of breaking a PW in to three components of service-id, source-id, 
> and dest-id has been around for almost twenty years. I introduced mvpls draft 
> in 2002, followed by PBB-VPLS. VxLAN RFC (which also talks about data-plane 
> learning) is along the same idea introduced in 2010. And finally PBB-EVPN in 
> 2012. So, why do we need to re-invent the wheel again?
>  
> -Ali
> ___
> 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] comments on draft-boutros-bess-elan-services-over-sr

[Sami Boutros]

Hi Jorge,


> On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
>  wrote:
> 
> Hi everyone,
>  
> Jeffrey, not sure how much of EVPN this solution is, since there are no 
> ‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
> are needed at all.
> But I see your point Jeffrey, and I agree the concept of the source 
> identification is not SR specific.

Agreed, source identification is not SR specific.

>  
> @Sami, 
>  
> I couldn’t speak during the meeting so I’ll throw a couple of general 
> comments/questions:
>  
> While I see the anycast-SID as an interesting point, I disagree with the 
> document’s motivation that EVPN needed to introduce control-plane learning 
> due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?

> Control plane learning has a lot of advantages and data-plane learning/aging 
> has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.

>  
> Irrespective, the anycast-SID idea could work in regular EVPN as an optional 
> alternative to aliasing. You don’t need to do data-plane learning for that, 
> right?

Agreed, any technology can use any cast SID.

> The document seems to claim fast mac move. How can that be guaranteed if the 
> mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.

>  
> ARP suppression is not a merit of this solution. It could work even in 
> RFC4761/74762 VPLS networks.
>  

Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented SR, it simply say it will use it this way, I hope 
this is OK.

>  

> I have a few more, but those are enough to start.

Thanks,

Sami
> Thank you!
> Jorge
>  
>  
> From: BESS 
> Date: Thursday, November 19, 2020 at 12:46 PM
> To: bess@ietf.org 
> Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
> 
> Hi,
> 
> It seems that the draft is about using data-plane mac learning in an 
> EVPN-like solution. That retains other properties of EVPN, but removes the 
> need for advertising MAC addresses, with the consequences/problems that Ali 
> was trying to point out.
> 
> Leaving the pros and cons of data plane mac learning out, I want to point out 
> that the idea is actually orthogonal with SR - even if SR were not invented 
> this concept still applies. With VXLAN the source address corresponds to the 
> "source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
> extended to other use cases) serves the same purpose. That same "PE 
> Distinguisher Label" concept is also used in my Generic Fragmentation 
> proposal.
> 
> With that, the discussion for this draft should be in BESS, not in SPRING.
> 
> Jeffrey
> 
> Juniper Business Use Only
> 
> ___
> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Sami Boutros]

Hi Jeff,


> On Nov 19, 2020, at 3:46 AM, Jeffrey (Zhaohui) Zhang 
>  wrote:
> 
> Hi,
> 
> It seems that the draft is about using data-plane mac learning in an 
> EVPN-like solution.


Actually the draft explicitly mention that we don’t need any EVPN routes, and 
not sure what EVPN-like solution you are referring too.

> That retains other properties of EVPN, but removes the need for advertising 
> MAC addresses, with the consequences/problems that Ali was trying to point 
> out.
> 

It will be good that you point out those specific consequences/problems.

> Leaving the pros and cons of data plane mac learning out, I want to point out 
> that the idea is actually orthogonal with SR - even if SR were not invented 
> this concept still applies.

Agreed, but SR enabled the concept, via the ability to define SRGB for services 
across the network.

> With VXLAN the source address corresponds to the "source node SID", and with 
> MPLS the "PE Distinguisher Label" in MVPN (and extended to other use cases) 
> serves the same purpose. That same "PE Distinguisher Label" concept is also 
> used in my Generic Fragmentation proposal.
> 
> With that, the discussion for this draft should be in BESS, not in SPRING.
> 

As I mentioned this is still about BGP enabled services, however we can still 
present this in SPRING.

Thanks,

Sami

> Jeffrey
> 
> Juniper Business Use Only
> 
> ___
> 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] IETF 109, call for slots

[Sami Boutros]

Hi Mankamana,

We need 15 mins slot to present
https://tools.ietf.org/html/draft-boutros-bess-elan-services-over-sr-00

Thanks,

Sami
> On Oct 23, 2020, at 9:22 PM, Mankamana Mishra (mankamis) 
>  wrote:
> 
> All, 
> Final agenda for IETF 109 is sent, please send me slot request if you want 
> any.  We would be meeting on Thursday of IETF week.
>  
> https://datatracker.ietf.org/meeting/109/agenda.html 
> 
>  
>  
> 16:00-18:00
> 
> Thursday Session III
> 
> Room 5
> 
> rtg
> 
> bess  
> BGP Enabled ServiceS
> 
>  
>  
>  
> Mankamana 
> ___
> BESS mailing list
> BESS@ietf.org 
> https://www.ietf.org/mailman/listinfo/bess 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[Sami Boutros]

Support,

Sami
Sent from my iPhone

> On Jan 21, 2020, at 6:48 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-brissette-bess-evpn-mh-pa-04 [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 Tuesday 4th February 2020.  
>  
> Regards,
> Matthew and Stephane
>  
> [1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-mh-pa/
>  
>  
>  
>  
>  
> ___
> 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 call & IPR poll for draft-jain-bess-evpn-lsp-ping

[Sami Boutros]

Support as a co-author, not aware of any IPR.

Thanks,

Sami
> On May 7, 2019, at 12:36 AM,  
>  wrote:
> 
> Hi,
>  
> This email begins a two-week poll for adoption of 
> draft-jain-bess-evpn-lsp-ping-08[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 21th May 2019.  
>  
> Regards,
> Stephane and Matthew
>  
> [1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/ 
> 
> _
> 
> 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] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[Sami Boutros]

Support, Please progress the document.



Thanks,



Sami



Hi WG,



draft-ietf-bess-nsh-bgp-controlplane has passed WGLC and its finishing the 
shepherd's review phasis (I-D update required). It is in a good shape to 
progress further. However we are not aware of any implementation. As per our 
Implementation Requirement Policy, we need to poll the WG to know if WG agrees 
to progress the document without implementation.



This email starts a 2 weeks poll closing on 04/18/2019.



Please raise your support or any concern regarding the progress of this 
document without implementation.

If you are aware of any implementation, please also state it.





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



Brgds,



Stephane & Matthew

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

Re: [bess] Slot requests for BESS WG session - IETF 103 - Bangkok

[Sami Boutros]

Hi,

I would like to get a 5 min slot for

Draft-Boutros-geneve-evpn-03

Thanks,

Sami

> On Oct 6, 2018, at 1:59 PM, Mankamana Mishra (mankamis)  
> wrote:
> 
> All,
>  
> It is time we start building the BESS WG agenda for IETF 103 Bangkok.
>  
> Please send us your request for a presentation slot , indicating draft name, 
> speaker, and desired duration (covering presentation and discussion). If it 
> is not the first presentation of the draft, please give a reason why it is 
> required to have a new presentation slot.
>  
>  
> Thank you
>  
> Mankamana , Stephane & Matthew
>  
> ___
> 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] AD Review of draft-ietf-bess-fat-pw-bgp-03

[Sami Boutros]

Hi Albaro,

Agreed with all comments, and we can change the “is requesting the ability” to 
“announce the ability”.

Do we need to submit a new draft with the changes?

Thanks,

Sami
From: Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>
Date: Friday, January 26, 2018 at 1:54 PM
To: 
"draft-ietf-bess-fat-pw-...@ietf.org<mailto:draft-ietf-bess-fat-pw-...@ietf.org>"
 
<draft-ietf-bess-fat-pw-...@ietf.org<mailto:draft-ietf-bess-fat-pw-...@ietf.org>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, Martin Vigoureux 
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>
Subject: AD Review of draft-ietf-bess-fat-pw-bgp-03
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <ke...@arrcus.com<mailto:ke...@arrcus.com>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jli...@cisco.com<mailto:jli...@cisco.com>>, 
<bin_...@cable.comcast.com<mailto:bin_...@cable.comcast.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Resent-Date: Friday, January 26, 2018 at 1:54 PM

Dear authors:

I just finished reading this document.  Thank you for a well written and 
straight forward document!!

I have some comments (see below) that I think are easy to address.  I am then 
starting the IETF Last Call.

Thanks!

Alvaro.


Major:

M1. All the rfc2119 keywords in this text should not be capitalized because 
they are part of an example:

   For example, a PE part of a VPLS and with a local T = 1,
   MUST only transmit traffic with a flow label to those peers that
   signaled R = 1.  And if the same PE has local R = 1, it MUST only
   expect to receive traffic with a flow label from peers with T = 1.
   Any other traffic MUST NOT have a flow label.


M2. Security Considerations: I agree that there are no new issues.  However, 
please also point to rfc4761 and any other document that defines the base 
functionality being modified here.


Minor:

P1. "This draft introduces an OPTIONAL mode of operation..."  There's no need 
for "OPTIONAL" to be Normative in this sentence since it is just describing 
what it is, not specifying behavior.  s/OPTIONAL/optional


P2. The new registry has a policy of "IETF Review", which basically means that 
any RFC (not just Standards Track RFCs) can use the bits in the registry.  I 
ask because there are only 4 bits left.  Note that I'm not asking you to 
necessarily change the policy...just pointing it out.


P3. "T   When the bit value is 1, the PE is requesting the ability..."  Did you 
mean "announce the ability" instead?


P4. s/NUST NOT/MUST NOT


P5. References:  I think these can be Informative: rfc4385, rfc8077, rfc4928
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Sami Boutros]

Support for adoption 

Sami

> On Sep 25, 2017, at 2:42 AM, Martin Vigoureux  
> wrote:
> 
> Hello working group,
> 
> This email starts a two-week call for adoption on 
> draft-drake-bess-datacenter-gateway-05 [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 2nd of October*.
> 
> 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 & Thomas
> bess chairs
> 
> [1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/
> 
> ___
> 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 Last Call for draft-ietf-bess-fat-pw-bgp

[Sami Boutros]

Hi Martin,

I'm not aware of any IPR.

Thanks,

Sami

> On Jun 12, 2017, at 9:27 AM, Martin Vigoureux  
> wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on draft-ietf-bess-fat-pw-bgp-02 
> [1] which is considered mature and ready for a final working group review.
> 
> ¤ Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *26th of June*.
> Note that this is *not only* a call for comments on the document; it is also 
> a call for support (or not) to publish this document as a Proposed Standard 
> RFC.
> 
> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that applies 
> to draft-ietf-bess-fat-pw-bgp, 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 of
> draft-ietf-bess-fat-pw-bgp-02 please respond to this email and indicate 
> whether or not you are aware of any relevant IPR.
> 
> Note that, as of today, no IPR has been disclosed against this document or 
> its earlier versions.
> 
> ¤ We are also polling for knowledge of implementations of part or all of what 
> this document specifies. This information is expected as per [2]. Please 
> inform the mailing list, or the chairs, or only one of the chairs.
> 
> 
> Thank you,
> M
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
> ___
> 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] WG adoption for draft-boutros-bess-evpn-vpws-service-edge-gateway-03

[Sami Boutros]

Hi Martin and Thomas,

We would like to ask for WG adoption for this draft, as there are vendor 
planned implementations for it.

Thanks,

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

Re: [bess] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

[Sami Boutros]

Support .

Thanks,

Sami

> On Apr 17, 2017, at 5:31 AM, UTTARO, JAMES  wrote:
> 
> Support
>  
> Jim Uttaro
>  
> From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of luay.ja...@verizon.com
> Sent: Saturday, April 15, 2017 3:49 AM
> To: BESS 
> Cc: s...@ietf.org
> Subject: Re: [sfc] Extra time to reflect on 
> draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure
>  
> Support
>  
>  
> Luay
>  
> From: sfc  on behalf of Martin Vigoureux 
> 
> Reply-To: BESS 
> Date: Thursday, April 13, 2017 at 1:04 PM
> To: BESS 
> Cc: "s...@ietf.org" 
> Subject: [sfc] Extra time to reflect on 
> draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure
>  
> WG
>  
> Given the IPR disclosed [1] against
> draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for
> comment specifically to let people express a revised opinion on how
> draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS.
>  
> This call for comment is open until the 5th of May
>  
> Thanks
> M
>  
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2980_=DwIFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY=qN2VxBfuDQTHb9spUcOb6U-0QhNArhH4-TqX_aTjyaw=4VuflmQibSX6JGcRHsfv4SgtIIMuNUzVFEdMMccItP8=
>  
> ___
> sfc mailing list
> s...@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc=DwIFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY=qN2VxBfuDQTHb9spUcOb6U-0QhNArhH4-TqX_aTjyaw=u3C3H2GPfolNL2O1q7-SoUfZRNFXGGqXbUo471yGMkU=
>  
> ___
> 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 for draft-boutros-bess-vxlan-evpn-02.txt

[Sami Boutros]

Hi Thomas,

Can we please ask for a WG adoption for the above draft?

Thanks,

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

Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT)

[Sami Boutros]

Hi,

Here is the text updated, please let me know if this looks good.

"The MPLS label value in the Ethernet A-D route can be set to the VXLAN Network 
Identifier (VNI) for VXLAN encap as per [RFC7348], and this VNI will have a 
local scope per PE and may also be equal to the VPWS service instance 
identifier set in the Ethernet A-D route.”

Will add a Normative reference to RFC7348.

I can add as well the following:

"When using VXLAN encap, the BGP Encapsulation extended community defined in 
[draft-ietf-idr-tunnel-encaps] and [RFC5512] is included in the Ethernet A-D 
route."

And add  a Normative reference to [RFC5512] and Informative to the 
tunnel-encaps.

Thanks,

Sami



On 4/12/17, 1:19 PM, "John E Drake" <jdr...@juniper.net> wrote:

>Sami,
>
>I don't think we want to use a global VNI because if we do we will be limited 
>to one circuit per global VNI due to the fact that we demux traffic strictly 
>using the label value and not the MAC address.
>
>Yours Irrespectively,
>
>John
>
>
>> -Original Message-
>> From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
>> Sent: Wednesday, April 12, 2017 3:49 PM
>> To: Sami Boutros <sbout...@vmware.com>; Alia Atlas <akat...@gmail.com>;
>> The IESG <i...@ietf.org>
>> Cc: draft-ietf-bess-evpn-v...@ietf.org; Jeffrey (Zhaohui) Zhang
>> <zzh...@juniper.net>; bess-cha...@ietf.org; bess@ietf.org
>> Subject: Re: Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with 
>> DISCUSS
>> and COMMENT)
>> 
>> Sami:
>> 
>> Hi!
>> 
>> Let’s go ahead and add the text to explain the operation with VXLAN – I think
>> that the reference to rfc7348 should be Normative.
>> 
>> I’ll take care of dealing with the downref when we’re ready with the new 
>> text.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> 
>> 
>> 
>> 
>> 
>> On 4/12/17, 2:14 PM, "Sami Boutros" <sbout...@vmware.com> wrote:
>> 
>> Hi Alia,
>> 
>> Please see comments inline.
>> 
>> 
>> On 4/11/17, 4:43 PM, "Alia Atlas" <akat...@gmail.com> wrote:
>> 
>> >Alia Atlas has entered the following ballot position for
>> >draft-ietf-bess-evpn-vpws-11: Discuss
>> >
>> >When responding, please keep the subject line intact and reply to all
>> >email addresses included in the To and CC lines. (Feel free to cut this
>> >introductory paragraph, however.)
>> >
>> >
>> >Please refer to
>> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_
>> >statement_discuss-
>> 2Dcriteria.html=DwICaQ=uilaK90D4TOVoH58JNXRgQ=I
>> >VzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-
>> rljSFAaM5b76_QaDS
>> >Tz2BD_8ny0Dxcf4sM=s8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I
>> =
>> >for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> >The document, along with other ballot positions, can be found here:
>> >https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.o
>> >rg_doc_draft-2Dietf-2Dbess-2Devpn-
>> 2Dvpws_=DwICaQ=uilaK90D4TOVoH58JN
>> >XRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-
>> rljSFAaM5
>> >b76_QaDSTz2BD_8ny0Dxcf4sM=MlJKXisQTr1aheS8hahty-
>> iFDOCS_GhM37X2lMUAH54
>> >=
>> >
>> >
>> >
>> >--
>> >DISCUSS:
>> >--
>> >
>> >First, thank you for a clearly written document that contained enough
>> >context to trigger my hazy memory of some of the technical details.
>> >
>> >My concern is around this paragraph in the Introduction:
>> >
>> >"The MPLS label value in the Ethernet A-D route can be set to the
>> >   VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may
>> >have
>> >   a global scope or local scope per PE and may also be equal to the
>> >   VPWS service instance identifier set in the Ethernet A-D route.
>> >"
>> >
>> >First, I recognize that folks have implemented and deployed EVPN with
>> >VXLAN.
>> >That's fine.  There is an ISE RFC 7348 that describes VXLAN.   Depending
>> >on what
>> >you (authors, shepherd, AD, WG) decide to do about the rest of my
>> >concern, it is likely that this should be normative references - which
>> >would be a downref.
>> 
>> I can add the 7348 as a normative 

Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT)

[Sami Boutros]

Hi Alia,

Please see comments inline.


On 4/11/17, 4:43 PM, "Alia Atlas"  wrote:

>Alia Atlas has entered the following ballot position for
>draft-ietf-bess-evpn-vpws-11: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=uilaK90D4TOVoH58JNXRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-rljSFAaM5b76_QaDSTz2BD_8ny0Dxcf4sM=s8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I=
> 
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dvpws_=DwICaQ=uilaK90D4TOVoH58JNXRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-rljSFAaM5b76_QaDSTz2BD_8ny0Dxcf4sM=MlJKXisQTr1aheS8hahty-iFDOCS_GhM37X2lMUAH54=
> 
>
>
>
>--
>DISCUSS:
>--
>
>First, thank you for a clearly written document that contained enough
>context to trigger my hazy
>memory of some of the technical details.
>
>My concern is around this paragraph in the Introduction:
>
>"The MPLS label value in the Ethernet A-D route can be set to the
>   VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may
>have
>   a global scope or local scope per PE and may also be equal to the
>   VPWS service instance identifier set in the Ethernet A-D route.
>"
>
>First, I recognize that folks have implemented and deployed EVPN with
>VXLAN.
>That's fine.  There is an ISE RFC 7348 that describes VXLAN.   Depending
>on what
>you (authors, shepherd, AD, WG) decide to do about the rest of my
>concern, it is
>likely that this should be normative references - which would be a
>downref.

I can add the 7348 as a normative reference.

>
>Second, the paragraph here isn't really adequate to describe how to
>implement the
>functionality.   I don't see how:
>a) The ingress PE decides which VNIs it can send based upon the
>VNI=MPLS_label
>from the egress.   Is there an assumption that VXLAN allows
>sending all VNIs across
>the particular VPWS, whether port-based, VLAN-based, etc?

We are signaling Ethernet A-D route per VPWS instance, and in there we will 
signal 
VNI instead of an MPLS label for VxLAN encap.

>b) Is there an assumption that the egress PE-advertised MPLS label
>also indicates the
> VNI to be used?  

EVPN can work with different encapsulations a BGP Tunnel Encapsulation 
Attribute 
That specifies the tunnel type will be added to the Ethernet A-D route.


>That seems like another mode, like the
>VLAN-based service, except
> it is perhaps VNI + VLAN-based service?

The draft lists clearly the different service interface types, and there will 
be only one VNI per VPWS instance wether this is Vlan or port based.

>
>Please don't take this Discuss as a reason to remove the paragraph and
>the implied functionality.
>If it's implemented and deployed (and I think it is) - then what I really
>want is to just have it
>adequately written down so that others can interoperably implement.  The
>downref to VXLAN
>should just be a matter of process nuisance (i.e. another IETF Last Call
>and handling any concerns).
>

Should I add the 7348 as a normative reference?



>
>--
>COMMENT:
>--
>
>1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or
>"This specification" or...

Will fix.
>
>2) Sec 3.1:  "C  If set to 1, a Control word [RFC4448] MUST be
>present when sending EVPN packets to this PE."
>   Given discussions with IEEE about real MACs starting with 4 and 6 in
>top nibble, adding a statement about it being BCP to include
>   the control word (unless using Entropy Label) would be a good idea.
>
Could you suggest some text? 

Should I submit -12 with the changes?

Thanks,

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

Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Sami Boutros]

Hi Jorge,

The issue I see with ignoring the routes with P and B Flags clear is the 
following:

What if a PE advertised P or B Flag set then decide to send P and B Flags 
clear, what should we do in that case?

Ignore the P and B Flags clear route and keep the old P or B Flag set route, 
wouldn’t that be incorrect?

Thanks,

Sami


On 3/13/17, 6:04 AM, "Rabadan, Jorge (Nokia - US)" <jorge.raba...@nokia.com> 
wrote:

>Sami, 
>
>About this one:
>
>“  1. Why is receiving an extended community with both the P and B flags
>set treated as a withdrawal, while it is ignored for the case when both
>the P and B flags are clear?
>
>I agree both should be treated as a withdrawal, I will change the text.”
>
>
>[JORGE] Sami, please correct this:
>
>“If the PE receives a route with both B and P
>   clear, it MUST treat the route as a withdrawal from the sender PE.”
>
>As you have in the following paragraph, flags P=B=0 is perfectly valid:
>
>“In multihoming single-active scenario for a given VPWS service
>   instance, the DF election should result in the Primary-elected PE for
>   the VPWS service instance advertising the P Flag set and the B Flag
>   clear, the Backup elected PE should advertise the P Flag clear and
>   the B Flag set, and the rest of the PEs in the same ES should signal
>   both P and B Flags clear.”
>
>
>Let me know if I’m missing something please. Don’t want to hold the progress, 
>but this is important.
>Thank you.
>Jorge
>
>
>
>On 3/12/17, 8:24 PM, "Sami Boutros" <sbout...@vmware.com> wrote:
>
>Hi Acee,
>
>Please find attached document with all comments addresses, if all good 
> will 
>Submit before the cut-off tomorrow.
>
>Please see comments inline.
>On 3/12/17, 11:36 AM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>
>
>>Hi Sami, 
>>
>>I think this version reads much better. I still have a couple comments and
>>questions. 
>>
>>  1. Why is receiving an extended community with both the P and B flags
>>set treated as a withdrawal, while it is ignored for the case when both
>>the P and B flags are clear?
>
>I agree both should be treated as a withdrawal, I will change the text.
>
>>  2. A related question is if a route with both the P and B flags clear is
>>ignored, won’t this break DF election described on the bottom of page 8?
>>It says “the rest of the PEs in the same ES should single both the P and B
>>Flags clear.”
>
>The DF election is between the PE(s) attached to the ES and has nothing to 
> do 
>With the remote PE receiving the routes from the PE(s) attached to the ES.
>The remote PE expect to receive one route with P Flag set and another 
> route 
>With with B flag set from another PE, all other routes received from other 
> PE(s) 
>Attached to the same ES are not needed, and hence can be treated as 
> withdrawal
>Of previous routes from those Pe(s). 
>
>> 
>>  3. Also, during DF election, is it implementation specific which backup
>>is chosen if multiple PEs advertise the B Flag set in their respective
>>extended communities?
>
>The DF election MUST always result in one Backup and One primary, however 
>During transit more than one route with P or B Flags can be received.
>
>>Why isn’t it the last one similar to the primary PE
>>selection?
>
>Ok, to be consistent, will change the text to have the remote PE select 
> the 
>last advertising backup PE.
>
>> 
>>  4. Both VID and VLAN ID are used in the document. I didn’t research this
>>but from the context it appears these are synonymous. If VID is used, I’d
>>also add it to the “Terminology” in 1.1.
>
>Ok.
>>
>>  A few more Nits:
>>*** draft-ietf-bess-evpn-vpws-11.txt.orig 2017-03-12 13:56:46.0
>>-0400
>>--- draft-ietf-bess-evpn-vpws-11.txt  2017-03-12 14:34:06.0 
> -0400
>>***
>>*** 153,163 
>> instance. As with the Ethernet Tag in standard EVPN, the VPWS service
>> instance identifier has uniqueness within an EVPN instance.
>>  
>>!For EVPN routes, the Ethernet Tag ID are set to zero for Port-based,
>>!VLAN-based, and VLAN-bundle interface mode and it is set to non-zero
>>!Ethernet tag ID for VLAN-aware bundle mode. Conversely, for EVPN-
>> VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a
>>!no

Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Sami Boutros]

ot available in VPWS. This can be done by the primary PE (on local
> AC down) using the label advertised in the per-EVI Ethernet A-D route
>!by the backup PE to encapsulate the traffic and direct it to the
>backup
> PE.
>  
>  6 Failure Scenarios
>***
>*** 592,600 
> For a faster convergence in multi-homed scenarios with either Single-
> Active Redundancy or All-active redundancy, a mass withdraw technique
> is used. A PE previously advertising a per-ES Ethernet A-D route, can
>!withdraw this route signaling to the remote PEs to switch all the
> VPWS service instances associated with this multi-homed ES to the
>!backup PE
>  
>  7 Acknowledgements
>  
>--- 592,600 
> For a faster convergence in multi-homed scenarios with either Single-
> Active Redundancy or All-active redundancy, a mass withdraw technique
> is used. A PE previously advertising a per-ES Ethernet A-D route, can
>!withdraw this route by signaling to the remote PEs to switch all the
> VPWS service instances associated with this multi-homed ES to the
>!backup PE.
>  
>  7 Acknowledgements

Thanks,

Sami
>
 



INTERNET-DRAFT  Sami Boutros
Intended Status: Standard Track   VMware
 Ali Sajassi
 Samer Salam
   Cisco Systems
  John Drake
Juniper Networks
  J. Rabadan
   Nokia

Expires: September 13, 2017   March 12, 2017


 VPWS support in EVPN 
   draft-ietf-bess-evpn-vpws-11.txt 

Abstract

   This document describes how EVPN can be used to support Virtual
   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
   following characteristics for VPWS: single-active as well as all-
   active multi-homing with flow-based load-balancing, eliminates the
   need for traditional way of Pseudowire (PW) signaling, and provides
   fast protection convergence upon node or link failure.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice
 


BoutrosExpires September 13, 2017   [Page 1]

INTERNET DRAFTVPWS support in EVPNMarch 12, 2017


   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2 Service interface  . . . . . . . . . . . . . . . . . . . . . . .  5
 2.1 VLAN-Based Service Interface . . . . . . . . . . . . . . . .  5
 2.2 VLAN Bundle Service Interface  . . . . . . . . . . . . . . .  6
   2.2.1 Port-Based Service Interface . . . . . . . . . . . . . .  6
 2.3 VLAN-Aware Bundle Service Interface  . . . . . . . . . . . .  6
   3. BGP Extensions  . . . . . . . . . . . . . . . . . . . . . . . .  6
 3.1 EVPN Layer 2 attributes extended community . . . . . . . . .  7
   4 Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5 EVPN Comparison to PW Signaling  . . . . . . . 

Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

[Sami Boutros]

bel will identify the VPWS service instance and if translation is
>
> needed, it should be done by the Ethernet interface for each service.
>
>  
>
>!For single-homed CE, in an advertised per EVI Ethernet A-D route the
>
> ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS
>
> service instance identifier that identifies the EVPL or EPL service.
>
>  
>
>!For a multi-homed CE, in an advertised per EVI Ethernet A-D route the
>
> ESI field is set to the CE's ESI and the Ethernet Tag ID is set to
>
> the VPWS service instance identifier, which MUST have the same value
>
> on all PEs attached to that ES. This allows an ingress PE in a
>
>--- 511,521 
>
> label will identify the VPWS service instance and if translation is
>
> needed, it should be done by the Ethernet interface for each service.
>
>  
>
>!For single-homed CE, in an advertised per-EVI Ethernet A-D route the
>
> ESI field is set to 0 and the Ethernet Tag ID is set to the VPWS
>
> service instance identifier that identifies the EVPL or EPL service.
>
>  
>
>!For a multi-homed CE, in an advertised per-EVI Ethernet A-D route the
>
> ESI field is set to the CE's ESI and the Ethernet Tag ID is set to
>
> the VPWS service instance identifier, which MUST have the same value
>
> on all PEs attached to that ES. This allows an ingress PE in a
>
>***
>
>*** 523,535 
>
> traffic follows the transport paths, which may be asymmetric.
>
>  
>
> The VPWS service instance identifier encoded in the Ethernet Tag ID
>
>!in an advertised per EVI Ethernet A-D route MUST either be unique
>
> across all ASs, or an ASBR needs to perform a translation when the
>
>!per EVI Ethernet A-D route is re-advertised by the ASBR from one AS
>
> to the other AS.
>
>  
>
>!Per ES Ethernet A-D route can be used for mass withdraw to withdraw
>
>!all per EVI Ethernet A-D routes associated with the multi-home site
>
> on a given PE.
>
>  
>
>  
>
>--- 524,536 
>
> traffic follows the transport paths, which may be asymmetric.
>
>  
>
> The VPWS service instance identifier encoded in the Ethernet Tag ID
>
>!advertised in a per-EVI Ethernet A-D route MUST either be unique
>
> across all ASs, or an ASBR needs to perform a translation when the
>
>!per-EVI Ethernet A-D route is re-advertised by the ASBR from one AS
>
> to the other AS.
>
>  
>
>!A per-ES Ethernet A-D route can be used for mass withdraw to withdraw
>
>!all per-EVI Ethernet A-D routes associated with the multi-homed site
>
> on a given PE.
>
>  
>
>  
>
>***
>
>*** 540,551 
>
> signaling is done via LDP and service endpoint discovery is either
>
> through manual provisioning or through BGP.
>
>  
>
>!In existing implementation of VPWS using pseudowires(PWs), redundancy
>
> is limited to single-active mode, while with EVPN implementation of
>
> VPWS both single-active and all-active redundancy modes can be
>
> supported.
>
>  
>
>!In existing implementation with PWs, backup PWs are not used to carry
>
> traffic, while with EVPN, traffic can be load-balanced among
>
> different PEs multi-homed to a single CE.
>
>  
>
>--- 541,552 
>
> signaling is done via LDP and service endpoint discovery is either
>
> through manual provisioning or through BGP.
>
>  
>
>!In existing implementations of VPWS using pseudowires(PWs), redundancy
>
> is limited to single-active mode, while with EVPN implementation of
>
> VPWS both single-active and all-active redundancy modes can be
>
> supported.
>
>  
>
>!In existing implementations with PWs, backup PWs are not used to carry
>
> traffic, while with EVPN, traffic can be load-balanced among
>
> different PEs multi-homed to a single CE.
>
>  
>
>***
>
>*** 566,572 
>
>  
>
> Finally, EVPN may employ data plane egress link protection mechanisms
>
> not available in VPWS. This can be done by the primary PE (on local
>
>!AC down) using the label advertised in the per EVI Ethernet A-D route
>
> by the backup PE to encapsulate the traffic and direct it to backup
>
> PE.
>
>  
>
>--- 567,573 
>
>  
>
> Finally, EVPN may employ data plane egress link protection mechanisms
>
> not available in VPWS. This can be done by the primary PE (on local
>
>!AC down) u

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,

Please see comments inline.



Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
   Port-based, vlan-based, and vlan-bundle interface mode and it is set
   to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
   for all the four interface modes, Ethernet tag ID in the Ethernet A-D
   route MUST be set to a non-zero value in all the service interface
   types.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.


[Sami] We are defining new interface types in other drafts, so we can’t say in 
the above text
For all a service interface types for example, honestly I am not in favor to 
change the text.

2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true).

[Sami] This is not what the text is indicating.

For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2.

[Sami] This is simply not possible, since the source of traffic on the ES is 
one for both PE1 and PE2.

I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

[Sami] I will add to the above text, on different PE (s) and different ES (es) 
instead of different PE (s)

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1


[Sami] Sure will fix.

4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

[Sami] Ok I will add that this is for all-active.


Thanks,

Sami


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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi John,

I can add that the value is from 0 to 0x00ff, will that work?


Thanks,

Sami
On 2/21/17, 10:56 AM, "John E Drake"  wrote:

>Sami,
>
>Snipped, comment inline
>
>Yours Irrespectively,
>
>John
>
>> >
>> >> Ethernet Tag ID 32-bit field MUST be set to the 24-bit VPWS service 
>> >> instance
>> identifier value."
>> >
>> >
>> >
>> >Ok, but you still didn’t mention how the 24-bit value is to be aligned in 
>> >the 32-
>> bit field.  I’m guessing there will be some 0-padding, but will that the at 
>> the
>> beginning or the end?
>> >
>> 
>> I made the VPWS service instance identifier a 32-bit value in the new draft.
>> 
>
>[JD]   I don't think you can do this as there are multiple implementations 
>that use 24 bits  
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

How about this?


In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, as result of DF election, the Primary elected PE for the VPWS 
service instance should signal P=1,B=0, the Backup elected PE should signal 
P=0,B=1, and the rest of the PEs in the same ES should signal P=0,B=0. When the 
primary PE/ES fails, the primary PE will withdraw the associated Ethernet A-D 
routes for the VPWS service instance from the remote PE, the remote PEs should 
then send traffic associated with the VPWS instance to the backup PE.

DF re-election will happen between the PE(s) in the same ES, and there will be 
a new elected primary PE and new elected backup PE that will signal the P and B 
bits as described. A remote PE SHOULD receive P=1 from only one Primary PE and 
a B-1 from only one Backup PE. However during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:53 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I recommend using Jorge’s text. That says, what originating multi-homed PEs 
should behave in single-active case.
That along with the text below (on how remote should behave) will help.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:46 PM
To: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07



From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>; Shah, 
Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>; Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but only one PE should signal 
B=1 at the time. Since there may be transient windows where the remote PE gets 
2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a 
normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest 
of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, 
the remote PEs will immediately send to the backup. In the meantime, there is a 
DF reelection, and there will be a new primary and new backup that will signal 
the bits as per the above. The remote PE will always send to the primary first 
and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" 
<sbout...@vmware.com<mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-ev

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,


From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding

[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

[Sami] But wouldn’t the text highlighted here clarify the text above, that only 
one Backup should be selected.

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

[Sami] Why the limitation? Any reason? For PW redundancy we do support too 
multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

[Sami] DF election is intentionally not in scope, not to redefine any 
mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>; Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:dr

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

We can have a phone call to go over this, if you like, I will send you my 
availability in contact in a private e-mail.
From: Iftekhar Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Date: Wednesday, February 8, 2017 at 10:45 AM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>
Cc: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami,

To make my comments clear (in case it didn’t come through earlier emails), I am 
summarizing my comments again.

1.   Clearly identify the role of AC and ES for point-to-point services

Sami: We clearly say the following: "Ethernet Virtual Private Line (EVPL) 
service as p2p service between a pair of ACs (designated by VLANs) and Ethernet 
Private Line (EPL) service, in which all traffic flows are between a single 
pair of ports, that in EVPN terminology would mean a single pair of Ethernet 
Segments ES(es).”
But I think you don’t find that clear, so can you propose some text that will 
make it clear?


2.   Clearly identify and document the reference model for the 
point-to-point services. For example, here is what I believe the model should 
look like.


[cid:image002.png@01D281F8.6434A550]

Sami: We have a already a reference model similar to PWE3 in the doc, in 
section 4. Not sure what the above will do, and does PWE3 have the above? If 
you need the above to define some YANG data model, I would recommend adding it 
to the YANG data model draft!



3.   Define an entity to toward PSN – see the picture above. Like I said 
earlier, if we don’t fix it now, it is only get worse/confusing as other 
extensions are added.

Sami: Can you propose some text for that? That will make it clear for you 
different than what we already added.
"VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.”



4.   I would reiterate again – please summarize the functionality of 
RFC7432 that applies to point-to-point services and which does not.  Users who 
are only interested in point-to-point services, could use this document to 
implement it without getting drowned information which is not relevant in such 
scenarios. Point-to-point services should be treated as services in their own 
wright – rather than after thought or extension of multipoint services.


Sami: And, I will repeat again, through out the document we are only talking 
about only E-AD routes, which is used by EVPN-VPWS service, and when we talk 
about redundancy we refer to the EVPN base for single-active and active-active, 
not sure what else do you want us to say? As I said we don’t agree to list what 
we don’t support from EVPN, since the list can’t predict what future extensions 
will be added to EVPN.

Thanks,

Sami

Hope this makes it clear the type of updates I am looking for.

Thanks,
Iftekhar

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,


The management entity you are looking for is the evpn VPWS service instance, 
fxc can map more than one AC to this. I will add a definition in the doc to 
this evpn VPWS instance and mention that only one AC can be xconnected to it. 
Will that be ok?

[Iftekhar2] An issue pointed earlier that I see with the current solution is 
that there is no per service level entity for statistic counters on the PSN 
side. The LSP provides aggregate counters for all the services carried on that 
LSP.

[Sami] The EVPN-VPWS LSP here carries only one service not multiple servcies. 
Here is what I added. I hope this will be good enough.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more 
clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can 
definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition 
below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we 
will include it, however there are other drafts extending DF election like 
rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup 
PE
(i.e. which backup PE?).

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will 
select only one backup PE."

If there are multiple primary PEs, and if one of them fail, why not switchover 
to other
primary PE, so on and so forth..

[Sami] In single active there should be only one primary, having more than one 
primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, 
or A/S in which only one primary and one backup.

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

[Sami] We are not redefining what single active or all active mean, this is as 
per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the
  PEs attached to an Ethernet segment, is allowed to forward traffic
  to/from that Ethernet segment for a given VLAN, then the Ethernet
  segment is defined to be operating in Single-Active redundancy
  mode.


I.e. One primary and one/multiple backup.


   All-Active Redundancy Mode: When all PEs attached to an Ethernet
  segment are allowed to forward known unicast traffic to/from that
  Ethernet segment for a given VLAN, then the Ethernet segment is
  defined to be operating in All-Active redundancy mode.

 I.e. Multiple Primary


Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the 
parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm 
would work better?

[Sami] Again, we are not redefining EVPN multihoming or DF election, those are 
following base EVPN.

Thanks,

Sami

Thanks,
Himanshu

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; 
Iftekhar Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

Please see inline
> 
>  
> Hi Authors,
>  
> I support this work. However, I do have few comments that I would like to add 
> to the list from the AD:
> · Section 1:  The terms ES and ACs are used interchangeably (e.g., 
> see “….Ethernet Virtual Private Line (EVPL) service as p2p service between a 
> pair of ACs” and “…Ethernet Private Line (EPL) service … a single pair of 
> ESes” .  This is confusing. What is the reason for not considering a port as 
> an AC?
> Suggestion: Please include a complete service entity reference mode in this 
> draft. Clearly indicate what entities are involved to provision a VPWS (for 
> example, ES-AC - LSP etc.). This will also be extremely useful for data 
> modeling of the service.
> Sami: I am not sure I get this, we spend a lot of time on this on the list to 
> conclude to the text in Place for ES and AC. I am not sure changing any of 
> that will clarify or confuse.
>  
> Iftekhar:  I am not saying you didn’t spend enough time. What I am saying is 
> at least to me the equivalence of AC and ES is not clear. Are you saying AC 
> == ES?  As I understand, these two constructs are not equivalent. AC is a 
> data plane construct while ES appears to be purely a control plane construct. 
> Okay for the sake of argument, say ES and AC are equivalent. Then why do you 
> need AC? Moreover, what will be the data plane entity representation of 
> VPWS-EVPN  for EVPL and EPL look like? Would it be AC- (xconnect) label – LSP 
> or ES- (xconnect) – LSP?

If you have a look at the terminology section it clarifies what exactly we mean 
by ES in the doc it refers to the link/port attached to the PE and we refer to 
AC as the VLAN like port. Like Pwe3 the evpn p2p lsp can be looked at as a Pw 
construct. By the way AC is both a data and control plane construct. We are not 
redefining what EVPL or EPL means but on a given PE we are cross connecting a 
port or a VLAN like service to an evpn signaled p2p bidir lsp using evpn-vpws.

>  
> · Section 1: “…whereas, for more general VPWS,…”  What is a more 
> general VPWS?
>  
> Sami: Please refer to https://tools.ietf.org/html/rfc4664 for the general 
> VPWS definition. I will add a reference to it in the doc.
>  
> Iftekhar: Okay.
>  
> · Section 1: It is hard to keep track of what enhancements are being 
> proposed and what functionalities defined in RFC7432 applies or don’t apply 
> to VPWS.
>  
> Sami: The only change is making the Ethernet tag ID setting to a non zero 
> value a MUST, this is explicitly mentioned in section 1
>  
> "Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for 
> Port-based, vlan-based, and vlan-bundle interface mode and it is set to 
> non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, for all 
> the four interface modes, Ethernet tag ID in the Ethernet A-D route MUST be 
> set to a non-zero value in all the service interface types."
>  
> Iftekhar: Let me give couple of examples. Does (a) MAC/IP route (type2) or 
> Inclusive Multicast Ethernet Tag route (type 3) (b) MAC Mobility Extended 
> Community or  Default Gateway Extended Community  defined in RFC7432 apply to 
> EVPN-VPWS?  If not, it would be useful that this document clarifies it.


The document clearly mention that there is no Mac related routes, or bridge 
like service related routes not sure what more clarifications we need. 
Enumerating route types and extended communities not supported doesn't make 
sense given that EVPN is still adding more route types and more extended 
communities in several drafts not only the base.

>  
> Suggestion: Add a summary table which captures what Route Types apply (or 
> don’t apply) to VPWS
>  
> Sami: The only route that applies is the ethernet A-D route and we need 
> segment route for multihoming. None of the other routes apply!
>  
> · Section 5: What is equivalent of PW in EVPN-VPW case? In the 
> service model, is there any entity that need to be modeled? I see that in the 
> https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpws-fxc-01 you are 
> introducing a new entity on the PSN side called “VPWS Service Tunnel … a pair 
> of EVPN service labels associated with a pair of endpoints”. What is 
> difference between labels associated with a pair of VPWS endpoints in this 
> draft vs vpws-fxc draft?
> Sami: I don;t think we can explain the fxc draft in this draft, however in 
> the fxc the label is not sufficient to identify the service.
>  
> Iftekhar: Let me ask a very simple question. Suppose I am interested in 
> statistic counters on packet received or transmitted toward PSN/from PSN for 
> a VPWS-EVPN. In the VPWS (RFC4664) there is PW entity.  Could you kindly 
> identify an entity against which such counters can be shown and retrieved? 
> All  VPWS-EVPN draft has is a “label”.
>  

The PW entity is as well identified by 2 labels for imposition and disposition, 
the same way an evpn p2p lsp for vpws is identified.

> I 

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

Please see comments inline.

From: Iftekhar Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Date: Thursday, January 26, 2017 at 2:44 PM
To: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<ssa...@cisco.com<mailto:ssa...@cisco.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<d...@steinbergnet.net<mailto:d...@steinbergnet.net>>, 
<thomas.beckh...@telekom.de<mailto:thomas.beckh...@telekom.de>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jefft...@gmail.com<mailto:jefft...@gmail.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Resent-Date: Thursday, January 26, 2017 at 2:44 PM

Hi Authors,

I support this work. However, I do have few comments that I would like to add 
to the list from the AD:

· Section 1:  The terms ES and ACs are used interchangeably (e.g., see 
“….Ethernet Virtual Private Line (EVPL) service as p2p service between a pair 
of ACs” and “…Ethernet Private Line (EPL) service … a single pair of ESes” .  
This is confusing. What is the reason for not considering a port as an AC?

Suggestion: Please include a complete service entity reference mode in this 
draft. Clearly indicate what entities are involved to provision a VPWS (for 
example, ES-AC - LSP etc.). This will also be extremely useful for data 
modeling of the service.

Sami: I am not sure I get this, we spend a lot of time on this on the list to 
conclude to the text in Place for ES and AC. I am not sure changing any of that 
will clarify or confuse.


· Section 1: “…whereas, for more general VPWS,…”  What is a more 
general VPWS?

Sami: Please refer to https://tools.ietf.org/html/rfc4664 for the general VPWS 
definition. I will add a reference to it in the doc.


· Section 1: It is hard to keep track of what enhancements are being 
proposed and what functionalities defined in RFC7432 applies or don’t apply to 
VPWS.

Sami: The only change is making the Ethernet tag ID setting to a non zero value 
a MUST, this is explicitly mentioned in section 1

"Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for 
Port-based, vlan-based, and vlan-bundle interface mode and it is set to 
non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, for all the 
four interface modes, Ethernet tag ID in the Ethernet A-D route MUST be set to 
a non-zero value in all the service interface types."



Suggestion: Add a summary table which captures what Route Types apply (or don’t 
apply) to VPWS

Sami: The only route that applies is the ethernet A-D route and we need segment 
route for multihoming. None of the other routes apply!


· Section 5: What is equivalent of PW in EVPN-VPW case? In the service 
model, is there any entity that need to be modeled? I see that in the 
https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpws-fxc-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dvpws-2Dfxc-2D01=DwMGaQ=uilaK90D4TOVoH58JNXRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=HcUojq-BETlXVyoybL6fXvPLI8qFDvFHnbLsuHVNeew=S9UX7kIkRIvJs6_-bWMXPlhhP-3rSRpJYb8DSuaUdJo=>
 you are introducing a new entity on the PSN side called “VPWS Service Tunnel … 
a pair of EVPN service labels associated with a pair of endpoints”. What is 
difference between labels associated with a pair of VPWS endpoints in this 
draft vs vpws-fxc draft?

Sami: I don;t think we can explain the fxc draft in this draft, however in the 
fxc the label is not sufficient to identify the service.

Thanks,

Sami

Suggestion: Clearly identify entity that needs to be modeled on the PSN side. 
If it is service tunnel, please indicate so. If this aspect is not addressed 
properly, IMHO, this will cause lot of confusion.

Thanks,
Iftekhar
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, January 25, 2017 8:39 PM
To: 
draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>
Cc: Jeffrey Zhang; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] AD R

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Alvaro,

Thanks for your review. Please have a look at attached draft w/ most of the 
comments addressed.

Please see comments inline Sami:

Thanks,

Sami
From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>
Date: Wednesday, January 25, 2017 at 8:39 PM
To: 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, Jeffrey Zhang 
<zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: AD Review of draft-ietf-bess-evpn-vpws-07
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<ssa...@cisco.com<mailto:ssa...@cisco.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<d...@steinbergnet.net<mailto:d...@steinbergnet.net>>, 
<thomas.beckh...@telekom.de<mailto:thomas.beckh...@telekom.de>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jefft...@gmail.com<mailto:jefft...@gmail.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Resent-Date: Wednesday, January 25, 2017 at 8:39 PM

Dear authors:

Hi!

I just finished reading this document.  Please take a look at my comments below 
– I think they should be easy to resolve.  I will start the IETF Last Call when 
the comments have been addressed and a new revision has been published.

Thanks!

Alvaro.


Major:

M1. There are 8 authors listed on the front page.  Following the guidelines in 
the RFC Style Guide [RFC7322], we want the list to be at most 5.  Please work 
among yourselves to reduce the number of authors.  Alternatively, you can just 
list an Editor or two.


M2. From the Introduction: “Unlike EVPN where Ethernet Tag ID in EVPN routes 
are set to zero…in EVPN-VPWS, Ethernet tag ID in the Ethernet A-D route MUST be 
set to a valid value in all the service interface types.”  Zero is a valid 
value for the Ethernet Tag ID.

Sami: I will change the text from “a valid value” —> “non zero value”.

Section 3. (BGP Extensions) says that “the Ethernet Tag ID 32-bit field is set 
to the 24-bit VPWS service instance identifier”, but I couldn’t find a place 
where the document told me what a valid value is.  IOW, how can the “MUST” be 
enforced if there’s no clear indication of what is valid?  OTOH, any 
specification wants the fields to contain valid values, obviously!  What 
happens if the value is not valid?BTW, all this is to say that without a 
proper explanation (which probably doesn’t belong in the Introduction), the 
whole paragraph is superfluous.

Sami: A valid value will be non-zero 24-bit, I will change the text to 
"non-zero 24-bit VPWS service instance identifier"


M3. The Introduction says that “For EVPL service, the Ethernet frames 
transported over an MPLS/IP network SHOULD remain tagged with the originating 
VID and any VID translation is performed at the disposition PE.”, later the 
same (or at least something similar) is mentioned in Section 2.1. (VLAN-Based 
Service Interface): “the Ethernet frames transported over an MPLS/IP network 
SHOULD remain tagged with the originating VID, and a VID translation MUST be 
supported in the data path and MUST be performed on the disposition PE.”  
Please keep the normative language in one place – I am not fond of normative 
language in the Introduction; note that even though the result should be the 
same, the text is different (the “MUSTs” are used in 2.1).

Sami: Will change the introduction to say MUST be

M3.1. [minor] It is not clear in the text that EVPL service corresponds to 
VLAN-based service.  Please clarify that.  In fact, some of the flow of the 
document feel disjoint because slightly different terminology is used and no 
hint of how it all ties together is presented; mapping EPL/EVPL to the Service 
Interfaces, which are only mentioned in Section 2 (and very briefly in the 
Introduction – see M2).

Sami: In the introduction we have this text "[MEF] defines Ethernet Virtual 
Private Line (EVPL) service as p2p service between a pair of ACs (designated by 
VLANs) and Ethernet Private Line (EPL) service …” So, isn’t that sufficient?


M4. Section 1.2 is titled Requirements.  However, the list seems to include a 
combination of statements of fact (“EPL service access circuit maps to the 
whole Ethernet port”: this is pretty much the definition of EPL), 
solution-sounding lines (“Each VLAN individually (or <S-VLAN,C-VLAN> 
combination) will be considered to be an endpoint for an EVPL service”: not 
only does it sound like

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

[Sami Boutros]

Support.

Sami

> On Jan 31, 2017, at 7:44 AM, Jeffrey (Zhaohui) Zhang  
> wrote:
> 
> Support.
> 
>> -Original Message-
>> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
>> Sent: Tuesday, January 31, 2017 9:58 AM
>> To: bess@ietf.org
>> Cc: draft-sajassi-bess-evpn-igmp-mld-pr...@ietf.org
>> Subject: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01
>> 
>> Hello working group,
>> 
>> This email starts a two-week poll on adopting
>> draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item.
>> 
>> Please send comments to the list and state if you support adoption or
>> not (in the later case, please also state the reasons).
>> 
>> This poll runs until **February 14th**.
>> 
>> *Coincidentally*, we are also polling for knowledge of any 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-sajassi-bess-evpn-igmp-mld-proxy-01
>> 
>> ___
>> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Thanks Alvaro for your comments.

Will address them and resubmit the draft.

Thanks,

Sami
From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>
Date: Wednesday, January 25, 2017 at 8:39 PM
To: 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>" 
<draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, Jeffrey Zhang 
<zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: AD Review of draft-ietf-bess-evpn-vpws-07
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<ssa...@cisco.com<mailto:ssa...@cisco.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<d...@steinbergnet.net<mailto:d...@steinbergnet.net>>, 
<thomas.beckh...@telekom.de<mailto:thomas.beckh...@telekom.de>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jefft...@gmail.com<mailto:jefft...@gmail.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Resent-Date: Wednesday, January 25, 2017 at 8:39 PM

Dear authors:

Hi!

I just finished reading this document.  Please take a look at my comments below 
– I think they should be easy to resolve.  I will start the IETF Last Call when 
the comments have been addressed and a new revision has been published.

Thanks!

Alvaro.


Major:

M1. There are 8 authors listed on the front page.  Following the guidelines in 
the RFC Style Guide [RFC7322], we want the list to be at most 5.  Please work 
among yourselves to reduce the number of authors.  Alternatively, you can just 
list an Editor or two.


M2. From the Introduction: “Unlike EVPN where Ethernet Tag ID in EVPN routes 
are set to zero…in EVPN-VPWS, Ethernet tag ID in the Ethernet A-D route MUST be 
set to a valid value in all the service interface types.”  Zero is a valid 
value for the Ethernet Tag ID.  Section 3. (BGP Extensions) says that “the 
Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance 
identifier”, but I couldn’t find a place where the document told me what a 
valid value is.  IOW, how can the “MUST” be enforced if there’s no clear 
indication of what is valid?  OTOH, any specification wants the fields to 
contain valid values, obviously!  What happens if the value is not valid?
BTW, all this is to say that without a proper explanation (which probably 
doesn’t belong in the Introduction), the whole paragraph is superfluous.


M3. The Introduction says that “For EVPL service, the Ethernet frames 
transported over an MPLS/IP network SHOULD remain tagged with the originating 
VID and any VID translation is performed at the disposition PE.”, later the 
same (or at least something similar) is mentioned in Section 2.1. (VLAN-Based 
Service Interface): “the Ethernet frames transported over an MPLS/IP network 
SHOULD remain tagged with the originating VID, and a VID translation MUST be 
supported in the data path and MUST be performed on the disposition PE.”  
Please keep the normative language in one place – I am not fond of normative 
language in the Introduction; note that even though the result should be the 
same, the text is different (the “MUSTs” are used in 2.1).

M3.1. [minor] It is not clear in the text that EVPL service corresponds to 
VLAN-based service.  Please clarify that.  In fact, some of the flow of the 
document feel disjoint because slightly different terminology is used and no 
hint of how it all ties together is presented; mapping EPL/EVPL to the Service 
Interfaces, which are only mentioned in Section 2 (and very briefly in the 
Introduction – see M2).


M4. Section 1.2 is titled Requirements.  However, the list seems to include a 
combination of statements of fact (“EPL service access circuit maps to the 
whole Ethernet port”: this is pretty much the definition of EPL), 
solution-sounding lines (“Each VLAN individually (or <S-VLAN,C-VLAN> 
combination) will be considered to be an endpoint for an EVPL service”: not 
only does it sound like what the solution will do, but it is also the 
definition of EVPL), and statements that talk to the configuration and not what 
the technical solution described later can do (“A given PE could have thousands 
of EVPLs configured. It must be possible to configure multiple EVPL services 
within the same EVI.”: is there an actual scalability requirement?). I 
would have expected actual requirements (for example: “EPL service access 
circuits MUST map to the whole Ethernet port”; normative language is not 
required) that I can then check against the solution – bu

Re: [bess] EVPN-VPWS Service Edge Gateway rev03

[Sami Boutros]

Hi Jorge,

The ES is that case will be set manually by the operator for the group of 
service routers that are in the same redundancy group. Will make sure this 
clarification is in the next Rev.

Thanks,

Sami
From: "Rabadan, Jorge (Nokia - US)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Date: Saturday, November 26, 2016 at 3:44 AM
To: Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>
Cc: "EXT Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, 
"Patrice Brissette (pbrisset)" <pbris...@cisco.com<mailto:pbris...@cisco.com>>, 
Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: EVPN-VPWS Service Edge Gateway rev03

Hi Sami,

Thank you.

I still fail to see this:
“The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.”

RFC7432’s DF election is purely based on the ES route and not the per ES AD 
route. What do you mean with the sentence above? You don’t use the ES route 
whatsoever? How is the ESI value figured out?
IMHO those things are not straight forward to figure out just by reading the 
text.

Thanks.
Jorge



On 11/24/16, 10:14 PM, "Sami Boutros" 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>> wrote:

Hi Jorge,

Sorry for the delay, I will be addressing the comments below in the next rev, 
and will be clarifying the DF election too.

The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.

The election will be performed to decide on who will be the primary responding 
to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the 
access nodes by applying the HRW algorithm.

I will clarify the text to reflect the above.

Thanks,

Sami

On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:
Sami,
I looked at your Service Edge Gateway draft, and since my comments/questions 
were not addressed in rev 03, I’m resending our last exchange.
Besides the comments below (please see the thread from earlier this year), the 
most confusing part to me is still the multi-homing on the Service Edge nodes. 
After reading the text, still not sure if the intend is a DF election based out 
of the AD per-EVI routes or if the DF election follows regular RFC7432 
procedures. This is a blurry area in the draft and I would personally 
appreciate a clarification.
Thank you.
Jorge
On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
<jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>> 
wrote:
Hi Sami,
As discussed, this is the email. The new comments are tagged as [JORGE2].
Please see in-line.
Thanks.
Jorge
--
From: Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>
Date: Tuesday, October 20, 2015 at 5:39 AM
To: Jorge Rabadan 
<jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
Hi Jorge,
--
Abstract
This document describes how a service node can dynamically terminate
EVPN virtual private wire transport service (VPWS) from access nodes
and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
Customer edge devices connected to the access nodes. Service nodes
using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
overlay services it can offer for the terminated EVPN VPWS transport
service. On an access node an operator can specify the L2 or L3 or
Ethernet VPN overlay service needed by the customer edge device
connected to the access node that will be transported over the EVPN-
VPWS service between access node and service node.
/* [JORGE] it would be good to clearly state the benefit of doing this.
The main advantages that I see are service extension with single-side
provisioning (no need to provision new ACs at the service node). */
Sami: will update the abstract.
[JORGE2] I don’t see anything changed in rev 02 ;-)

1  Introduction
/* [JORGE] maybe this level of detail at the introduction is a bit
confusing. I think it would be better to state what the goal and
advantages are in the introduction and leave the details for the solution
description. */
Sami: will update.
[JORGE2] I don’t see anything changed in rev 02 ;-)

...
2.2  Scalability
(R2a) A single service node PE can be associated with many access

Re: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02

[Sami Boutros]

Hi Jeffrey,



>>One RT is used for the service edge GWs to discover themselves so that
>> they can do DF election using HRW. The other RT is used among edge nodes
>> and service edge nodes for setting up P2P service tunnels.
>
>It's still not clear why the other RT is needs to be included in that route. 
>It does not seem to be necessary for the edge nodes to import that route? The 
>edge nodes only need to be configured what RT needs to be used for what 
>service, and one edge node's route does not need to be imported by other edge 
>nodes - only the service nodes need to import it.

This is correct, but the service node need still to import the access edge 
nodes routes to be able to respond to them, and for that it still need an RT or 
at least an import extended community, we can have for that an EVPN Layer 2 
import extended community provisioned/derived at service node, however I think 
when service node respond to the access node, it still need to attach an RT not 
an import EC, in order not to change the operation access nodes.

>
>> There are scenarios in which access node need to ONLY backhaul traffic
>> (and not do any local switching!). In those scenarios, you will need to
>> terminate the service tunnels at the service edge nodes regardless of IRB
>> or not.
>
>Understand. However, if the service is EVPN, even when you terminate the VPWS 
>with logical interfaces that are part of of the service EVI on the service 
>node, that service node will do local switching between those logical 
>interface; if we extend the EVPN to the edge node using virtual hub and spoke, 
>the traffic between the edge nodes will still go through the service nodes 
>anyway due to the nature of hub and spoke, so no different from the VPWS 
>approach as far as local switching is concerned?

The way I look at this as yet another option that will be outside the spoke of 
this draft, since this is vanilla EVPN hub and spoke that can be used too. I.e. 
This draft define another mean of achieving a similar thing, in scenarios where 
access node will only be capable of supporting dynamic EVPN-VPWS or even static 
EVPN-VPWS with no signaling.

Thanks,

Sami
>
>Thanks.
>
>Jeffrey
>
>> -Original Message-
>> From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
>> Sent: Wednesday, November 16, 2016 9:07 AM
>> To: Jeffrey (Zhaohui) Zhang; Sami Boutros; bess@ietf.org
>> Subject: Re: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-
>> service-edge-gateway-02
>> 
>> 
>> Hi Jeffrey,
>> 
>> 
>> On 11/14/16, 10:13 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang"
>> <bess-boun...@ietf.org on behalf of zzh...@juniper.net> wrote:
>> 
>> >Sami,
>> >
>> >Let me use this old thread to continue the discussion during/after your
>> >presentation on Monday.
>> >
>> >   The service node would advertise EVPN-VPWS per EVI Ethernet A-D
>> >   routes with the Ethernet Segment Identifier field set to 0 and the
>> >   Ethernet tag ID set to (0x wildcard), all those routes will
>> >   be associated with the EVPN-VPWS service edge RT that will be
>> >   imported by other service edge PEs, each route will have a unique RD
>> >   and will be associated with another RT corresponding to the L2, L3 or
>> >   Ethernet VPN overlay service that can be transported over the EVPN-
>> >   VPWS transport service.
>> >
>> >As we agreed after the session, the second RT above is only used to
>> >indicate the type of services that a service node support but not for the
>> >purpose of route import/export control. For that, we don't need to use
>> >RTs. ECs are just fine. An afterthought is that, we can probably define
>> >some bits in "EVPN Layer 2 attributes extended community" to signal the
>> >types of services?
>> 
>> One RT is used for the service edge GWs to discover themselves so that
>> they can do DF election using HRW. The other RT is used among edge nodes
>> and service edge nodes for setting up P2P service tunnels.
>> 
>> >
>> >When a service node advertises a per EVI Ethernet A-D rout in response to
>> >the one received from an access node, it could target the route to that
>> >particular access node. This could be done by including a VRF Route
>> >Import EC (RFC 7153) in the route sent by the access node - the service
>> >node will include that in its route and only the targeted access node
>> >will import it.
>> >
>> >We did not get to cover the following two points:
>> >
>> >- during draft-ietf-bess-evpn

Re: [bess] Slots requests for BESS WG session - IETF 97 - Seoul

[Sami Boutros]

Hi Martin,

I would like to present 3 old drafts with 5 mins for each draft a total of 15 
mins.

draft-boutros-bess-evpn-auto-provisoning 

draft-boutros-bess-evpn-vpws-service-edge-gateway 

draft-boutros-bess-vxlan-evpn 


Thanks,

Sami

> On Oct 18, 2016, at 1:28 AM, Martin Vigoureux  
> wrote:
> 
> All,
> 
> it is time we start building the BESS WG agenda for Seoul.
> The IETF agenda is available at:
> https://datatracker.ietf.org/meeting/97/agenda.html
> Please note that it is still a preliminary agenda.
> 
> The BESS WG session (2h) is currently scheduled on
> Monday, 14th of November, Afternoon session I 13:30-15:30 (local time)
> 
> Please send us your request for a presentation slot, indicating
> draft name, speaker and desired duration (covering presentation +
> discussion)
> 
> Please send the requests no later than the 30th of October.
> Thank you
> 
> M
> 
> ___
> 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] Poll for adoption: draft-boutros-bess-vxlan-evpn-01

[Sami Boutros]

Support as a co-author and not aware of any ipr

Thanks,

Sami

Sent from my iPhone

> On Jun 20, 2016, at 6:22 AM, "thomas.mo...@orange.com" 
>  wrote:
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting
> draft-boutros-bess-vxlan-evpn-01 [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 *July 4th*.
> 
> 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.
> 
> No IPR has been disclosed against this Document.
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dboutros-2Dbess-2Dvxlan-2Devpn-2D01=CwICaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=me053Be9qKrCJjUISJBP2sGFEDp-39GNmgAhZLwv8aY=K1uFmxlFzD89U7uo4iRU6pSEhwdxCD42QGfWCXlgrvE=140df9Ysq87qs5jbDwHs5EQStDRt1MUfX9BDVWX_qh8=
>  
> _
> 
> 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 Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[Sami Boutros]

Sure Martin,

Will do.

Sami

Sent from my iPhone

> On Jun 1, 2016, at 12:26 AM, Martin Vigoureux  
> wrote:
> 
> WG,
> 
> we have now received an answer from all the authors and to their knowledge 
> there is no undisclosed IPR that relates to this draft.
> 
> Sami, please update the draft and make sure that *all* the authors are 
> identified on the submission page, with their latest address, before 
> submitting the draft to publication (the draft alias is incomplete/incorrect).
> 
> And please get back to the WG with a synthesis of the changes brought to the 
> draft.
> 
> -m
> 
> Le 24/05/2016 10:05, Martin Vigoureux a écrit :
>> WG, Authors,
>> 
>> we are past the deadline for this WG LC.
>> I am still waiting for statements from authors.
>> In the meantime could you update the draft to reflect the necessary
>> changes which were identified as part of the WG LC.
>> In doing so, could you trim the list of authors to max 5 on the first
>> page and make sure the e-mail addresses are all correct.
>> 
>> Beyond that we are ready to go as we have knowledge of implementations.
>> 
>> Thank you
>> -m
>> 
>> Le 05/05/2016 12:54, EXT Martin Vigoureux a écrit :
>>> Hello Working Group,
>>> 
>>> Please read carefully, this e-mail contains new elements compared to
>>> other WG LCs.
>>> 
>>> This email starts a Working Group Last Call on
>>> draft-ietf-bess-evpn-vpws-03 [1].
>>> 
>>> ¤ Please read the document if you haven't read the most recent
>>> version yet, and send your comments to the list, no later than
>>> *20th of May*.
>>> Note that this is *not only* a call for comments on the document, but
>>> also a call for support (or not) publishing this document as a Proposed
>>> Standard RFC.
>>> 
>>> ¤ We are also polling for knowledge of any undisclosed IPR that applies
>>> to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed
>>> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378
>>> for more details) prior to moving forward.
>>> If you are listed as a document 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.
>>> Two IPR disclosures exist against previous revisions of this document
>>> [2].
>>> 
>>> ¤ We are also polling for knowledge of implementations of part or all of
>>> what this document specifies. This information is expected as per [3].
>>> Please inform the mailing list, the chairs, or only one of the chairs.
>>> 
>>> ¤ Finally, if someone wishes to volunteer to be Document Shepherd for
>>> this document, please let us know.
>>> 
>>> Thank you
>>> M
>>> 
>>> 
>>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/
>>> [2]
>>> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-vpws
>>> 
>>> 
>>> [2]
>>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>>> 
>>> ___
>>> 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 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] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[Sami Boutros]

Thanks Jim and Jeffrey for the comments,

We will move the BW section to the service-edge-gateway draft specially for the 
single side signaling and we will mention that the BW can be handled 
orthogonally too.

Thanks,

Sami
From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Tuesday, May 31, 2016 at 7:17 AM
To: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>, 
Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for 
draft-ietf-bess-evpn-vpws-03

Sami,

My two cents ;) These constraints will most likely be managed 
by the SP in an orthogonally from the creating of PWs.. At least that would be 
my approach.. So, goes something like, service requested, check available 
resources ( BW, Ports, latency, etc… ) select endpoints that meet the criteria.

Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, May 27, 2016 5:41 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for 
draft-ietf-bess-evpn-vpws-03

Hi Sami,

I thought about this BW topic further, and have the following question:

- Even for the originally stated purpose, i.e. for PE1 to request PE2 to 
request BW reservation in the network, why does it have to be signaled from 
PE1? Why can’t you provision PE2 to request that BW reservation? You need to 
provision service identifier on both PE1 and PE2 anyway, so you might as well 
add BW provisioning on PE2.



I understand that draft-boutros-bess-evpn-vpws-service-edge-gateway-02 does 
specify that the service node could skip the service identifier configuration 
and automatically signals the one that it receives from the access node. In 
that case, signaling qos/bw parameters from the access node makes sense (in 
that there is no need for configuration on the service node side).



So, perhaps the entire BW or shaping signaling stuff could be moved from the 
base EVPN-VPWS draft to draft-boutros-bess-evpn-vpws-service-edge-gateway?



Jeffrey

Sami: The issue here is that we are using the BW idr draft, and there is no 
shaping defined there, and we don’t plan to define a new attribute for this, 
perhaps we can add that to a new draft?
 Zzh2> Good point that BW is not equal to shaping parameters; however, existing 
PW specifications do not seem to have BW related stuff and one actual customer 
use case I am aware of with EVPN VPWS actually does involve shaping; so maybe 
it’s better to take care of this in the base spec? It’s just a new attribute 
anyway.

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

Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[Sami Boutros]

Hi Jeff,

I am ok to remove the BW section, adding other authors for their I/p.

Thanks,

Sami
From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Friday, May 27, 2016 at 2:41 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for 
draft-ietf-bess-evpn-vpws-03

Hi Sami,

I thought about this BW topic further, and have the following question:

- Even for the originally stated purpose, i.e. for PE1 to request PE2 to 
request BW reservation in the network, why does it have to be signaled from 
PE1? Why can’t you provision PE2 to request that BW reservation? You need to 
provision service identifier on both PE1 and PE2 anyway, so you might as well 
add BW provisioning on PE2.



I understand that draft-boutros-bess-evpn-vpws-service-edge-gateway-02 does 
specify that the service node could skip the service identifier configuration 
and automatically signals the one that it receives from the access node. In 
that case, signaling qos/bw parameters from the access node makes sense (in 
that there is no need for configuration on the service node side).



So, perhaps the entire BW or shaping signaling stuff could be moved from the 
base EVPN-VPWS draft to draft-boutros-bess-evpn-vpws-service-edge-gateway?



Jeffrey

Sami: The issue here is that we are using the BW idr draft, and there is no 
shaping defined there, and we don’t plan to define a new attribute for this, 
perhaps we can add that to a new draft?
 Zzh2> Good point that BW is not equal to shaping parameters; however, existing 
PW specifications do not seem to have BW related stuff and one actual customer 
use case I am aware of with EVPN VPWS actually does involve shaping; so maybe 
it’s better to take care of this in the base spec? It’s just a new attribute 
anyway.

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

Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[Sami Boutros]

Hi Jeffrey,

Please see responses inline in green.

From: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Date: Monday, May 16, 2016 at 2:18 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for 
draft-ietf-bess-evpn-vpws-03

Hi Sami,

Please see zzh> below. I trimmed some text.


   ... eliminates the
   need for single-segment and multi-segment PW signaling,

This is not discussed in the draft later. It should either be discussed, or 
removed from the abstract & introduction.
[Sami]
We do have a section 5 on comparison between PW signaling and EVPN, Actually, 
the draft is proposing a mechanism that eliminates PW signaling for P2P service 
using EVPN, so not sure how can we remove this?

Zzh> It’s the mentioning of “single-segment and multi-segment” that led to my 
comments. If that were not there, it would not have been an issue. For example, 
I had expected some text on how multi-segment PW is realized in EVPN-VPWS. If 
you don’t plan to talk about that, then just don’t bring it up. For example, 
simply say “eliminates the need for traditional way of PW signaling”.

   ... and provides
   fast protection using data-plane prefix independent convergence upon
   node or link failure.

This is not discussed in the draft either. Can you elaborate? Is it really 
enabled by EVPN or actually independent of EVPN?

[Sami]
Please have a look at section 5.
[Sami]

Zzh> When it comes to PIC, the closed thing I can find in section 5 is the 
following:

   Upon link or node failure, EVPN can trigger failover with the
   withdrawal of a single BGP route per EVPL service or multiple EVPL
   services, whereas with VPWS PW redundancy, the failover sequence
   requires exchange of two control plane messages: one message to
   deactivate the group of primary PWs and a second message to activate
   the group of backup PWs associated with the access link. Finally,
   EVPN may employ data plane local repair mechanisms not available in
   VPWS.

The first part (before “Finally”) talks about the two control plane message – 
so that’s not “data-plane” (the text I had question about talks about 
“data-plane prefix independent convergence). The second part talks about “data 
plane local repair” but has no details that I was looking for.

Sami:
The local repair here will be done by the primary PE o(on local AC down) using 
the label advertised in per EVI EAD route advertised by the backup PE will 
direct the traffic to backup PE, I will add this text to clarify this, is this 
ok?
Sami:

It seems that the Ethernet Segment is not used consistently. From RFC 7432:

   Ethernet Segment (ES): When a customer site (device or network) is
  connected to one or more PEs via a set of Ethernet links, then
  that set of links is referred to as an 'Ethernet segment'.

My understanding is that ES is at link/port level and it refers to a set of 
links, while AC could be at vlan level. In the below paragraph,

   [EVPN] has the ability to forward customer traffic to/from a given
   customer Attachment Circuit (AC), aka Ethernet Segment in EVPN
   terminology, without any MAC lookup.

Here we're referring AC as ES - it does not seem to be stringent.
It's better to remove "aka Ethernet Segment in EVPN terminology" to avoid 
inconsistency.

Sami: Sure will remove.

[Sami]

There is no inconsistency, the text you refer to in [7432] is part of the 
explanation of the ESI or ethernet segment identifier.
in [7432] Page 31, it mentions exactly what we are referring to above. "On the 
other hand, a unique label per <ESI, Ethernet tag> allows an egress PE to 
forward a packet that it receives from another PE, to the connected CE, after 
looking up only the MPLS labels without having to perform a MAC lookup.”

Zzh> My point is about the relationship between ES and AC/link/port (see below) 
and not about whether mac lookup is done or not.

[Sami]

   ... [MEF] defines Ethernet
   Virtual Private Line (EVPL) service as p2p service between a pair of
   ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in
   which all traffic flows are between a single pair of ESes.

Perhaps change "ESes" to "links or ESes"? The definition of ES in RFC7432 is 
"set of links". See below about generalization.

[Sami]

From one PE point of view an ES is a single link.[7432] is not denying this.

Zzh> My original point was that, RFC 7432 defines a ES as “set of links” for 
multi-homing case so “between a single pair of ESes” here may be a little 
misleading. I am not going to split hair on this – but please see more below on 
this to understand my intention and a simple fix (again it’s up to you and I am 
not insisting).

Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[Sami Boutros]

Hi Jeffrey,

Thanks for your comments, Please see responses inline.

Hi,

As the document shepherd, I have the following questions/comments. Some of 
which are just editorial nits.

   This document describes how EVPN can be used to support virtual
   private wire service (VPWS) in MPLS/IP networks.

Please capitalize "virtual private wire service". There are two other cases of 
this.

   ... eliminates the
   need for single-segment and multi-segment PW signaling,

This is not discussed in the draft later. It should either be discussed, or 
removed from the abstract & introduction.

[Sami]
We do have a section 5 on comparison between PW signaling and EVPN, Actually, 
the draft is proposing a mechanism that eliminates PW signaling for P2P service 
using EVPN, so not sure how can we remove this?

[Sami]

   ... and provides
   fast protection using data-plane prefix independent convergence upon
   node or link failure.

This is not discussed in the draft either. Can you elaborate? Is it really 
enabled by EVPN or actually independent of EVPN?

[Sami]
Please have a look at section 5.
[Sami]


It seems that the Ethernet Segment is not used consistently. From RFC 7432:

   Ethernet Segment (ES): When a customer site (device or network) is
  connected to one or more PEs via a set of Ethernet links, then
  that set of links is referred to as an 'Ethernet segment'.

My understanding is that ES is at link/port level and it refers to a set of 
links, while AC could be at vlan level. In the below paragraph,

   [EVPN] has the ability to forward customer traffic to/from a given
   customer Attachment Circuit (AC), aka Ethernet Segment in EVPN
   terminology, without any MAC lookup.

Here we're referring AC as ES - it does not seem to be stringent.
It's better to remove "aka Ethernet Segment in EVPN terminology" to avoid 
inconsistency.

[Sami]

There is no inconsistency, the text you refer to in [7432] is part of the 
explanation of the ESI or ethernet segment identifier.
in [7432] Page 31, it mentions exactly what we are referring to above. "On the 
other hand, a unique label per  allows an egress PE to 
forward a packet that it receives from another PE, to the connected CE, after 
looking up only the MPLS labels without having to perform a MAC lookup.”

[Sami]

   ... [MEF] defines Ethernet
   Virtual Private Line (EVPL) service as p2p service between a pair of
   ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in
   which all traffic flows are between a single pair of ESes.

Perhaps change "ESes" to "links or ESes"? The definition of ES in RFC7432 is 
"set of links". See below about generalization.

[Sami]

From one PE point of view an ES is a single link.[7432] is not denying this.

[Sami]

   ... EVPL can
   be considered as a VPWS with only two ACs.

Both EVPL and EPL can be considered as VPWS with only two ACs (I assume an AC 
is not necessarily at vlan level).

   ... In a VPWS service,  the traffic from an
   originating Ethernet Segment can be forwarded only to a single
   destination Ethernet Segment; hence, no MAC lookup is needed and the
   MPLS label associated with the per-EVI Ethernet AD route can be used
   in forwarding user traffic to the destination AC.

I can understand that ES here is generalized, but it's better to point out at 
the beginning.


   For a multi-homed CE, in an advertised Ethernet A-D per EVI route the
   ESI field is set to the CE's ESI and the Ethernet Tag field is set to
   the VPWS service instance identifier, which MUST have the same value
   on all PEs attached to that ES.

What if you receive a set of per EVI routes with the same Ethernet Tag field 
but different ESIs? The spec should define the behavior.

[Sami]
Those will be different routes as per [7432]. We are not defining any new 
behavior.

[Sami]

   In all cases traffic follows the transport paths, which
   may be asymmetric.

"follows the transport paths" is hard to understand. Perhaps this sentence 
could be deleted.

[Sami]
Transport paths carry the service traffic over the MPLS transport network, we 
are simply mentioning this, those paths can for sure be asymetric as the per 
the nature of MPLS LSPs. I am not really sure if we should delete this.
[Sami]


   The Ethernet Segment identifier encoded in the Ethernet A-D per EVI
   route is not used to identify the service, however it can be used for
   flow-based load-balancing and mass withdraw functions.

The first clause is a little strange in its reference to "identify the 
service". It seems to be just irrelevant? Also, it's not the ESI itself that is 
used for load-balancing? Perhaps the paragraph can be reworded as the following:

   The Ethernet A-D per ES route and corresponding Ethernet A-D per
   EVI routes can be correlated by the Ethernet Segment Identifier.
   This allows flow-based load-balancing and mass withdraw functions.

[Sami]
Ok, will change this.
[Sami]


In the following paragraph:

   For 

Re: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02

[Sami Boutros]

Hi Jeffrey,

Thanks for your comments and Please see comments inline..

On 3/24/16, 6:20 PM, "Jeffrey (Zhaohui) Zhang"  wrote:

>Sami and co-authors,
>
>I have some comments & questions on this draft.
>
>I noticed that the following terms are used in a mixed way and that adds 
>confusion. Perhaps it could be straightened out?
>
>  Service node, service edge node, service edge gateway, access node

Sami: Agreed will update the text in next rev.
>
>Also in Figure 1, "AN" and "SE" are not marked in the figure.

Sami: will do.
>
>There are a couple of places referring to "underlay EVI". Given that underlay 
>typically refer to the underlying provider network, perhaps "transport EVI" or 
>"VPWS EVI" would be better?

Sami: We will update this text too.
>
>   This document describes how a service node can act as a gateway
>   terminating dynamically EVPN virtual private wire service (VPWS) from
>   access nodes and offering Layer 2, EVPN and Layer 3 VPN overlay
>   services to Customer edge devices connected to the access nodes.
>
>I take it that the gateway is offering "layer 2, EVPN and layer 3 VPN" 
>services but instead of via local attachment circuits, it's via VPWS 
>implemented via EVPN.

Sami: Correct.
>
>"4.2 Applicability to IP-VPN TBD" is empty, so I'll use EVPN for my 
>understanding: the VPWS brings the customer connection (on the AN) to the EVPN 
>on the gateway. There could be many VPWS from multiple ANs terminating into 
>the same EVPN instance on the gateway. With that, I wonder if EVPN virtual hub 
>and spoke could be used to implement the same? The ANs would be the spokes and 
>the gateway would be the hub? Other EVPN PEs (not drawn in Figure 1) on the 
>core side can be either spokes or hubs in the same EVPN instance?
>
>If the above makes sense, then could the same be extended to IP-VPN service? 
>You just need an IRB interface for the EVPN instance on the gateway?

Sami: The current document doesn’t preclude the IRB option and terminating 
multiple EVPN VPWS to the same L2 overlay bridge that has an IRB interface 
attached to an IP-VPN service. The empty sections are there for describing use 
cases that we will plan to add to the document in the future.

Thanks,

Sami

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

Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires

[Sami Boutros]

On Mon, Mar 7, 2016 at 10:27 AM, Sami Boutros <boutros.s...@gmail.com>
wrote:

> We would like to request slots for
>
> 1- draft-boutros-bess-evpn-auto-provisoning-01 , Speaker : Rex or Sami, 10
> mins.
> 2- draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Speaker: Sami or
> Patrice 10 mins.
>
> Thanks,
>
> Sami
>
>
> On Mon, Mar 7, 2016 at 4:18 AM, Martin Vigoureux <
> martin.vigour...@nokia.com> wrote:
>
>> All,
>>
>> it is time we start building the BESS WG agenda for Buenos Aires.
>> The IETF agenda is available at:
>> https://datatracker.ietf.org/meeting/95/agenda.html
>> Please note that it is still a preliminary agenda.
>>
>> The BESS WG session (2h) is currently scheduled on
>> Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time)
>>
>> Please send us your request for a presentation slot, indicating:
>> draft name, speaker and desired duration (covering presentation +
>> discussion)
>>
>> Please send the requests no later than the 20th of March
>> Thank you
>>
>> M
>>
>> ___
>> 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 for draft-boutros-bess-vxlan-evpn-00.txt

[Sami Boutros]

On Mon, Mar 7, 2016 at 10:30 AM, Sami Boutros <boutros.s...@gmail.com>
wrote:

> Hi Thomas and Martin,
>
> The draft has been around for 3 years, and the authors think it is ready
> for adoption, can we please ask for a WG poll for it?
>
> Thanks,
>
> Sami
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

[Sami Boutros]

Same here and I am not aware of any ipr beyond what was already disclosed

Sami

Sent from my iPhone

> On Feb 3, 2016, at 6:55 AM, Aldrin Isaac  wrote:
> 
> I support as co-author.  Not aware of any related IPR. 
> Cheers,
> Aldrin
> 
>> On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin  
>> wrote:
>> Hello Working Group,
>> 
>> This email starts a Working Group Last Call on
>> draft-ietf-bess-evpn-etree [1] which is considered mature and ready for
>> a final working group review.
>> 
>> Please read the document if you haven't read the most recent version yet
>> (-03), and send your comments to the list, no later than *February the
>> 2nd* (2016-02-02).
>> 
>> This is not only a call for comments on the document, but also a call of
>> support for its publication.
>> 
>> *Coincidentally*, we are also polling for knowledge of any IPR that
>> applies to draft-ietf-bess-evpn-etree, 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 of
>> draft-ietf-bess-evpn-etree please respond to this email and indicate
>> whether or not you are aware of any relevant IPR.
>> 
>> Thank you,
>> 
>> Thomas/Martin
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
>> 
>> ___
>> 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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Regd. DF Election Notes

[Sami Boutros]

Same here

Thanks,

Sami

Sent from my iPhone

> On Jan 24, 2016, at 6:47 AM, Henderickx, Wim (Nokia - BE) 
>  wrote:
> 
> Support, since this enhances the DF election for EVPN
> 
> On 1/11/16, 1:07 AM, "BESS on behalf of Martin Vigoureux" 
>  
> wrote:
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting
> draft-mohanty-bess-evpn-df-election-02 [1] as a working group item.
> 
> Please state on the list if you support adoption or not (in the both 
> cases, please also state the reasons).
> 
> This poll runs until *the 25th of January*.
> 
> Currently no IPR has been disclosed against this document.
> 
> *Coincidentally*, we are also polling for knowledge of any 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-mohanty-bess-evpn-df-election/
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> 
> From: "Henderickx, Wim (Wim)" 
> Date: Saturday, July 25, 2015 at 10:28 PM
> To: smohanty mohanty 
> Subject: Re: Regd. DF Election Notes
> 
> Here you go
> 
> From: "Satya Mohanty (satyamoh)"
> Date: Sunday 26 July 2015 08:07
> To: Wim Henderickx
> Subject: Regd. DF Election Notes
> 
> Hi Wim,
> 
> Good to talk to you at the airport.
> I am following up on the request to please send me the writeup regarding the 
> various service models sec 6.1 – 6.3.
> About 2-3 years back you had circulated such a dic.
> Best would be if you’ve examples.
> 
> Thanks,
> --Satya
> ___
> 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] Seeking Comments for EVPN-VPWS Service Edge Gateway

[Sami Boutros]

ontext? why
> is it different from L2 or L3 service? should this be clarified in the
> introduction?
> Also by L2 and L3 are you referring to the encapsulation? i.e. L2 means
> ethernet over the EVI label and L3 IP over the EVI label? */
>
> /* [JORGE] If the service RTs are the same in the access and core network,
> PE2 should have two different peering sessions, one to the RR in the
> access network and one to the core RR. Is that the intend? if so, it may
> be good to clarify */
>
>
Sami:Can you please look at the updated version 01 and see what comments
still apply?

>
>
>
>
>Service edge nodes on the underlay EVI will determine the primary
>service node terminating the VPWS transport service and offering the
>L2, L3 or Ethernet VPN service by running the on HWR algorithm as
>described in [draft-mohanty-l2vpn-evpn-df-election <
> https://tools.ietf.org/html/draft-mohanty-l2vpn-evpn-df-election>] using
> weight
>[VPWS service identifier, Service Edge Node IP address]. This ensure
>that service node(s) will consistently pick the primary service node
>even after service node failure. Upon primary service node failure,
>all other remaining services nodes will choose another service node
>correctly and consistently.
>
> /*[JORGE] Following EVPN, the DF election is based on the exchange of ES
> routes. Hence the assumption is that the two service nodes should
> advertise ES routes with a system-level ESI and an AD route per ES with
> the same ESI? The service node DF for a given service should send an AD
> per-EVI route with the P indication in the new EC defined in EVPN-VPWS. I
> believe all the
> existing procedures should be used, are you defining new ones? */
>
>
>
Sami: Please have a look at 01.


>
>Single-sided signaling mechanism is used. The Service PE node that is
>a DF for accepts to terminate the VPWS transport service from an
>access node, the primary service edge node shall:- Dynamically create
>an interface to terminate the service and shall attach this interface
>to the overlay VPN service required by the access node to service its
>customer edge device.- Responds to the Eth A-D route per EVI from the
>access node by sending its own Eth A-D per EVI route by setting the
>same VPWS service instance ID and downstream assigned MPLS label to
>be used by the access node.
>
> /* [JORGE] Need to correct the format: the two bullets must go in
> different lines */
>
>
>
Sure will do.


>
>   
>
> 4.1 Multi-homing
>
> /* [JORGE] how bout the following scenario:
>
> Here AN1 and AN2 have a ESI for the CE. Regular EVPN-VPWS procedures
> should apply.
>
>  +-+ +-+
> ++   +-----+ |     | +-+ | |
> | CE +---+ AN1 +-+ +-+ SE2 +-+ |
> +--+-+   +-+ | IP/MPLS | +-+ | IP/MPLS |
>| | Access  | | Core|
>| +-+ | Network | +-+ | Network |
>+-+ AN2 +-+ +-+ SE3 +-+ |
>  +-+ | | +-+ | |
>  +-+ +-+
> <-EVPN-VPWS-><-IP/MAC VRF>
>
> */
>
>
> Sami: Exactly, regular EVPN VPWS should apply, and hence why do we need to
mention it?

Thanks,

Sami

>
>
>
>
> From:  BESS on behalf of Sami Boutros
> Date:  Wednesday, October 7, 2015 at 11:13 PM
> To:  "bess@ietf.org"
> Subject:  [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
>
>
> Hi,
>
>
> The draft proposes a dynamic mechanism to terminate the VPWS transport
> service at a service PE into an overlay L2 or L3 service based on a single
> side provisioning at the access PE.
>
>
> https://tools.ietf.org/html/draft-boutros-bess-evpn-vpws-service-edge-gateway-01
>
>
> Thanks,
>
>
> Sami
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Feedback on draft-boutros-bess-vxlan-evpn-00.txt

[Sami Boutros (sboutros)]

Hi,

The draft has been around for almost 3 years and it is about interconnecting 
VXLAN or NVGRE networks with data plane mac learning via EVPN, the draft is 
informational and describe as well some useful use cases.

Thanks,

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

[bess] Seeking Feedback on evpn-auto-provisoning

[Sami Boutros]

Hi,

The draft propose an EVPN route based on the FSOL packets to be sent to a
controller in a data center network, to trigger a push of the related L2/L3
service configuration to be provisioned on the PE/NVE and on the switch
ports.

https://tools.ietf.org/html/draft-boutros-bess-evpn-auto-provisoning-00

Thanks,

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

[bess] draft-ietf-bess-evpn-prefix-advertisement-02

[Sami Boutros (sboutros)]

Hi Jorge,

In some of the use case sections in the draft, there is no mention of the 
label/VNI that will be associated with RT-5.
As well if the router-mac will be associated with RT-5 and the GW-IP will be 
set, why do we need to advertise those again in RT-2? 

Thanks,

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

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree

[Sami Boutros (sboutros)]

same here.

Thanks,

Sami
On May 19, 2015, at 1:35 PM, Ali Sajassi (sajassi) saja...@cisco.com wrote:

 
 
 Support as a co-author. Not aware of any IPR that hasn¹t already been
 disclosed.
 
 Regards,
 Ali
 
 On 5/19/15, 12:22 PM, Martin Vigoureux
 martin.vigour...@alcatel-lucent.com wrote:
 
 Hello working group,
 
 This email starts a two-week poll on adopting
 draft-sajassi-bess-evpn-etree [1] as a working group item.
 
 Please send comments to the list and state if you support adoption or
 not (in the later case, please also state the reasons).
 
 This poll runs until **June the 2nd**.
 
 
 *Coincidentally*, we are also polling for knowledge of any 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://tools.ietf.org/html/draft-sajassi-bess-evpn-etree
 
 ___
 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 poll - draft-fang-l3vpn-virtual-pe-05

[Sami Boutros (sboutros)]

Support.

Thanks,

Sami

Hello Working Group,

This email starts a two-week poll on adopting
draft-fang-l3vpn-virtual-pe-05 [1].

Please send comments to the list and state if you support adoption or
not (in both cases please also state the reasons).

This poll runs until November the 3rd.


Coincidentally, we remind you to check and then state on this list if you are 
aware, or not, of any undisclosed IPR (according to IETF IPR rules, see RFCs 
3979, 4879, 3669 and 5378 for more details) relating to 
draft-fang-l3vpn-virtual-pe-05

If you are listed as a document author or contributor please respond to
this email and state whether or not you are aware of any relevant
IPR. The response needs to be sent to the L3VPN WG mailing list. The document 
will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the L3VPN WG email list but 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

MT

---
[1] http://tools.ietf.org/html/draft-fang-l3vpn-virtual-pe-05


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