Re: [Teas] Discussion on modelling container TE tunnels in YANG
tom petch <ietfa@btconnect.com> Sun, 26 May 2019 11:54 UTC
Return-Path: <ietfa@btconnect.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21A4120124 for <teas@ietfa.amsl.com>; Sun, 26 May 2019 04:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 upaIXcIUIdT2 for <teas@ietfa.amsl.com>; Sun, 26 May 2019 04:54:34 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30106.outbound.protection.outlook.com [40.107.3.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A01812001E for <teas@ietf.org>; Sun, 26 May 2019 04:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j8Q6fiNPcIgqQu61AOOSe7sKt6ZCDeutf6UhLqdTleg=; b=cIM18g20lo2XBvi0cgz5jftOopTqLzCfZVdIPcS6ru/aic+ZAUVBDBBQldaVJY2UMI5h3KNNlMz4KAiVWjwKl11jugnvWePzMrQhLFXA4WXGxBXUY0BTFp03g6EIhNFoWw/rKHcxPVIF5/6SpxN3HGEq+f8NSdO6tCQxYaHcJQE=
Received: from AM0PR0702MB3732.eurprd07.prod.outlook.com (52.133.51.25) by AM0PR0702MB3587.eurprd07.prod.outlook.com (52.133.47.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Sun, 26 May 2019 11:54:31 +0000
Received: from AM0PR0702MB3732.eurprd07.prod.outlook.com ([fe80::38cd:6ef6:7d75:23c2]) by AM0PR0702MB3732.eurprd07.prod.outlook.com ([fe80::38cd:6ef6:7d75:23c2%7]) with mapi id 15.20.1943.007; Sun, 26 May 2019 11:54:31 +0000
From: tom petch <ietfa@btconnect.com>
To: Tarek Saad <tsaad.net@gmail.com>, Igor Bryskin <Igor.Bryskin@huawei.com>, Rakesh Gandhi <rgandhi@cisco.com>, Xufeng <xufeng.liu.ietf@gmail.com>, Vishnu Pavan Beeram <vbeeram@juniper.net>, Italo Busi <Italo.Busi@huawei.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Discussion on modelling container TE tunnels in YANG
Thread-Index: AQHVE7nF58tTWGO3v0advTEFJwt/kQ==
Date: Sun, 26 May 2019 11:54:30 +0000
Message-ID: <010901d513b9$35622680$4001a8c0@gateway.2wire.net>
References: <BN8PR06MB6289BC83144EDE01645F11F9FC020@BN8PR06MB6289.namprd06.prod.outlook.com> <BN8PR06MB6289FA104129CB51C4AD84D4FC020@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0470.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::26) To AM0PR0702MB3732.eurprd07.prod.outlook.com (2603:10a6:208:26::25)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfa@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8be2f75c-b9c2-4a62-f9aa-08d6e1d0e6bb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM0PR0702MB3587;
x-ms-traffictypediagnostic: AM0PR0702MB3587:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR0702MB3587E4D60F44AA0A68766A2FA21C0@AM0PR0702MB3587.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1728;
x-forefront-prvs: 0049B3F387
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(396003)(366004)(346002)(13464003)(199004)(189003)(476003)(6486002)(6512007)(9686003)(4720700003)(486006)(44736005)(73956011)(66946007)(66476007)(66556008)(66446008)(64756008)(7736002)(61296003)(446003)(52116002)(53936002)(86362001)(68736007)(86152003)(256004)(14454004)(99286004)(229853002)(305945005)(966005)(26005)(14496001)(6306002)(1941001)(81166006)(44716002)(5660300002)(81156014)(478600001)(71200400001)(8936002)(71190400001)(110136005)(8676002)(25786009)(84392002)(186003)(102836004)(2906002)(50226002)(53546011)(386003)(6506007)(81816011)(4326008)(6246003)(76176011)(1556002)(6436002)(3846002)(81686011)(66066001)(6116002)(316002)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3587; H:AM0PR0702MB3732.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CIdon9udXQMlSdyQK8QBlES0+ApdFTLz+9eBysTsf1SsScnWlWG7HmUqAxXGHgjc9J0DQlkxIYu4khcEZ4UqCK/5xncphX64jEwmjf2CUcpOlzeqghfd5B9M+NZIjuie9N0UEmey61CsRpIQ5pAk49iUXYsrXSQ4pKIvxL+RcCj0sKamdQ1nmwA4LftU8Ba2kmcE4DJEQ2siAfI/zPU7e9GF5dkgNKSj2cogJGKLODe9xlnUUTi8Y+E1lGly27j70mUWWjeulf4LPYD40PdJBmhlmA9aGITqVa19iUqLDQNvVN9+R/WUl0Xx8cpTdN1kYrK5eLypBxpe82jZIT4dfDXn0QBOasVJkBxU2hoRnyoAoOyQh++Zxk7qH5jJ3YwVHXYWLR34lKYi1ipGXTVRMX/kSAP6pvl6pA3wDbq6Yzk=
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7F2027F2024BE5498E640FA01FA2570C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8be2f75c-b9c2-4a62-f9aa-08d6e1d0e6bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2019 11:54:31.0171 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ietfa@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3587
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/MA_R7f5VxqofQwOw37EojCwMLkI>
Subject: Re: [Teas] Discussion on modelling container TE tunnels in YANG
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 May 2019 11:54:37 -0000
<inline> ----- Original Message ----- From: "Tarek Saad" <tsaad.net@gmail.com> Sent: Friday, May 24, 2019 10:13 PM Subject: [Teas] Discussion on modelling container TE tunnels in YANG The team on “to” list met to discuss this subject topic. Notes from today’s discussion (please add if I missed): Name collision between configured and ephemeral tunnels: This is a generic problem in NMDA. How to handle collisions between configured and ephemeral (or auto-created) objects of a list, if the list uses the object (string based) name as the key? Both configured and ephemeral can have the same object name but they are different objects – how to avoid such collision. Proposed solution: Option 1: Use a special character for ephemeral names – e.g. such names always are prepended by special character “#” Make the special character changeable by configuration – the default can be “#” and user can change if they desire.. Others? <tp. Tarek I am not sure if I understand the context here but if the ephemeral is a YANG name, then the constraint is Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No #, anywhere. More generally, the IETF has made extremely limited use of special characters to separate a class of identifiers, because names in the IETF - host, domain, SMI etc - have all used an extremely limited set of characters, a tradition that YANG has followed, wisely IMHO. If you are interfacing with humans, then limit yourself to what humans used to seeing, aA to zZ, 0 to 9 and practically nothing else (7-bit ASCII is far too complex:-). X- has been used and I would suggest something more on those lines, but it must be an either or; too often these semantic boundaries turn out to be fuzzy and it all ends in confusion - I do not understand the context enough to know what the future holds here. On inheritance, below, the general principle, which users may expect, is that the inherited object can acquire properties but not overwrite inherited ones - but then YANG set out not to have inheritance or be otherwise objec-oriented. Tom Petch AI (Italo): to send email to netmod group. Container TE tunnels discussion: * Container tunnels are grouping of tunnels between same 2 endpoints to share incoming traffic towards the egress * Member tunnels of a container tunnel can be auto-created/deleted on-demand and controlled by thresholds specified under the container * Some attributes may apply on the container tunnel and inherited down to member tunnels of the container * Q: Should model allow member tunnel to override inherited attributes from container tunnel? * Q: Should all auto-created member tunnels of a container have the same prefix/suffix – i..e prefix/suffix can be configurable Regards, Tarek ------------------------------------------------------------------------ -------- > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >