Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery

Jan Lindblad <janl@tail-f.com> Tue, 28 February 2017 10:49 UTC

Return-Path: <janl@tail-f.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0EF129501 for <l3sm@ietfa.amsl.com>; Tue, 28 Feb 2017 02:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ueMQg-7-H1OA for <l3sm@ietfa.amsl.com>; Tue, 28 Feb 2017 02:49:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2443F1294FE for <l3sm@ietf.org>; Tue, 28 Feb 2017 02:49:41 -0800 (PST)
Received: from [10.147.40.137] (unknown [173.38.220.34]) by mail.tail-f.com (Postfix) with ESMTPSA id 14E831AE02A7; Tue, 28 Feb 2017 11:49:37 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Jan Lindblad <janl@tail-f.com>
In-Reply-To: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk>
Date: Tue, 28 Feb 2017 11:49:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6747A53-4855-43CF-97DA-46B5C7F4A551@tail-f.com>
References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/54MSP9mNF-wP9VlRJ25tj3wXBfU>
Cc: l3sm@ietf.org
Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 10:49:43 -0000

A great achievement that I have long awaited, for sure!

I have some concerns with the resulting model, however, and I now (obviously) regret not looking at this earlier and taking part in the review process.

At ietf-l3vpn-svc.yang:2053 I find:

grouping site-devices {
  container devices {
   must "/l3vpn-svc/sites/site/management/type = "+
    "'provider-managed' or "+
    "/l3vpn-svc/sites/site/management/type = "+
    "'co-managed'" {
     description
      "Applicable only for provider-managed or co-managed device.";
    }

To me, it appears that the author intended to say that the "container device" configuration is only applicable when the current site management type is 'provider-managed' or 'co-managed'. That would make sense. 

The use of "must" and the use of the absolute paths above changes the meaning in YANG to "as soon as any l3vpn is configured, there must be at least one l3vpn (not necessarily the current one) that is 'provider-managed' or 'co-managed'." One implication would be that it would not be legal to have a collection of only 'customer-managed' vpns. What would be legal, though, is to have one 'provider-managed' l3vpn with no device configuration and another 'customer-managed' with devices configured. I expect this was not the intention.

This was something I noticed after spending a few minutes reading the model. Perhaps a YANG doctor review would be appropriate?

Best Regards,
/jan



> On 23 Feb 2017, at 11:15, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> Thanks to all of you for helping to complete this work.
> Special thanks (of course) to the authors and contributors.
> And massive thanks to Stephane who was relentless in making the minor edits for
> the many different phases of "final" review.
> 
> Adrian
> 
>> -----Original Message-----
>> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of rfc-editor@rfc-
>> editor.org
>> Sent: 23 February 2017 00:26
>> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
>> Cc: l3sm@ietf.org; drafts-update-ref@iana.org; rfc-editor@rfc-editor.org
>> Subject: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
>> 
>> A new Request for Comments is now available in online RFC libraries.
>> 
>> 
>>        RFC 8049
>> 
>>        Title:      YANG Data Model for L3VPN
>>                    Service Delivery
>>        Author:     S. Litkowski, L. Tomotaki, K. Ogaki
>>        Status:     Standards Track
>>        Stream:     IETF
>>        Date:       February 2017
>>        Mailbox:    stephane.litkowski@orange.com,
>>                    luis.tomotaki@verizon.com,
>>                    ke-oogaki@kddi.com
>>        Pages:      157
>>        Characters: 272974
>>        Updates/Obsoletes/SeeAlso:   None
>> 
>>        I-D Tag:    draft-ietf-l3sm-l3vpn-service-model-19.txt
>> 
>>        URL:        https://www.rfc-editor.org/info/rfc8049
>> 
>>        DOI:        10.17487/RFC8049
>> 
>> This document defines a YANG data model that can be used for
>> communication between customers and network operators and to deliver
>> a Layer 3 provider-provisioned VPN service.  This document is limited
>> to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
>> model is intended to be instantiated at the management system to
>> deliver the overall service.  It is not a configuration model to be
>> used directly on network elements.  This model provides an abstracted
>> view of the Layer 3 IP VPN service configuration components.  It will
>> be up to the management system to take this model as input and use
>> specific configuration models to configure the different network
>> elements to deliver the service.  How the configuration of network
>> elements is done is out of scope for this document.
>> 
>> This document is a product of the L3VPN Service Model Working Group of the
>> IETF.
>> 
>> This is now a Proposed Standard.
>> 
>> STANDARDS TRACK: This document specifies an Internet Standards Track
>> protocol for the Internet community, and requests discussion and suggestions
>> for improvements.  Please refer to the current edition of the Official
>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
>> standardization state and status of this protocol.  Distribution of this
>> memo is unlimited.
>> 
>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>> To subscribe or unsubscribe, see
>>  https://www.ietf.org/mailman/listinfo/ietf-announce
>>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>> 
>> For searching the RFC series, see https://www.rfc-editor.org/search
>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>> 
>> Requests for special distribution should be addressed to either the
>> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
>> specifically noted otherwise on the RFC itself, all RFCs are for
>> unlimited distribution.
>> 
>> 
>> The RFC Editor Team
>> Association Management Solutions, LLC
>> 
>> 
>> _______________________________________________
>> L3sm mailing list
>> L3sm@ietf.org
>> https://www.ietf.org/mailman/listinfo/l3sm
> 
> _______________________________________________
> L3sm mailing list
> L3sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l3sm
>