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

[Iftekhar Hussain <[e-mail]>]

Hi Sami,

Certainly, if it helps, certainly we could chat  via phone sometime. PWE3 model is different than what your doc is proposing. No, I am not looking for Yang model – I am co-authoring one. I am looking for clarity and thoroughness.

Thanks,
Iftekhar

From: Sami Boutros [mailto:[e-mail]]
Sent: Wednesday, February 08, 2017 11:25 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 8, 2017 at 10:45 AM
To: Sami Boutros <[e-mail]<mailto:[e-mail]>>
Cc: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>, Jeffrey Zhang <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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:image001.png@01D28202.3DC08BA0]

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:[e-mail]]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 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


A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that it would be better to sort this out. Again, if other folks are happy with the current state of the doc, I don’t want to hold your doc.

Thanks,
Iftekhar

Thanks,

Sami