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

From: Julien Meuric <[email-masked]>
Date: Tue, 15 Jan 2019 10:04:59 +0100

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.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 15 Jan 2019 12:26:47 +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,[email-masked],
Date:2019-01-15 04:05:43
Subject:[Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi all,

In this module, we have:

Thanks,

Julien, et al.

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 15 Jan 2019 14:12:57 +0000

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:[email-masked],[email-masked],
Cc:[email-masked],[email-masked],
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:

Cheers,
Igor
From:Julien Meuric
To:TEAS WG,

Hi all,

In this module, we have:

Thanks,

Julien, et al.

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 15 Jan 2019 14:39:41 +0000

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 <[email-masked]> On Behalf Of Igor Bryskin
Sent: Tuesday, January 15, 2019 3:13 PM
To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Julien,

Cheers,
Igor
From:Igor Bryskin

Hi Julien,

2 comments:

Cheers,
Igor
From:Julien Meuric
To:TEAS WG,

Hi all,

In this module, we have:

Thanks,

Julien, et al.

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Julien Meuric <[email-masked]>
Date: Wed, 16 Jan 2019 10:48:51 +0100

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:
> 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,
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jan 2019 12:56:07 +0000

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,[email-masked],
Cc:[email-masked],[email-masked],
Date:2019-01-16 04:49:41
Subject:Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Igor,

Cheers,

Julien

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Fri, 18 Jan 2019 08:39:54 +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 <[email-masked]> On Behalf Of Igor Bryskin
Sent: Wednesday, January 16, 2019 1:56 PM
To: [email-masked]; Igor Bryskin <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric

Hi Igor,

Cheers,

Julien

On 15/01/2019 15:12, Igor Bryskin wrote:
> from link in ERO without necessarily looking into topology infotmation..
>
> Cheers,
> Igor
> *From:*Julien Meuric

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Jan 2019 14:27:38 +0000

Hi Sergio,

AFAIK Top level TE RTR TLV of V2/3 OSPF -TE role is to advertise bindings of the advertising RouterID to one or more TERouterIDs, each of which could be either 32 or 128 bit long, hence there is a way to map a 128b long TE RouterID to 32b long te node id ( as specified by te-types). If I am correct, there is no issue with the description. if I am wrong we should not mention the RFC.

IMHO there is no need for 128 TE Router ID (unless it is assumed always to be IPv6 address, which is not), because it is difficult to envision a TE topology so large that unt32 is not sufficient to identify all its nodes.

Cheers,
Igor
From:Belotti, Sergio (Nokia - IT/Vimercate)
To:Igor Bryskin,[email-masked],[email-masked],
Cc:[email-masked],[email-masked],Tarek Saad (tsaad),
Date:2019-01-18 03:40:16
Subject:RE: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

Hi Igor,

“typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric

Hi Igor,

Cheers,

Julien

---

From: tom petch <[email-masked]>
Date: Sun, 20 Jan 2019 12:07:47 +0000

----- Original Message -----
From: "Belotti, Sergio (Nokia - IT/Vimercate)"
<[email-masked]>
Sent: Friday, January 18, 2019 8:39 AM

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.

<tp>

No it doesn't.  As your extract below shows, the reference is to
Section 3.2.1 of [RFC6119].
Go read it, it only defines a 32-bit stable IPv4 address; like the other
references, 32 bits rules ok!

Where TE might have problems is with a box that is:
- TE
- IPv6 only, no IPv4
- supports both LSR protocols
- wants to follow the advice that the two LSR protocols should use the
same identifier so that information can be correlated.

OSPF then has
Router Address 32-bit, no structure no semantics, the identifier
Router IPv6 Address 128-bit in TLV Type 3

while the other LSR protocol  has
IPv6 TE Router ID 128-bit TLV type 140.

so the two identifiers for the two LSR protocols would appear to be
irreconcilable.

This is a TE issue, not a modelling one; if the TE is in a seemingly
impossible situation, then the YANG module too will be in a seemingly
impossible situation and it is the TE that needs to be resolved first
before the YANG module can be.

Tom Petch

"typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

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
Date:2019-01-16 04:49:41

Hi Igor,

Cheers,

Julien

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 20 Jan 2019 16:00:53 +0000

Hi Tom,

Lets consider Ipv6 only network. Why in your opinion one would  ever nesd a 128b long TE Router ID? This would be necessary only if TE Router ID is one of the router's  global IP addresses. But we seem to agree that TE Router  needs to be neither IP address nor be global (just a TE topology unique, and there could be more than one TE topologies any given router could be part of with a separate TE Router ID/ te-node ID). And there are also, of course,  abstact TE topologies, where TE Router IDs are meaningless, while te-node IDs are meaningful.

My question is can you thInk of a practical use case that requires 128b TE Router ID?

Probably is worth noting that In the te-topology modeling design team we have both CSCO and JNPR folks. None of them  has ever raised any issues with 32b long te-node IDs AFAIK.

Cheers,
Igor

From:tom petch
To:Belotti, Sergio (Nokia - IT/Vimercate),Igor Bryskin,[email-masked],[email-masked],
Cc:[email-masked],[email-masked],Tarek Saad (tsaad),
Date:2019-01-20 07:07:59
Subject:Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

----- Original Message -----

Hi Igor,

<tp>

OSPF then has

Tom Petch

"typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric
Date:2019-01-16 04:49:41

Hi Igor,

Cheers,

Julien

---

From: tom petch <[email-masked]>
Date: Tue, 22 Jan 2019 11:13:44 +0000

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
Sent: Sunday, January 20, 2019 4:00 PM

Hi Tom,

Lets consider Ipv6 only network. Why in your opinion one would  ever
nesd a 128b long TE Router ID? This would be necessary only if TE Router
ID is one of the router's  global IP addresses. But we seem to agree
that TE Router  needs to be neither IP address nor be global (just a TE
topology unique, and there could be more than one TE topologies any
given router could be part of with a separate TE Router ID/ te-node ID).
And there are also, of course,  abstact TE topologies, where TE Router
IDs are meaningless, while te-node IDs are meaningful.

My question is can you thInk of a practical use case that requires 128b
TE Router ID?

<tp>

Igor

I am very happy to always have a 32 bit TE Router ID but the RFC would
appear not to allow it.

By IPv6 only, I mean no IPv4! i.e. the node has not got a routable IPv4
address.

According to RFC5305, s.4.3, TLV134,

'   The router ID TLV contains the 4-octet router ID of the router ...'
' it guarantees that we have a single stable address that can always be
referenced in a path that will be reachable...'
' If a router implements traffic engineering, it MUST include this TLV
in its LSP.  '

This seems impossible; there is no reachable IPv4 address so it cannot
form TLV134 yet it MUST include a TLV134 which must then be invalid.

RFC6119 IPv6 TE does not update this text in RFC5305 and says
'   The TE Router ID TLV contains a stable IPv4 address that is
routable,
   regardless of the state of each interface. '
Again, no stable IPv4 address so this TLV should not be sent.  RFC6119
adds the possibility of
' The IPv6 TE Router ID TLV is TLV type 140.
  The IPv6 TE Router ID TLV contains a 16-octet IPv6 address.  A stable
   global IPv6 address MUST be used '

so the least bad outcome, for a box with IPv6 connectivity but no IPv4
conectivity, would appear to be to omit TLV134 and include TLV140.

That is my logic.  I am not involved with writing code for this but see
this elephant someway down the line and the need to define te-node-id in
te-types, and the post that started this thread, seems to make it come
closer.

Tom Petch

Probably is worth noting that In the te-topology modeling design team we
have both CSCO and JNPR folks. None of them  has ever raised any issues
with 32b long te-node IDs AFAIK.

Cheers,
Igor

From:tom petch
To:Belotti, Sergio (Nokia - IT/Vimercate),Igor
Bryskin,[email-masked],[email-masked],
Cc:[email-masked],[email-masked],Tarek Saad (tsaad),
Date:2019-01-20 07:07:59
Subject:Re: [Teas] Types within ietf-te-path-computation and
ietf-te-types Modules

----- Original Message -----

Hi Igor,

<tp>

OSPF then has

Tom Petch

"typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric
Date:2019-01-16 04:49:41

Hi Igor,

Cheers,

Julien

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Jan 2019 15:02:02 +0000

Hi Tom,

As you know YANG modeling makes no use of TLVs, hence in order to satisfy RFC5305 we would have to define te_node_id and numbered te_link_id as 128b. This would significantly increase client-server TE related information flow (especially TE tunnel EROs/RROs, each of which could potentially contain hundreds of hops/elements) with no practical justification, which would be a waste.
Furthermore, as mentioned earlier, the TE client-server relationships and information flows are orthogonal to the TE routing flooding and, strictly speaking, TE YANG model attributes do not need to comply bluntly to TE routing RFCs TLVs. For example, a IPv6 only TE routing speaker may still assign a 32b te-node_id to every 128b TE router ID it has learned via routing before conveying TE topology info to its clients.

Igor  

-----Original Message-----
From: tom petch [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2019 6:14 AM
To: Igor Bryskin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Types within ietf-te-path-computation and ietf-te-types Modules

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
Sent: Sunday, January 20, 2019 4:00 PM

Hi Tom,

<tp>

Igor

Tom Petch

Cheers,
Igor

From:tom petch

----- Original Message -----

Hi Igor,

<tp>

OSPF then has

Tom Petch

"typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric
Date:2019-01-16 04:49:41

Hi Igor,

Cheers,

Julien

---

From: tom petch <[email-masked]>
Date: Thu, 24 Jan 2019 16:48:25 +0000

---- Original Message -----
From: "Igor Bryskin" <[email-masked]>
Sent: Wednesday, January 23, 2019 3:02 PM

Hi Tom,

As you know YANG modeling makes no use of TLVs, hence in order to
satisfy RFC5305 we would have to define te_node_id and numbered
te_link_id as 128b. This would significantly increase client-server TE
related information flow (especially TE tunnel EROs/RROs, each of which
could potentially contain hundreds of hops/elements) with no practical
justification, which would be a waste.
Furthermore, as mentioned earlier, the TE client-server relationships
and information flows are orthogonal to the TE routing flooding and,
strictly speaking, TE YANG model attributes do not need to comply
bluntly to TE routing RFCs TLVs. For example, a IPv6 only TE routing
speaker may still assign a 32b te-node_id to every 128b TE router ID it
has learned via routing before conveying TE topology info to its
clients.

<tp>

Igor,

mmm I think I understand, so if others are happy with the current
wording, then it works for me.

The interesting part lies in the future, since te-types is a module to
be imported and used by others and it will be interesting to see if
those users expect to be able to use a 128bit type as well as a 32bit
one; time will tell.

Tom Petch

Igor

-----Original Message-----
From: tom petch [mailto:[email-masked]]
Sent: Tuesday, January 22, 2019 6:14 AM
To: Igor Bryskin; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Types within ietf-te-path-computation and
ietf-te-types Modules

----- Original Message -----
From: "Igor Bryskin" <[email-masked]>
Sent: Sunday, January 20, 2019 4:00 PM

Hi Tom,

<tp>

Igor

Tom Petch

Cheers,
Igor

From:tom petch

----- Original Message -----

Hi Igor,

<tp>

OSPF then has

Tom Petch

"typedef te-node-id {
    type yang:dotted-quad;
    description

Cheers
Sergio

Hi Julien,

To your A2.1:

To your B1.1:

Cheers,
Igor

From:Julien Meuric
Date:2019-01-16 04:49:41

Hi Igor,

Cheers,

Julien