Re: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-routing-types

Xufeng Liu <xliu@kuatrotech.com> Mon, 14 November 2016 06:54 UTC

Return-Path: <xliu@kuatrotech.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CCC1295AC; Sun, 13 Nov 2016 22:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com
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 CHKrjv2n6Wkx; Sun, 13 Nov 2016 22:54:27 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0078.outbound.protection.outlook.com [104.47.1.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE591129420; Sun, 13 Nov 2016 22:54:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5IZ9iERcv8fOpgjx5DMydqZhBKC46tCibvIBpWm6Q64=; b=mUe/62rCZxf/mTTVbkkSAy534vHJdrUG9+iLMmb6LRhEWzjag5tzFjAUUlN9BpMVLweY9ktzX6Ygljgar3DIAks1f5OQgioXQarcqeoQ83wQOqYeWuhsrgLtGjJGQinyFYhtKjQQ/r/+HtVgUP2aipN54OqBxyeVjjS/rKvVla8=
Received: from AM5PR0601MB2641.eurprd06.prod.outlook.com (10.168.154.138) by AM5PR0601MB2643.eurprd06.prod.outlook.com (10.168.154.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 06:54:22 +0000
Received: from AM5PR0601MB2641.eurprd06.prod.outlook.com ([10.168.154.138]) by AM5PR0601MB2641.eurprd06.prod.outlook.com ([10.168.154.138]) with mapi id 15.01.0721.010; Mon, 14 Nov 2016 06:54:23 +0000
From: Xufeng Liu <xliu@kuatrotech.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "draft-rtgyangdt-rtgwg-routing-types@ietf.org" <draft-rtgyangdt-rtgwg-routing-types@ietf.org>
Thread-Topic: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-routing-types
Thread-Index: AQHSPiRptM+kOP0i2U+usr4iFeZV+aDYB3QAgAADlCA=
Date: Mon, 14 Nov 2016 06:54:22 +0000
Message-ID: <AM5PR0601MB26416E88F257550D12648C92B1BC0@AM5PR0601MB2641.eurprd06.prod.outlook.com>
References: <7c9884b6-f786-22af-0ab1-5b410ae5237d@cisco.com> <20161114063938.GA45227@elstar.local>
In-Reply-To: <20161114063938.GA45227@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=xliu@kuatrotech.com;
x-originating-ip: [2001:67c:370:128:e03b:a650:a18e:3b0c]
x-microsoft-exchange-diagnostics: 1; AM5PR0601MB2643; 7:DwnrlFpruzuFRCoX826NdSav6SsF3VfQxMMdE382kY4qPgImVVuxlVGzoMqEAJE1SWY6oW4LdUYjfUcj3IXJ7YQtFferNan/w2qs2Lqf/NNlJR1S4bup1cGmc5ZN363p4L4RHvRVDs4si0v/l/U52H1XAZmTRZTO20p5LixGVkR0Nhz5YaMhh/ckYcolwIy25otY7Na059CNwhUl4+4abQmE5ubS27GxDhxJQg1Ld3/0aDe13Yt7chnV8JIn5aG+IccmKkI/NEKt/iP3yfVdhCgvVetUW8rQ9cS9vzOv0XFjjGPr4p+HyFgoMIwilKm5GIvt4hmz0OGEi6f72yX6ntdhhJsBWNtCcbWyxTxGhqw=
x-ms-office365-filtering-correlation-id: 5ce8750f-9777-4b86-b6a9-08d40c5b10d7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0601MB2643;
x-microsoft-antispam-prvs: <AM5PR0601MB2643F9C0591EFD6F98102708B1BC0@AM5PR0601MB2643.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060322)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6061317)(6043046); SRVR:AM5PR0601MB2643; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0601MB2643;
x-forefront-prvs: 0126A32F74
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(336003)(199003)(13464003)(24454002)(377454003)(189002)(2501003)(2900100001)(101416001)(68736007)(76576001)(7696004)(15188155005)(33656002)(230783001)(189998001)(77096005)(54356999)(7846002)(86362001)(92566002)(105586002)(16799955002)(106356001)(76176999)(3660700001)(9686002)(74316002)(50986999)(2950100002)(7736002)(8676002)(97736004)(87936001)(305945005)(6116002)(102836003)(586003)(122556002)(5001770100001)(106116001)(3280700002)(15395725005)(2906002)(229853002)(81166006)(5660300001)(8936002)(81156014)(4326007)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0601MB2643; H:AM5PR0601MB2641.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: kuatrotech.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: kuatrotech.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 06:54:22.7880 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0601MB2643
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-yang-coord/eqdONlZK0M5b2MRjzGr9EeVcZq8>
Cc: Benoit Claise <bclaise@cisco.com>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "Joe Clarke \(jclarke\)" <jclarke@cisco.com>, "lime@ietf.org" <lime@ietf.org>, "Rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>
Subject: Re: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-routing-types
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.17
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, 14 Nov 2016 06:54:29 -0000

