Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

"Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com> Fri, 18 January 2019 08:40 UTC

Return-Path: <sergio.belotti@nokia.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 6460013116B for <teas@ietfa.amsl.com>; Fri, 18 Jan 2019 00:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.452
X-Spam-Level:
X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 8UsrQR4C4QLV for <teas@ietfa.amsl.com>; Fri, 18 Jan 2019 00:40:02 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50122.outbound.protection.outlook.com [40.107.5.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008EB130F7B for <teas@ietf.org>; Fri, 18 Jan 2019 00:39:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mM4cIgh8wHmtDiRkP/GSlp+oZE5wV//NYcD5K5mN5WY=; b=ZQu2dSpqvTsq8uN/Vp/HAXxNZKucnGZFjfLPY5coXy5gcdXqHnH+y/2dniw5Zoyr9cL8TLbr4GufBK+i2u1jRbuhMeiYWM1GOQk2R7Qt6VtPIACaWxwB8+8dOwQcytT2brFM7D/09MeUQhl3FigPAwUZW6/MaK8b/ot5PelGqcQ=
Received: from AM0PR07MB5921.eurprd07.prod.outlook.com (20.178.83.29) by AM0PR07MB4193.eurprd07.prod.outlook.com (52.133.60.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.18; Fri, 18 Jan 2019 08:39:54 +0000
Received: from AM0PR07MB5921.eurprd07.prod.outlook.com ([fe80::d46c:f820:830b:8cc9]) by AM0PR07MB5921.eurprd07.prod.outlook.com ([fe80::d46c:f820:830b:8cc9%6]) with mapi id 15.20.1558.010; Fri, 18 Jan 2019 08:39:54 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "julien.meuric@orange.com" <julien.meuric@orange.com>, "teas@ietf.org" <teas@ietf.org>
CC: "esther.lerouzic@orange.com" <esther.lerouzic@orange.com>, "ahmed.triki@orange.com" <ahmed.triki@orange.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>
Thread-Topic: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules
Thread-Index: AQHUrLF1Ib2A5vq+vkm4QN/hXN8bcqWwQceAgAAdqYCAAUiLgIAANFOAgALbJhA=
Date: Fri, 18 Jan 2019 08:39:54 +0000
Message-ID: <AM0PR07MB59212DE755A64C1CB4756B63919C0@AM0PR07MB5921.eurprd07.prod.outlook.com>
References: <38a2168c-b23d-0324-c058-72ce000a84b4@orange.com> <etPan.5c3dd203.5c1b45c5.2232@localhost> <etPan.5c3dead0.76c532e5.48f3@localhost>, <216f71fd-6cc0-ce1a-7da8-0adc4b38da98@orange.com> <etPan.5c3f2a50.63ff74c0.f8f@localhost>
In-Reply-To: <etPan.5c3f2a50.63ff74c0.f8f@localhost>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [93.36.178.236]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4193; 6:p8O0/BljotSvLC1kWeq0sZmzRrfZc317FIvmVcs/g4c+z5CeP486N737W4mFP8f7VQFUlk4/4UKHE06MihbbxLRpGGUatY++nnbBeXjWEGMn0sceyUuXVMW2fFysIRwhBLRKGhM8WOAiZcLFidfpJGKiQBZVFWQUrd8bODSjq9hbxF6Y97nqbVfuBeBIs1YU6iwNf2evCQZ2LNp/hL0HhtvrX7594xXe+st9M44iUNP7cONjixfabZUHIX68D2lLPbQX8e4d61GiYZnUZTGIQIOWKvvB0ReBpvm6eLUaUK8vd8xWwCoZWcc9RZGpSEFKDVNvbay6xQpHZSXKaml0lHmQ+nrpNtWsrtb2J7TVBbd2XauYf5jaBIxpLgl4MzcuZmxJW2x+7lS+rkGRKIDjr3BETtE4KappynBxR/l4Y0AxsaqiBAArXXiOBCykBboeqn5g5XxIQaQKQLPGg49jsA==; 5:t/hs0D0UQ8iwwFl4oiv0lSEup7J+BPSkJ7fiMyPkOynVRkrKa/AyML7BjwLRzNsV47N9GMEAfIbnSeuvwvwL1GQXge+SCW8Jv9T5jio3n67sAHJFbXLGuNy9stfw+8lQGw9pCkbz1l1kknCZnPhYgSCOrvdnIHZRXERGAIZqtEAN5ad3ULGsizbLtfUdpnUzWwKxIIeShFFH9jZsUXw1bg==; 7:tmclNWdZI151Fs8cFAeBQHMh1u/C9vluZLbBaoAyABVso1ZaEKOMN9zYJinztksI5uIoU7IdlEkPORd34VBW3S1bMWGjcP/DYEiJ7jInupHuEy5p6Zm60+Y63kv6J4DCClfrsdBl09/37SdTOgdmdQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4390df0e-d2b7-459b-774d-08d67d208506
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4193;
x-ms-traffictypediagnostic: AM0PR07MB4193:
x-microsoft-antispam-prvs: <AM0PR07MB4193AFBBE1057487C2B59AE0919C0@AM0PR07MB4193.eurprd07.prod.outlook.com>
x-forefront-prvs: 0921D55E4F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(396003)(136003)(346002)(189003)(199004)(53754006)(37854004)(54906003)(110136005)(316002)(68736007)(2906002)(81166006)(74316002)(81156014)(71190400001)(7736002)(8676002)(71200400001)(5660300001)(8936002)(14454004)(478600001)(97736004)(966005)(6436002)(55016002)(86362001)(2201001)(9326002)(33656002)(66574012)(229853002)(2501003)(11346002)(9686003)(105586002)(486006)(446003)(102836004)(236005)(476003)(25786009)(6306002)(54896002)(4326008)(99286004)(6506007)(53546011)(53386004)(106356001)(7696005)(6246003)(76176011)(53936002)(3846002)(6116002)(606006)(790700001)(66066001)(93886005)(256004)(14444005)(186003)(6346003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4193; H:AM0PR07MB5921.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: WAw0y2eY08Ts1j1CYPV2HjTaOalmRmwEX4Ei8PI3wLrhrgO4HOeggUNpHYFKRnLVjOY0aPC+bgiso3S1YOxWymOef7wNAghgqZD9E2C1MaPKPaIpjkTMbwebeNGNt6UuoEh6B+DJ8b9+Onm+Z597uMTv1kSGcm8nzGM9pyPwVaiZHFcE4FHALTlI2DqZSi4ZmM9GkgQIVZxSpAV/FWfPDIWSmXY7+cVKTHY98sVQFz4YnIi5V/DlQDu07UKDhexKj/8JXZVePwSb3ALXkX9zLT9EL5j1rLVwnbvFUv2QstgBtzYhJLN1bAx/QVJr7Abp/YN/s/LvLDJ4+YEmBD2NUyjUsumcLoCokmLu7rFDJIOGnkQKHdSZZ1U+Nxxl+0DRW7n2/mi/Q317dArVZ1hGkAxKAk6acu9NpOTXEVQq/UA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB59212DE755A64C1CB4756B63919C0AM0PR07MB5921eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4390df0e-d2b7-459b-774d-08d67d208506
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2019 08:39:54.2732 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4193
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/TggTOby4w1D0I7VrNuIxDo2zNTk>
Subject: Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules
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, 18 Jan 2019 08:40:07 -0000

Hi Igor,
I think Julien is not arguing about the need or not to have a routable address but on the fact that ,at the moment, te-types in the description of te-node-id mention RFC 6119 that means a 128-bit format.


"typedef te-node-id {
    type yang:dotted-quad;
    description
      "A type representing the identifier for a node in a TE
       topology.
       The identifier is represented as 32-bit unsigned integer in
       the dotted-quad notation.
       This attribute MAY be mapped to the Router Address described
       in Section 2.4.1 of [RFC3630], the TE Router ID described in
       Section 3 of [RFC6827], the Traffic Engineering Router ID
       described in Section 4.3 of [RFC5305], or the TE Router ID
       described in Section 3.2.1 of [RFC6119].
       The reachability of such a TE node MAY be achieved by a
       mechanism such as Section 6.2 of [RFC6827].";


Cheers
Sergio

From: Teas <teas-bounces@ietf.org>; On Behalf Of Igor Bryskin
Sent: Wednesday, January 16, 2019 1:56 PM
To: julien.meuric@orange.com; Igor Bryskin <Igor.Bryskin@huawei.com>;; teas@ietf.org
Cc: esther.lerouzic@orange.com; ahmed.triki@orange.com
Subject: Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Julien,

To your A2.1:

te-node-id (a property of a te topology node) is conceptually different/orthoganal  from TE-router-id ( a property of a TE enabled routing protocol speaker). There are many reasons to this, to name a couple:
1. Tthere could be TE networks (especially in cs layers) that are run without routing protocols;
2. TE topology could be abstract with a te-node representing an arbitrary segment of the underlay network.

TE routing is just one way (albeit important) a te topology could be discovered/managed and the RFCs you mentioned are as important for te topologies as,say, RSVP RFCs are important for te tunnels, i.e. we can onlly talk about reference points and convenience of
implementaion of popular use cases, but not something that needs to be comformant to universally.

To your B1.1:

Tunnel termination point normally represents a physical device where a TE tunnel is terminated, its clients are adoptrd, etc. (e.g. WDM transponder) with a certain phyisical address, which may or may not fit in 64, 128, etc. bit, hence the type is defined as binary. On the other  hand, link termination point (or tp per I2RS topology model) is a numbered or unnumbered identifier of a link terminated on a node. There is no need for sharing types between the two because they are totally unrelated.


Cheers,
Igor

From:Julien Meuric
To:Igor Bryskin,teas@ietf.org,
Cc:esther.lerouzic@orange.com,ahmed.triki@orange.com,
Date:2019-01-16 04:49:41
Subject:Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Igor,

A.1. I'm glad we agree on using the "te-node-id" type in both places.

A.2. I am not questioning the fact that an ID does not need to be a
routable address; I am just saying that there are (Standard Track) RFCs
that defines 128-bit TE Router IDs (e.g., RFC 6119 section 4.1, as
mentioned below) and the definition of "te-node-id" imported from
"te-types" cannot overlook that (this could be another thread directed
to the authors of ietf-te-types).

B.1. I agree that a tunnel TP is different from a link TP; I do not
suggest to use the same name on these leaves. However, both should point
to the "te-tp-id" space (instead of binary). If you believe there are
some missing encodings in "te-tp-id", what are they?

B.2. It is fine to have 2 different types such as "te-node-id" and
"te-tp-id" (as within the RO part in the tree below), we are in sync on
that.

Cheers,

Julien


On 15/01/2019 15:12, Igor Bryskin wrote:
> Hi Julien,
>
> Two more comments from me and Italo:
> 1.To <http://1.To> align src/dst type with the node-id type is a good
> idea;
> 2. As widely discussed, TE node id, generally speaking, is not
> (pingable) IP address, nor it is a routing protocol  router ID , just
> a number that identifys node uniquely in the TE topology the node
> belongs to, hence uint32 is sufficient.
>
> Cheers,
> Igor
> *From:*Igor Bryskin
> *Date:*2019-01-15 07:27:22
>
> Hi Julien,
>
> 2 comments:
> 1.src (dst)-tp-id below means src/dst tunnel termination point, which
> is different from flink-tp-id below, which menas link termination
> point, i.e. place where a numbered/unnumbered link is terminated on a
> node;
> 2. We discussed a lot and believe that node-id sub-object should be
> different from numbered link-id sub-object ( as per current RSVP and
> PCEP) because there are use cases where one needs to distinguish node
> from link in ERO without necessarily looking into topology infotmation..
>
> Cheers,
> Igor
> *From:*Julien Meuric
> *Date:*2019-01-15 04:05:43
>
> Hi all,
>
> A colleague of mine has started to implement some pieces of the
> ietf-te-path-computation Yang module. He has already bumped into a
> couple of inconsistencies that are worth sharing.
>
> In this module, we have:
>
> +---- path-request* [request-id]
> |  +---- ...
> |  +---- source?                   inet:ip-address
> |  +---- destination?              inet:ip-address
> |  +---- src-tp-id?                binary
> |  +---- dst-tp-id?                binary
> |  +---- ...
> |  +---- explicit-route-objects
> |  |  +---- route-object-exclude-always* [index]
> |  |  |  +---- index            uint32
> |  |  |  +---- (type)?
> |  |  |     +--:(num-unnum-hop)
> |  |  |     |  +---- num-unnum-hop
> |  |  |     |     +---- node-id?      te-types:te-node-id
> |  |  |     |     +---- link-tp-id?   te-types:te-tp-id
> |  |  |     |     +---- ...
>
> In the above, the types associated to source/destination and x-tp-id are
> different between the request level and the RO level. This leads us to 2
> fixes to consider on this document:
> - src-tp-id/dst-tp-id should mimic link-tp-id and reuse te-tp-id instead
> of binary;
> - source/destination and node-id should share a common type (any reason
> they would not?).
>
> What is more, te-node-id is currently defined in ietf-te-types as 32-bit
> only, whereas the references it mentions include 128-bit format; e.g.
> RFC 6119 (section 3.2.1.) says: "it is useful to have a stable IPv6
> address identifying a TE node. The IPv6 TE Router ID TLV is defined in
> Section 4.1."
> Fixing te-types:te-node-id is a prerequisite to fully solve the 2nd
> issue above.
>
> Thanks,
>
> Julien, et al.
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org<mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org<mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas