[Teas] Discussion on modelling container TE tunnels in YANG

Tarek Saad <tsaad.net@gmail.com> Fri, 24 May 2019 21:13 UTC

Return-Path: <tsaad.net@gmail.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 F0E51120316 for <teas@ietfa.amsl.com>; Fri, 24 May 2019 14:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xYoi5CvYH56o for <teas@ietfa.amsl.com>; Fri, 24 May 2019 14:13:18 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F317112030A for <teas@ietf.org>; Fri, 24 May 2019 14:13:17 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id d128so6788128vsc.10 for <teas@ietf.org>; Fri, 24 May 2019 14:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Kcy8UU0EePlEpyEQiBTil/RjyQG+VCdb6H3D7odbtGs=; b=gcQjUF7EHKUKgzRoUPCEFJWqRiBxvbuN5PaiTRPx3h/PdiL9c7zp1XbEZ5KN35Dh+N w/mW7iJnixlXp1KwRY3M7xrTYMCUXS6OVXFaG3dSIMtu04Egzke/xZh0uO89ArCCyRWv Oruhtz2CYEbiTHyiIQt0BDKOy79Q6i4Dc6i+9qj+2OLV8a35M9ZXHixQefQF/5r5JGeW xoZxEMd2h0NSmMVGYwJWMEhZY5O2sAAsyMkhvd4QyX2mqZGhjZRIRlIPIcsWcRXKMM6v fSGyUHpTXTy83yrwyQhW01j3Wx2y/3Umwv4J4AqlFpIDh/7cix+D7TxPRtdCJHtHA/sh AIIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=Kcy8UU0EePlEpyEQiBTil/RjyQG+VCdb6H3D7odbtGs=; b=PWWxyUg3yleEztugJAKjlp5eRzYk9YGjlnqCly4+owm4dH8fZ9TOZ9bmTo9z/2YzN0 wKoBvb9+cj5FW0SHvCbwNCo2w9+pZB6Rz/5cy/SlyLDmT//9QXkiF2BDwWmveKPTHoId Rx+zjzWRUtQ2rdzkGpFwbqgPOJUbRT1eKyJruKAv7XeR59W05seQqnDPdZYw9qqwpGsc JY46kK25+gKkT3W/hXtybg5rkSlirQwKAA8hA7by6dwdSkvlcVdYCPMIfqvhFoaILhfx rpwy1sf37+FuA9NO/iVDRRkNEiMsDIzXssEPYjoEfPMEnBgjScymYt6hA0Igt2nv/mkL g3uA==
X-Gm-Message-State: APjAAAV5sXA/blKYYGv4/QovlbJNW7du7iFf1xG7yhNNcnMpCaJUFBJG GHsSqpZPKSMDqC0/8dTmCpo=
X-Google-Smtp-Source: APXvYqzs70bBdyToQS4rww6xMqQ7B9ol+mj4mdGFohjj+AT0ky3teuL7DaeeyFPbt+ctRx9Np2Fc6w==
X-Received: by 2002:a05:6102:3d9:: with SMTP id n25mr4136500vsq.181.1558732397054; Fri, 24 May 2019 14:13:17 -0700 (PDT)
Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id g135sm2049735vkd.51.2019.05.24.14.13.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 14:13:16 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: 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: Discussion on modelling container TE tunnels in YANG
Thread-Index: AQHVEnWANoIpbvacKka8hA+QimISzg==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 24 May 2019 21:13:16 +0000
Message-ID: <BN8PR06MB6289FA104129CB51C4AD84D4FC020@BN8PR06MB6289.namprd06.prod.outlook.com>
References: <BN8PR06MB6289BC83144EDE01645F11F9FC020@BN8PR06MB6289.namprd06.prod.outlook.com>
In-Reply-To: <BN8PR06MB6289BC83144EDE01645F11F9FC020@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BN8PR06MB6289FA104129CB51C4AD84D4FC020BN8PR06MB6289namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Gp28apJC-845sTUev3uGaLtulXY>
Subject: [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: Fri, 24 May 2019 21:13:20 -0000

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?
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