Re: [bess] WG adoption poll - draft-fang-l3vpn-virtual-pe-05

Benson Schliesser <> Thu, 23 October 2014 15:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E97D1ABD36 for <>; Thu, 23 Oct 2014 08:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgCQlFDG6ReK for <>; Thu, 23 Oct 2014 08:02:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCC881ABD3A for <>; Thu, 23 Oct 2014 08:02:50 -0700 (PDT)
Received: by with SMTP id q108so807489qgd.25 for <>; Thu, 23 Oct 2014 08:02:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VZIKwcOhDkixzJpOTDDvcyzkL5knkMnjKEDZ1PyLQJM=; b=mbXRc+lCBYl4kzwMQh4mY8amzQ+sSdXGunc8M7Wp5tnF4RlckBMeLyC+JSW8sj6uhJ XKr/XN96Q4D5zbNh/OGPdIVU668Ga61FSsF4vBD1txt/3ysuW+fbTGpAcl7fFeLLKcbW ig7EvohjP3Bq2+96/kyIVwSkCIe/QiYtzd/0edOOkEZX5kY+JBfTKQ0MBd8T8+FMMjru cn0BFthV37NGi6jKeTOcoC1pmCdSxgRZVycqleI3ye3tSgIWTaqLpBWdJYu9jRhfgDdT ThLIPzhgSZTh30VddYJQw0+eyE4SoZBnW2LotHwAGB45/GqJJZTJcz1AHuuhocN5sKQK CU2A==
X-Gm-Message-State: ALoCoQnRGRZQIbBgu6tNFRS0rgNsDExoecGXtkRnz8xUM9QZcTwGnoJ0Pw1NyXIHdb+VNa0gYht6
MIME-Version: 1.0
X-Received: by with SMTP id t111mr8269521qge.6.1414076569777; Thu, 23 Oct 2014 08:02:49 -0700 (PDT)
Received: by with HTTP; Thu, 23 Oct 2014 08:02:49 -0700 (PDT)
Received: by with HTTP; Thu, 23 Oct 2014 08:02:49 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 23 Oct 2014 11:02:49 -0400
Message-ID: <>
Subject: Re: [bess] WG adoption poll - draft-fang-l3vpn-virtual-pe-05
From: Benson Schliesser <>
To: Thomas Morin <>
Content-Type: multipart/alternative; boundary=001a11c15d7ea0e3990506185b4f
Cc: L3VPN <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Oct 2014 15:03:01 -0000

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.

On Oct 22, 2014 10:12 AM, "Thomas Morin" <> 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]
> _______________________________________________
> BESS mailing list