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

Igor Bryskin <Igor.Bryskin@huawei.com> Tue, 15 January 2019 12:26 UTC

Return-Path: <Igor.Bryskin@huawei.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 9172B130E58 for <teas@ietfa.amsl.com>; Tue, 15 Jan 2019 04:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jvd1WrGeR3rL for <teas@ietfa.amsl.com>; Tue, 15 Jan 2019 04:26:55 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C1840130DE9 for <teas@ietf.org>; Tue, 15 Jan 2019 04:26:54 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9E9368D67BBD032C448D for <teas@ietf.org>; Tue, 15 Jan 2019 12:26:52 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 15 Jan 2019 12:26:52 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.25]) by SJCEML703-CHM.china.huawei.com ([169.254.5.133]) with mapi id 14.03.0415.000; Tue, 15 Jan 2019 04:26:48 -0800
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "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>
Thread-Topic: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules
Thread-Index: AQHUrLF+MRSI9pFT0EemCcHxg8dUFqWwQccq
Date: Tue, 15 Jan 2019 12:26:47 +0000
Message-ID: <etPan.5c3dd203.5c1b45c5.2232@localhost>
References: <38a2168c-b23d-0324-c058-72ce000a84b4@orange.com>
In-Reply-To: <38a2168c-b23d-0324-c058-72ce000a84b4@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan5c3dd2035c1b45c52232localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/tyi_LdPZ-EzQDL1GxaKDussslB0>
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: Tue, 15 Jan 2019 12:26:57 -0000

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
To:TEAS WG,
Cc:LE ROUZIC Esther TGI/OLN,ahmed.triki@orange.com,
Date:2019-01-15 04:05:43
Subject:[Teas] Types within ietf-te-path-computation and ietf-te-types Modules

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
https://www.ietf.org/mailman/listinfo/teas