Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules
Julien Meuric <julien.meuric@orange.com> Wed, 16 January 2019 09:49 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 24291130E0A for <teas@ietfa.amsl.com>; Wed, 16 Jan 2019 01:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, URIBL_BLOCKED=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 6CaryRlkAGFH for <teas@ietfa.amsl.com>; Wed, 16 Jan 2019 01:49:09 -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 56504130DF1 for <teas@ietf.org>; Wed, 16 Jan 2019 01:49:09 -0800 (PST)
Received: from p-mail-ext.rd.orange.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 630BA5615A7; Wed, 16 Jan 2019 10:48:51 +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 5E1D55615A5; Wed, 16 Jan 2019 10:48:51 +0100 (CET)
Received: from p-mail-int.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 19F68181A07; Wed, 16 Jan 2019 10:48:53 +0100 (CET)
Received: from [10.193.71.36] (l-at13891.rd.francetelecom.fr [10.193.71.36]) by p-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id 1A1E81819C9; Wed, 16 Jan 2019 10:48:52 +0100 (CET)
From: Julien Meuric <julien.meuric@orange.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Cc: "esther.lerouzic@orange.com" <esther.lerouzic@orange.com>, "ahmed.triki@orange.com" <ahmed.triki@orange.com>
References: <38a2168c-b23d-0324-c058-72ce000a84b4@orange.com> <etPan.5c3dd203.5c1b45c5.2232@localhost> <etPan.5c3dead0.76c532e5.48f3@localhost>
Organization: Orange
Message-ID: <216f71fd-6cc0-ce1a-7da8-0adc4b38da98@orange.com>
Date: Wed, 16 Jan 2019 10:48:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <etPan.5c3dead0.76c532e5.48f3@localhost>
Content-Type: text/plain; charset="windows-1252"
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.16.93916, AntiVirus-Engine: 5.56.0, AntiVirus-Data: 2019.1.3.5560002
X-PMX-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FROM_DOMAIN_IN_ANY_CC1 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 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, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_NS_SERVFAIL , __URI_WITHOUT_PATH 0, __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Bgx6SsxsspV2fA3GErzVFH6U6DA>
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: Wed, 16 Jan 2019 09:49:14 -0000
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 > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas
- [Teas] Types within ietf-te-path-computation and … Julien Meuric
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Types within ietf-te-path-computation … Julien Meuric
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … tom petch
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … tom petch
- Re: [Teas] Types within ietf-te-path-computation … Igor Bryskin
- Re: [Teas] Types within ietf-te-path-computation … tom petch