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
>