Re: [Rtg-yang-coord] Routing YANG Design Team Scope

Rob Shakir <rjs@rob.sh> Mon, 27 July 2015 10:40 UTC

Return-Path: <rjs@rob.sh>
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 548C21B2ABB; Mon, 27 Jul 2015 03:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 7Lvu3OSHTubr; Mon, 27 Jul 2015 03:39:58 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD7B1B2C3A; Mon, 27 Jul 2015 03:38:53 -0700 (PDT)
Received: from [94.197.121.212] (helo=piccolo.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1ZJfne-0008Nm-MM; Mon, 27 Jul 2015 11:38:27 +0100
Date: Mon, 27 Jul 2015 11:38:57 +0100
From: Rob Shakir <rjs@rob.sh>
To: "Acee Lindem (acee)" <acee@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Message-ID: <etPan.55b60a41.3b25a484.755b@piccolo.local>
In-Reply-To: <D1DAB06D.298C6%acee@cisco.com>
References: <D1DAB06D.298C6%acee@cisco.com>
X-Mailer: Airmail Beta (309)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55b60a41_6b0a26b0_755b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/gxC7sjlzsbg04Pd8fDvNV-srQx4>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, YANG Doctors <yang-doctors@ietf.org>, "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, Lou Berger <lberger@labn.net>, Loa Andersson <loa@pi.nu>
Subject: Re: [Rtg-yang-coord] Routing YANG Design Team Scope
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Jul 2015 10:40:01 -0000

My assumption, and understanding of the ask that the ADs put to the DT, is that the routing design team should consider usability of YANG models from a routing perspective, and not constrain itself on essentially arbitrary IETF-boundaries.

If the output of the DT means that we need cross-area review to further its work as any form of standard, or document that the IETF would choose to commit to RFC - then engagement with the relevant area should be sought, of course.

I am very much opposed to considering that point parts of a solution should be set as constraints on anything that can be done relating to network management going forward.

I have a feeling that this opinion may not be aligned with that of the netmod working group - it needs to be openly discussed as to what the best technical solution is, rather than calling foul on ‘scope’ related discussions.

Thanks for your consideration,
r.




On 26 July 2015 at 20:50:41, Acee Lindem (acee) (acee@cisco.com) wrote:

Juergen,  

Since this E-mail thread is about the hierarchy and granularity of MPLS  
models, I’m somewhat confused by your response. Nevertheless, I’ve updated  
the subject line to correspond to your concern.  

Our assumption is that the Routing YANG design team will attempt to use  
the existing models but will not be constrained by them. However, I agree  
that any changes or augmentations to the existing NETMOD RFCs would need  
to be reviewed in the NETMOD WG.  

Thanks,  
Acee  

On 7/26/15, 3:24 PM, "Juergen Schoenwaelder"  
<j.schoenwaelder@jacobs-university.de> wrote:  

>Dear Acee,  
>  
>please note that the interfaces model plus the IP model plus the core  
>system model plus the SNMP configuration model the IETF agreed on are  
>defined in RFC 7223, RFC 7277, RFC 7317, and RFC 7407. All these RFCs  
>were produced by the NETMOD working group. Work is starting in other  
>SDOs to extend these models. Hence, I think any attempts to replace  
>them with something different should not only be discussed on the  
>NETMOD list but also seek support from the NETMOD working group.  
>  
>Note that https://www.ietf.org/mailman/listinfo/rtg-yang-coord says:  
>  
> The rtg-yang-coord mailing list will provide a forum for  
> coordination of the development of YANG models being worked on for  
> Routing, in order to provide a consistent view to the NMS.  
>  
>It seems some of the content of draft-rtgyangdt-rtgwg-device-model-00  
>seems to leave the routing scope.  
>  
>/js  
>  
>On Sun, Jul 26, 2015 at 06:48:10PM +0000, Acee Lindem (acee) wrote:  
>> Hi Mahesh,  
>>  
>> Please comment on  
>>https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ as  
>>this is the latest view of the design team.  
>>  
>> Thanks,  
>> Acee  
>>  
>> From: Rtg-yang-coord  
>><rtg-yang-coord-bounces@ietf.org<mailto:rtg-yang-coord-bounces@ietf.org>>  
>> on behalf of Mahesh Jethanandani  
>><mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>  
>> Date: Sunday, July 26, 2015 at 4:31 PM  
>> To: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>  
>> Cc: Routing YANG  
>><rtg-yang-coord@ietf.org<mailto:rtg-yang-coord@ietf.org>>, YANG Doctors  
>><yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>>, Loa Andersson  
>><loa@pi.nu<mailto:loa@pi.nu>>  
>> Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg  
>>  
>> Lou,  
>>  
>> I like the approach taken in the draft  
>>draft-openconfig-mpls-consolidated-model. In particular, the approach  
>>represented in this tree model makes sense to me.  
>>  
>>  
>> +--rw mpls!  
>> +--rw global  
>> | ...  
>> +--rw te-global-attributes  
>> | ...  
>> +--rw signaling-protocols  
>> | ...  
>> +--rw lsps  
>> ...  
>>  
>>  
>> However, by its own admission, the draft says:  
>>  
>>  
>> This model does not aim to be feature complete (i.e., cover all  
>> possible aspects or features of MPLS).  
>>  
>> My suggestion would be for the MPLS WG to take up the model structure  
>>as represented above and to do a more complete work of including all  
>>features of MPLS, e.g. GMPLS.  
>>  
>> Thanks.  
>>  
>> Mahesh Jethanandani  
>> mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>  
>>  
>>  
>>  
>>  
>>  
>  
>> _______________________________________________  
>> Rtg-yang-coord mailing list  
>> Rtg-yang-coord@ietf.org  
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord  
>  
>  
>--  
>Juergen Schoenwaelder Jacobs University Bremen gGmbH  
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany  
>Fax: +49 421 200 3103 <http://www.jacobs-university.de/>  

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord