Re: [Teas] Te-topology and te data models questions

Anton Snitser <antons@sedonasys.com> Wed, 23 October 2019 13:19 UTC

Return-Path: <antons@sedonasys.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 646C51208FE for <teas@ietfa.amsl.com>; Wed, 23 Oct 2019 06:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, 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=sedonasys.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 pvSIyp4r3zOQ for <teas@ietfa.amsl.com>; Wed, 23 Oct 2019 06:19:15 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055FD1208EB for <teas@ietf.org>; Wed, 23 Oct 2019 06:19:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=naGTBU4OOqL53AdCjOxPTcN2EnSnvmXl/0kSnQnxgdkhGxlAhzddhbEUgtw1bQt+kXHxpTASZqdpqDObVj3Skb5rX+sMZdgVuNQmrkwmRhJcjG5CAlEsl7l1z9Tm0kprzwmZ/ED+KPr9YMd1Nivi9V9U6UVPugMFy9vKRogSvyrnxfQ0r9s6PEGp2NkCTWjcTmoTTGF981/H8aORHuW95qAuHA/dValafu70rj8d9H43aGMD1tRG1aRQy3wim7wd2cyUlLIGfqn4GN4F8qNKE5soEQDbsUI3xbzDqScpz0QqKLFvZjbJTewvXgJfZ+weqlXY1GkitHH+ApstjYwF3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=alEckHSxUUyXkiQBSg7802d/0UudC9z10yTn+QG6VWs=; b=MJ772f+GkKugVynGmYIv9QkmIumb7WPUdycnshX9n8QdAYYm9sHO3Bk19XnH1I67sel/9byphT4AsjYG4bf4o7mAgBWU7iUjOrX2aodEycryGTYFLvu/uKGTfwopuLX/fi0rb3iHU8rLuRt6BghhISVcCWDCLMYkaIen7Lgi0hDO9pCwZkAUy80IZ5UdlsSYYHoYvM7X/QwP7XiOn6GtIAK3WBw3Q+jUhcB+sfiza/JwEbh2k7XBCxzLETfPgkN1/9IytoTC333jwHLzRqOkafUJfS1/hlptgCAiVMAOCbLPoV3yKwTOryHOy4sdR9Dry954iITL8vChFHNQt86/0g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sedonasys.com; dmarc=pass action=none header.from=sedonasys.com; dkim=pass header.d=sedonasys.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sedonasys.onmicrosoft.com; s=selector2-sedonasys-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=alEckHSxUUyXkiQBSg7802d/0UudC9z10yTn+QG6VWs=; b=ZbCQ7NEm6PZakQWjVXY6B+Rq6qujuXIWKbPo9Dd5bJIQvqqU4hmEF13kIuuamSngH4PPfdqA7jNQgP3F9WYz4qvXFKG/Vof97aS2bwkwKobU9DYNoa2KHl+cwyz4Vu9CWAcLiVcTkq3Vo5tuD/cREuwc3fGJHWPtgpOJJmR8XD4=
Received: from DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM (10.255.17.204) by DB8PR10MB3578.EURPRD10.PROD.OUTLOOK.COM (10.186.164.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Wed, 23 Oct 2019 13:19:12 +0000
Received: from DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM ([fe80::50ed:4f45:c83c:20ce]) by DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM ([fe80::50ed:4f45:c83c:20ce%5]) with mapi id 15.20.2367.025; Wed, 23 Oct 2019 13:19:11 +0000
From: Anton Snitser <antons@sedonasys.com>
To: Igor Bryskin <i_bryskin@yahoo.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Te-topology and te data models questions
Thread-Index: AQHViMcitca1lXHc9k6nIr+9y4jXzadmsfcAgAG3rYA=
Date: Wed, 23 Oct 2019 13:19:11 +0000
Message-ID: <95D8350C-7BC7-4D5C-8558-B94023E3513F@sedonasys.com>
References: <E317D9F6-D881-4F9B-8640-C3E5F6E25EEC@sedonasys.com> <2022179508.357497.1571753131017@mail.yahoo.com>
In-Reply-To: <2022179508.357497.1571753131017@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=antons@sedonasys.com;
x-originating-ip: [37.142.40.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 79d80e22-26b7-4b94-68d4-08d757bb981b
x-ms-traffictypediagnostic: DB8PR10MB3578:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DB8PR10MB35788D6A132C2CD786536969D76B0@DB8PR10MB3578.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 019919A9E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39830400003)(366004)(376002)(346002)(396003)(189003)(199004)(53754006)(110136005)(76116006)(86362001)(45080400002)(66446008)(6506007)(7066003)(81166006)(6436002)(256004)(6486002)(33656002)(606006)(733005)(316002)(66946007)(91956017)(66576008)(66556008)(53546011)(25786009)(14444005)(66476007)(64756008)(14454004)(508600001)(9326002)(36756003)(8676002)(102836004)(2501003)(966005)(5660300002)(6246003)(66574012)(446003)(99286004)(186003)(54896002)(6512007)(66066001)(8936002)(11346002)(476003)(99936001)(2616005)(229853002)(71190400001)(71200400001)(3846002)(790700001)(486006)(7736002)(6116002)(26005)(81156014)(236005)(6306002)(76176011)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8PR10MB3578; H:DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: sedonasys.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 88abjPA2VVCs2LxUGnGFg2cF30Dpmypf8DwB0d4sbUXVFYx/BccvDo4tQ0ymBqSXssh8hcSGdKMutZmrPARs/SkNnwrdmOC1wPt5CYK9s6rgI8Maxj4ZAsXaNs/dbTzGWPU8x/guc0SWBDdZ+J7HCADmmhkj28zT8+BbtEXtCbB5+gfClrNjB6m5kIFA+IABtA7n5CCELEwZosY1n+N0K8u4bRMCARpFpMs1FUtI1Q5n8NHrcyCcIfz5sJl25AgE3XTbuyuCDc5gOzKtVYWII/TUk37lCOxmPxI/Iqp0SIoqYE6oFYHtDFYsklyKeKXMA79LG4NUjPC0oJtD3A79Xmqh7PC+RcTf2BAdRpDLXvqIwJeZxg7M0a44aCuBcRV6HJBYz7YROCbNJNCJpvI4mCgYp+QBBIzfgseG6NQ9LFOAAR4LcZJ0y01g4rJWogmIzsxFcQveb9jlYuwoP+shA+kou4yfbaKFUx5yp+HsoLQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_95D8350C7BC74D5C8558B94023E3513Fsedonasyscom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: sedonasys.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79d80e22-26b7-4b94-68d4-08d757bb981b
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 13:19:11.6769 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d7c5624d-c76e-473e-9a79-91d374431ce8
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lPyVGYZN4sfYGNg1UwSpzbEBF92h4mCu6s7p7Z0b2vKW3cGWQyx7Xq2pcWwzvEo6cpBSrJt1Bm5YXCUwWPuC0w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR10MB3578
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/pwz1evD8Wiaf5u4UUE3Y0jtKVHI>
Subject: Re: [Teas] Te-topology and te data models questions
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: Wed, 23 Oct 2019 13:19:18 -0000

Hi Igor,

Thank you for the prompt reply. Will sum up your responses here to reference.
Thank you for taking the time to respond!

General question – is this distribution ok with this much chatter? Or should we limit?


  1.  IB >> Correct. Transitional link is a special link modeling an inter-layer relationship. Specifically, it connects a client layer LTP with a server layer TTP and may articulate a cost of adding additional links in the server layer to satisfy  path computation request in the client layer. Transitional link is only useful  in multi-layer computations. Alternative to transitional link is inter-layer lock.

[AS] to avoid confusion on my part, in the draft it states it connects client layer LTP to server layer LTP. Is that correct? Or your “it connects a client layer LTP with a server layer TTP” is the correct interpretation?



  1.  IB >> No, in your case the link from the router is a regular TE link and belongs to OTN, while transitional link is inside WDM device (where OTN to WDM adaptation actually occurs)
[AS] is there no adaptation done in the OTN device as well? Taking the IP Ethernet frame adapting to ODU? Or a transitional-link can only occur in the WDM device?



  1.  IB >> TTP, generally speaking,  represents a device inside a TE node where a particular client-server layer adaptation (different in some way from other client-layer adaptations in the same node) occurs.  Normally, IP layer TE nodes do not have/requite TTPs, unless it is an abstract node, in which case the TTP may indicate, for example,  the physical router where TE tunnel (described on abstract IP topology) terminates.

[AS] ok understood, but in any case if supposedly one needs to portray a native topology of IP routers how does one describe the TTP? Asking because in one supporting data model ietf-te for management and maintenance of TE-Tunnels (where tunnels can be IP/MPLS LSPs, ODU Tunnels, OCH/OTSi Tunnels) TTPs are used as src and dst. in an IP topology what would those TTPs be? The devices/routers themselves?



  1.  [AS] I have some assumptions based on the existing data modules produced from both TEAS and I2RS, wondering if you can confirm on them and shed some light. Apologies in advance if questions refer to data models produced in other WG, maybe you can answer to the best you know.

  1.  Te-topo and augmentations of te-topo are not necessarily used for pure topology depiction for generic purposes. Its main goal is to allow a client to have an abstracted understanding of the network to complete path computation and path setup if necessary. Correct?
  2.  Referring back to a. when I mean pure topology discovery, I mean sometimes a client will need to have a complete view of topology down to port to port connectivity through all the layers to understand traffic patterns and complete physical path routes. This is not part of the mandate of te-topo right?
  3.  The way I2RS data models are portraying multi-layer topology relation is by using supporting-network/node/link/ltp attributes whereas in TEAS data models these same attributes are used more in order to show relation between nodes in case abstraction is used to show node within node. is this the same to your knowledge?
  4.  If all of the above are somewhat true and the mandate for the TEAS WG is to provide “just enough” topology data (native or otherwise) across layers IP/OTN/WDM to be able to compute paths and set them up then there should be another set of augmentations (one for each technology layer including OTN and WDM) to provide native topology data model – similar to the tech specific l2 and l3 unicast topology augmentation which came from I2RS. Correct?

Best regards!

From: Igor Bryskin <i_bryskin@yahoo.com>
Date: Tuesday, 22 October 2019 at 17:05
To: "teas@ietf.org" <teas@ietf.org>, Anton Snitser <antons@sedonasys.com>
Subject: Re: [Teas] Te-topology and te data models questions

Hi Anton,

Thank you for the interest, review and questions Please, find in line.

Cheers,
Igor

On Tuesday, October 22, 2019, 6:55:07 AM EDT, Anton Snitser <antons@sedonasys.com> wrote:



Hello everyone,



Name is Anton, am a systems engineer from Sedona systems.



I have been reviewing the ietf-te.yang and ietf-te-topology.yang data models as well as their various augmentations and I had a few questions regarding how they are meant to be used when representing native network state and managed objects. Not sure if this Is the correct email group. Saw it in the drafts, decided to try.



  1.  What is the usage scope of transitional links? – it is meant to represent an inter-layer transition between different layers, but as peC the diagrams In the drafts I have only seen it being used in the same
  2.
  3.   IB>>Correct. Transitional link is a special link modeling an inter-layer relationship. Specifically, it connects a client layer LTP with a server layer TTP and may articulate a cost of adding additional links in the server layer to satisfy  path computation request in the client layer. Transitional link is only useful  in multi-layer computations. Alternative to transitional link is inter-layer lock.
  4.
  5.  Can transitional links be used inter layer to describe a cross-layer-link in a technology disaggregated environment? E.g., a router port <-> OTN client-port and subsequently the OTN to WDM cross-layer-links. consider each layer node as a separate physical node e.g., physical router, OTN switch and WDM node
  6.
  7.  IB>> No, in your case the link from the router is a regular TE link and belongs to OTN, while transitional link is inside WDM device (where OTN to WDM adaptation actually occurs)





Consider the following.

[cid:FXfQrsJTThIbe5xRDO6d]
Is it possible to describe a link where a source node:tp from the IP topology and a destination node:tp from the OTN/WDM topology create a transitional link. IB>> No, see above



  1.  Are there strict guidelines on how a TTP should be modeled? In the drafts it is mentioned a TTP can be an OCH transponder in the WDM topology. What about OTN and IP? What are the rules used to designate a physical/logical entity as a TTP or non-TTP entity?

     *   Can an IP loopback on routers be considered a TTP? If not then what is a TTP in the IP layer?
     *   What is a TTP in the OTN layer? Is it the framing module in the switch?

  1.  IB>> TTP, generally speaking,  represents a device inside a TE node where a particular client-server layer adaptation (different in some way from other client-layer adaptations in the same node) occurs.  Normally, IP layer TE nodes do not have/requite TTPs, unless it is an abstract node, in which case the TTP may indicate, for example,  the physical router where TE tunnel (described on abstract IP topology) terminates.



  1.  The figures are missing from the tutorial draft<https://tools.ietf.org/html/draft-ietf-teas-te-topo-and-tunnel-modeling-04>. Is there a reference implementation document somewhere?



  1.  I have more questions, but I wanted to start slow.. to see there I get an ACK response.





Thank you very much to whoever answers!

Brgrds



[id:image001.png@01D3D4EC.AFD81260]

Anton Snizar | Systems Engineer


m: +972-504042744

e: antons@sedonasys.com<mailto:antons@sedonasys.com>

w: sedonasys.com<https://sedonasys.com/>

l: Linkedin<http://linkedin.com/in/anton-snizar-4aa57646/>


_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas