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

Julien Meuric <julien.meuric@orange.com> Tue, 15 January 2019 09:05 UTC

Return-Path: <julien.meuric@orange.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 0DD08130E1C for <teas@ietfa.amsl.com>; Tue, 15 Jan 2019 01:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no 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 S-1JwWDFCt31 for <teas@ietfa.amsl.com>; Tue, 15 Jan 2019 01:05:16 -0800 (PST)
Received: from p-mail-ext.rd.orange.com (p-mail-ext.rd.orange.com [161.106.1.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DC130DEA for <teas@ietf.org>; Tue, 15 Jan 2019 01:05:16 -0800 (PST)
Received: from p-mail-ext.rd.orange.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6CBA956161B for <teas@ietf.org>; Tue, 15 Jan 2019 10:04:58 +0100 (CET)
Received: from p-mail-int.rd.francetelecom.fr (p-mail-int.rd.francetelecom.fr [10.192.117.12]) by p-mail-ext.rd.orange.com (Postfix) with ESMTP id 66A8D561390 for <teas@ietf.org>; Tue, 15 Jan 2019 10:04:58 +0100 (CET)
Received: from p-mail-int.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 22C44181983; Tue, 15 Jan 2019 10:05:00 +0100 (CET)
Received: from [10.193.71.36] (l-5c-26-a-89-3d-9f.rd.francetelecom.fr [10.193.71.36]) by p-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id 0138C18195B; Tue, 15 Jan 2019 10:04:59 +0100 (CET)
From: Julien Meuric <julien.meuric@orange.com>
To: TEAS WG <teas@ietf.org>
Cc: "ahmed.triki@orange.com" <ahmed.triki@orange.com>, LE ROUZIC Esther TGI/OLN <esther.lerouzic@orange.com>
Organization: Orange
Message-ID: <38a2168c-b23d-0324-c058-72ce000a84b4@orange.com>
Date: Tue, 15 Jan 2019 10:04:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.1.15.85716, AntiVirus-Engine: 5.56.1, AntiVirus-Data: 2019.1.15.5561001
X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1700_1799 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, LEGITIMATE_SIGNS 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FROM_DOMAIN_IN_ANY_CC1 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/kQJtJL9JqYrqtnTQHwYgU0DSZJc>
Subject: [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 09:05:19 -0000

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.