For me the key question we should answer is if it does help developers 
implement vPE even if there is no new protocol extensions required.

From: Benson Schliesser <[email protected]<mailto:[email protected]>>
Date: Thursday 23 October 2014 17:02
To: Thomas Morin <[email protected]<mailto:[email protected]>>
Cc: L3VPN <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [bess] WG adoption poll - draft-fang-l3vpn-virtual-pe-05


Hi, Thomas and BESS -

I generally agree with the sentiment expressed below. That's not to say that I 
object to adoption, because ongoing work on the text might result in something 
useful. And it certainly could be helpful to have an architecture document like 
this to help drive more detailed technical work.

Of course, just because we adopt a draft does not mean that we must publish it. 
I would support adoption of this draft with an understanding of its role in 
further development activities, and an acknowledgement that it could be expired 
and dropped if it doesn't result in useful work.

Cheers,
-Benson

On Oct 22, 2014 10:12 AM, "Thomas Morin" 
<[email protected]<mailto:[email protected]>> wrote:
Hi working group,

Let me chime a different bell...

(Please note well that this feedback is sent without my co-chair hat. I won't 
participate as a chair in the adoption decision on this draft.)

Let me quote the document: "A virtual PE (vPE) is a BGP/MPLS L3/L2 VPN PE 
software instance which may reside in any network or computing devices.". You 
can pretty much ignore the 'software' part of the definition since the document 
does obviously not ban the implementation of the forwarding plane in hardware.  
What do we end up with ?  Answer: a virtual PE is... a PE !

So the notion presented by this document under the "virtual PE" name is merely 
an implementation choice that can be applied to RFC4364 and E-VPN. That 
explains why the amount of useful technical content in the document is so 
reduced (i.e. information that it neither obvious or already present 
elsewhere). I doubt that the document will be of any help to implementors or 
deployers.

Similarly, I doubt that it is very helpful to implementors or deployers to list 
all the split/no-split combinations for the control planes and dataplanes 
components; and furthermore nothing in that is really specific to BESS (e.g. it 
could apply equally to e.g. non-VPN BGP, or to some other routing protocol).

Don't misunderstand me, I think that the idea of implementing VRFs on the 
servers hosting VMs, is great. However, I don't think that a technical document 
is missing to facilitate the implementation of such an approach. It can be 
argued that an Informational RFC can be produced to promote the idea, but I 
would also challenge this: the IETF is not a marketing venue. [I would add 
that, even if it was, a 20+ pages RFC may not be the most efficient way to 
market an idea. People have been able to build solutions relying on this 
approach without a new RFC, and able to claim that their solution is based on 
IETF standard RFCs.]

Promoting the idea of an "SDN" implementation of PE functions (whatever that 
means) and/or organic data-plane/control-plane separation is yet another 
question, but if we were to adopt a document to promote this, at least I would 
expect the document to spell out the motivations and avoid just throwing I2RS 
references around.

At this point I'm leaving aside comments that could be made on details on the 
content, but I think that if this document was to be moved forward, a fair 
amount of clarification and editorial work would be needed. Given what I 
explained above, I don't think it would be worth to spend energy on that.

Overall, I don't think that BESS should adopt this document.

-Thomas



Sun Oct 19 2014 21:00:51 GMT+0200 (CEST), Martin Vigoureux:
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

M&T

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



_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess

Reply via email to