I hesitated to include these types because I thought that inet-types could be a better place for them. Do we now agree to cover them in routing-types?

Thanks,

- Xufeng

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Monday, November 14, 2016 1:40 AM
> To: draft-rtgyangdt-rtgwg-routing-types@ietf.org
> Cc: Benoit Claise <bclaise@cisco.com>;; lime@ietf.org; <rtg-ads@ietf.org>; <rtg-
> ads@ietf.org>;; Rtg-yang-coord@ietf.org; Joe Clarke (jclarke)
> <jclarke@cisco.com>;
> Subject: Re: [Rtg-yang-coord] LIME connection-less draft-rtgyangdt-rtgwg-
> routing-types
> 
> Another option could be to reuse the definitions from ietf-inet-types and to
> subtype them to constrain them to multicast addresses. Also double check that
> you will never ever need a zone index.
> 
> /js
> 
> On Mon, Nov 14, 2016 at 12:08:31PM +0900, Benoit Claise wrote:
> > draft-rtgyangdt-rtgwg-routing-types authors,
> >
> > I see the following typedef in draft-ietf-lime-yang-connectionless-oam
> >
> >      typedef IPv4-Multicast-Group-Address {
> >             type string {
> >              pattern '(2((2[4-9])|(3[0-9]))\.)'
> >                          +'(([0-9]|[1-9][0-9]|1[0-9][0-9]|'
> >                          +'2[0-4][0-9]|25[0-5])\.){2}'
> >                          +'([0-9]|[1-9][0-9]|1[0-9][0-9]'
> >                          +'|2[0-4][0-9]|25[0-5])';
> >             }
> >             description
> >               "The IPv4-Multicast-Group-Address type
> >                represents an IPv4 multicast address
> >                in dotted-quad notation.";
> >             reference "RFC4607 <https://tools.ietf.org/html/rfc4607>";;
> >       } // typedef IPv4-Multicast-Group-Address
> >       typedef IPv6-Multicast-Group-Address {
> >             type string {
> >             pattern
> >                         '(((FF|ff)[0-9a-fA-F]{2}):)([0-9a-fA-F]'
> >                         +'{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?'
> >                         +'(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4]'
> >                         +'[0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|'
> >                         +'2[0-4][0-9]|[01]?[0-9]?[0-9])))';
> >             pattern
> >             '(([^:]+:){6}(([^:]+:[^:]+)|'
> >                         +'(.*\..*)))|((([^:]+:)*[^:]+)'
> >                         +'?::(([^:]+:)*[^:]+)?)';
> >              }
> >             description
> >                         "The IPv6-Multicast-Group-Address
> >                         type represents an IPv6 address in full,
> >                         mixed, shortened, and shortened-mixed
> >                         notation.";
> >             reference "RFC4291 <https://tools.ietf.org/html/rfc4291>  2.7.
> >             ietf-inet-types:ipv6-address";
> >       }
> >       typedef IP-Multicast-Group-Address {
> >             type union {
> >               type IPv4-Multicast-Group-Address;
> >               type IPv6-Multicast-Group-Address;
> >             }
> >
> >             description
> >              "The IP-Multicast-Group-Address type
> >               represents an IP multicast address and
> >               is IP version neutral. The format of the
> >               textual representations implies the IP version.";
> >       } // typedef IP-Multicast-Group-Address
> >
> >
> > It's probably a good idea to introduce those typedefs in your draft,
> > for everybody's interest.
> > Now, hopefully, your draft will be published very soon. We can't delay
> > other doc publications.
> >
> > Also, look at this new tool, developed during this hackathon (new
> > tool, so bare with us):
> > http://yangcatalog.org/yang-search/yang-search.php
> > You should do a couple of searches with specific keywords.
> > For example, I searched on "multicast" and typedef.
> >     Note: we get some hits from YANG modules generated from MIB. Not
> > sure how useful that is.
> > We want to make sure there are no discrepancies in the typedef, and
> > that the typedef definitions are not spread around in too many documents.
> >
> > Regards, Benoit
> >
> >
> 
> > _______________________________________________
> > 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/>