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

Hi Julien, Igor,

I completely share the idea 1) to share src/dst type with node-id type . As co-author, the alignment in path-computation draft to proposed definitions in te-types is one of the item we need to check carefully for next meeting .

Thanks

Sergio

From: Teas <teas-bounces@ietf.org> On Behalf Of Igor Bryskin
Sent: Tuesday, January 15, 2019 3:13 PM
To: Igor Bryskin <Igor.Bryskin@huawei.com>; julien.meuric@orange.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,

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
To:julien.meuric@orange.com,teas@ietf.org,
Cc:esther.lerouzic@orange.com,ahmed.triki@orange.com,
Date:2019-01-15 07:27:22
Subject:Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

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