>From the BESS Charter I see "The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP"
There are two virtual PE models I am aware of. The first is the multi-tenant model that does not change operations at all, merely moves the VPN function as is from a physical device to a virtual device. The second is the single tenant model, which is a PE per customer location. The difference this model introduces is an explosion in the nmber of PEs and the associated building of router reflector hierarchies. Neither, as far as I can see require any changes to the BGP protocol. Certainly there are some new ways to provision things (orchestration). As a new participant to this group I may be missing much and need to be educated. However if the group is about extending BGP to support new services I am unclear why a virtual PE demands something new and if it does, should not the draft specify that? Chris On Oct 23, 2014, at 10:02 AM, Benson Schliesser <[email protected]> wrote: > 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]> 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] > https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess
