Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

Giles Heron <> Tue, 22 November 2016 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68E2E129622 for <>; Tue, 22 Nov 2016 05:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O14UOouZux57 for <>; Tue, 22 Nov 2016 05:28:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CB73129503 for <>; Tue, 22 Nov 2016 05:28:53 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS));
From: Giles Heron <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8AB95596-4DAC-4804-B9AE-2841AA8EF261"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Tue, 22 Nov 2016 13:28:48 +0000
In-Reply-To: <>
To: David Ball <>
References: <0d4501d24132$62ceb590$286c20b0$> <> <0f1f01d241a7$959b1c00$c0d15400$> <>
X-Mailer: Apple Mail (2.3251)
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
Archived-At: <>
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Nov 2016 13:28:56 -0000

Hi David,

> On 21 Nov 2016, at 09:38, David Ball <> wrote:
> Hi Adrian,
> On 18/11/2016 14:25, Adrian Farrel wrote:
>> But let's quickly jump from that discussion to try to understand the way forward
>> you would like to see. Clearly you think changes to the document are needed and
>> it sounds like everyone agrees that that is true. And that sounds (to me) like
>> you believe we have a document we can work with to serve as a basis for updates.
>> What isn't obvious to me is why you don't think that the working group should
>> have control of this discussion and the changes to the document. What do you
>> propose?
> Fundamentally, given the amount of work needed on this document, it's not clear to me that taking it as a basis for the WG work is the least-effort option; we should as a minimum consider alternatives - e.g. starting from scratch, or using the MEF modules as a basis (I believe MEF have recently liaised their in-progress work to IETF).
agreed.   I think we need to stand back and look at what needs to be in an L2VPN service model and then compare that to this draft and to the MEF work (perhaps without going as far as a formal requirements draft).

and I think we should perhaps consider a layered approach where we have:
a) technology-specific models for PWE-based VPWS/VPLS and for EVPN, which expose the internal details of the protocols (e.g. PW IDs, BGP RTs/RDs to the layer above) and which can be used as components in more complex end-to-end models (e.g. PWE access to an L3VPN).
b) technology-neutral but still resource-facing service models for e.g. E-Line and E-LAN which can be implemented using PWE, EVPN, L2TPv3, Ethernet VLANs, wet string etc.
c) customer-facing service models with constructs such as customer info/account number etc.

Were we to take the layered approach I’d suggest that IETF be responsible for (a), MEF for (b) and the individual service provider for (c) (though there may be value in standardising some of the customer-facing stuff to enable multi-provider orchestration etc.) 

within the context of (a) we should also look to maximise reuse between the L2VPN and L3VPN models (e.g. using common groupings for BGP RTs/RDs etc., using common site definitions etc.)

we may also want to consider whether we look to augment the I2RS network and topology models rather than creating models from scratch.   The “N” in “VPN” stands for “Network” after all.   That also gives us a potential approach to exposing the dependencies between layers (a), (b) and (c) by using the “supporting-“ network/node/link concepts.

> I also really would like to hear from the authors - their document may be useful in its own right (just not aligned with the WG charter), so it may be that they want to proceed with it in that direction, as an individual draft.  Of course that doesn't stop the WG "forking" it, but one might imagine the authors would be less inclined to participate in the WG in that case.
>     David
> -- 
> David Ball
> <> <>_______________________________________________
> L2sm mailing list