Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work

Benoit Claise <bclaise@cisco.com> Mon, 09 March 2015 13:53 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6A1A886D for <rtg-yang-coord@ietfa.amsl.com>; Mon, 9 Mar 2015 06:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkOX5lxm0QI5 for <rtg-yang-coord@ietfa.amsl.com>; Mon, 9 Mar 2015 06:53:04 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494381A8903 for <Rtg-yang-coord@ietf.org>; Mon, 9 Mar 2015 06:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42693; q=dns/txt; s=iport; t=1425908981; x=1427118581; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=q5x0EtFvtLcObxJX32sytcU4qFOZEOm6HZ8N5ktYYg8=; b=dBwGW7bOU6CqnJfy10bCXyuVTV4juGXZbZnm1SWXTDTCcDPgWPNVW0mG nRHMLzG4d4Kag+wOx8SFwd/wEepl1LT6Xtet2vPeyTA0Q6ArmfqgQnunP 0AYvXmoLcuehTTQdcVjL++k48ksLudu1KVc7iEG/RTFCGjGKmw698TZhS 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CvBABtpP1U/xbLJq1QCoJDgRVawkgZAQmFcAKBcQEBAQEBAXyEDwEBAQMBAQEBKkEKBgsLEQMBAQEKAxMBAQYHCQMCAQIBFAEfCQgGAQwFAQIBAQULiBMIDcNgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhAwGCgIBPhcBBoQnBZNzhW+BU4UijH8jgjKBPT0xgkMBAQE
X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="376482470"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Mar 2015 13:49:39 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t29DnbJl025755; Mon, 9 Mar 2015 13:49:37 GMT
Message-ID: <54FDA4DB.7010703@cisco.com>
Date: Mon, 09 Mar 2015 14:49:15 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, "'Susan Hares'" <shares@ndzh.com>, Rtg-yang-coord@ietf.org
References: <54F70B64.4010608@cisco.com> <54F70E24.5090400@cisco.com> <051101d05689$b6996980$23cc3c80$@ndzh.com> <037e01d05859$5bfb64c0$13f22e40$@olddog.co.uk>
In-Reply-To: <037e01d05859$5bfb64c0$13f22e40$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------070408080208020400030401"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/qeVBPXb_Z7MetUO58oC6vXggi_E>
Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 13:53:08 -0000

Hi Sue,

Sorry for the delay in getting back to you.
+1 to Adrian's answer.
As mentioned in the proposed charter:

    It needs to be clearly understood that this L3VPN service model is not an L3VPN
    configuration model. That is, it does not provide details for configuring
    network elements or protocols. Instead it contains the characteristics of the
    service, as discussed between the operators and their customers. A separate
    process is responsible for mapping this service model onto the protocols and
    network elements depending on how the network operator chooses to realise the
    service.

Regards, Benoit

> Hi Sue,
>
> As Stephane answered on the IDR list, the answer is "not exactly" :-)
>
> The intention here is protocol independence in that the model is not 
> (in its final form, but remember this is a working first draft) 
> considering the protocols or network elements used to deliver the 
> service. It is simply describing the service.
>
> A good example I have been discussing with the authors is failure 
> detection on the CE-PE link.
>
> This (IMHO) should not talk about the BFD transmission time. I think 
> it should talk about the maximum failure detection time, and leave the 
> operator to decide how to map that on to the various protocol and OAM 
> tools they have from their suppliers.
>
> So there will definitely be a secondary piece of work to figure out 
> how to map the abstract service definition to the protocols. I think 
> some of that will be vendor (hardware or software) secret sauce and 
> some may be standardised. Along the way this will inevitably point out 
> missing knobs and whistles in our protocols and our protocol 
> configuration tools.
>
> Adrian
>
> *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On 
> Behalf Of *Susan Hares
> *Sent:* 04 March 2015 14:44
> *To:* 'Benoit Claise'; Rtg-yang-coord@ietf.org
> *Subject:* Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the 
> L3VPN Service YANG Model work
>
> Benoit:
>
> Do you consider the L3VPN service a protocol dependent yang module or 
> a protocol independent module?
>
> Sue
>
> *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On 
> Behalf Of *Benoit Claise
> *Sent:* Wednesday, March 04, 2015 8:53 AM
> *To:* Rtg-yang-coord@ietf.org
> *Subject:* [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN 
> Service YANG Model work
>
> FYI.
>
> Regards, Benoit
>
>
>
> -------- Forwarded Message --------
>
> *Subject: *
>
> 	
>
> [L3sm] Some background on the L3VPN Service YANG Model work
>
> *Date: *
>
> 	
>
> Wed, 4 Mar 2015 14:40:52 +0100
>
> *From: *
>
> 	
>
> Benoit Claise <bclaise@cisco.com> <mailto:bclaise@cisco.com>
>
> *To: *
>
> 	
>
> l3sm@ietf.org <mailto:l3sm@ietf.org>
>
>
>
> Dear all,
>
> Let me give you some background on this new piece of work: The Layer 
> Three Virtual Private Network Service Model (L3SM)
>
> Three months ago, Adrian Farrel and I set up a design team to create a 
> L3VPN _service _YANG model.
> It needs to be clearly understood that this L3VPN _service _model is 
> not an L3VPN configuration model. That is, it does not provide details 
> for configuring network elements or protocols. Instead it contains the 
> characteristics of the service, as discussed between the operators and 
> their customers.  Therefore, that design team was composed of 
> operators only.
>
> That design team created a first draft: 
> http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/
> Now that the draft has been posted, the work and discussion should 
> continue in a public forum, i.e. this l3sm@ietf.org 
> <mailto:l3sm@ietf.org> mailing list.
>
> Next step? we're busy trying to create a new short-lived WG, focusing 
> solely on this L3VPN service YANG model.
> See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/
> If this WG is created (This proposal is on the IESG telechat this week 
> for external review approval), this would be a good test for the IETF 
> community: are we ready to standardize a first service YANG model? 
> Personally, I believe we are.
> IMO, the advantage/driver for this work is explained in the charter 
> proposal:
>
> The deliverable from this working group will provide information to evaluate the
> set of YANG models that have already been developed or are under development,
> and will help identify any missing models or details.  The deliverable can be
> viewed as driving requirements for protocol configuration model so that the
> service parameters can be mapped into inputs used by the protocol models.
>
> Don't hesitate to forward this email.
>     List address: l3sm@ietf.org <mailto:l3sm@ietf.org>
>     Archive: http://www.ietf.org/mail-archive/web/l3sm/
>     To subscribe: https://www.ietf.org/mailman/listinfo/l3sm
>
> Regards, Benoit
>
>