Support for IPv6

[dhruvdhody]

In the TE Model we have:

   leaf source {
      type te-types:te-node-id;
      description
        "TE tunnel source node ID.";
    }
    leaf destination {
      type te-types:te-node-id;
      description
        "TE tunnel destination node identifier.";
    }

In Te-Types:

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 4 octets in dotted-quad
       notation.
       This attribute MAY be mapped to the Router Address TLV
       described in Section 2.4.1 of RFC 3630, the TE Router ID
       described in Section 3 of RFC 6827, the Traffic Engineering
       Router ID TLV described in Section 4.3 of RFC 5305, or the
       TE Router ID TLV described in Section 3.2.1 of RFC 6119.
       The reachability of such a TE node MAY be achieved by a
       mechanism such as that described in Section 6.2 of RFC 6827.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
       Version 2, Section 2.4.1
       RFC 5305: IS-IS Extensions for Traffic Engineering,
       Section 4.3
       RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1
       RFC 6827: Automatically Switched Optical Network (ASON)
       Routing for OSPFv2 Protocols, Section 3";
  }

That means the 128-bit IPv6 address cant be source and destination in TE tunnel/LSPs. Isn't that an issue that we should fix?

[tsaad-net]

The tunnel endpoints are identified by TE node ID in the topology. TE Node ID is dotted-quad. We can map PCEP/RSVP IPv6 addresses to TE Node ID. Adding two optional Src-ip and Dst-ip

Tunnel Src Src-ip Src-TTP Dst Dst-ip Dst-TTP

[italobusi]

Agreed to use the te-gen-node-id datatype for tunnel source/destination and nodes in the explicit-route elements

These attributes will be interpreted as:

• TE node ID, when the te-topology-identifier identifies the topology where these IDs are defined
• IP address, when the te-topology-identifier is not present (so there is no topology reference for the tunnel)

Need to improve the description since the node in the TE topology is identified only by the te-node-id and not by an IP address.

IS-IS and OSPF-TE provides some mapping between a dotted-quad te-node-id and one or more IPv4/IPv6 addresses

[italobusi]

Slide drafted during our discussion today:

[italobusi]

2023-05-26 TE Call

Agreed not to take actions

• [ ] Pavan: provide some text to clarify the rationale not to address this issue

[tsaad-dev]

Discussed this on 06/02: One option is:

• to add node-ip (ip type) in tunnel source/destination for packet TE tunnels only.
• The L3 TE topology may allow multiple IP addresses to exist under a TE node. This is not blocking the TE tunnel (generic tunnel model) and LC will not wait for resolution on it.

[italobusi]

1. At least one IPv4 node address --> MAY be mapped to the te-node-id

2. Only IPv6 node addresses (OSFP)

   TE Router ID is always 4 octets --> MAY be mapped to te-node-id

3. Only IPv6 node addresses (IS-IS)

   1. TE Router ID is 4 octets --> MAY be mapped to te-node-id

   2. TE Router ID is 16 octets --> cannot be mapped to te-node-id

      1. L3 TE Topo is supported: the te-node-id assigned to a node with IPv6 addresses/Router IDs is provided by the L3 TE-Topo

      2. L3 TE Topo is not supported: the te-node-id cannot be used for setting up TE tunnels: issue to be addressed

This issue will be addressed in the Packet TE Tunnel model and it is out of scope of the generic TE Tunnel model

[swamy-b]

I believe that this topic should be addressed in this draft and not in packet TE tunnel model. One of the proposals was to have an optional leaf with src-ip and dst-ip and adding these optional leafs into the draft would cover the scenario without impacting the rest of the draft.

[italobusi]

See WG LC comment in https://mailarchive.ietf.org/arch/msg/teas/uqCE1W7j4cfkTmWo-Vzib80IVkc/

[tsaad-dev]

The recommendation is to make a change to RFC8776-bis: typedef te-node-id { union { type yang:dotted-quad; type yang:ipv6-address; } }

Update the description to reflect dotted-quad,v4,v6 are possible

[italobusi]

Discussed with Netmod WG whether this change is BC or NBC:

https://mailarchive.ietf.org/arch/msg/netmod/iwFmNRp6jK79Wv6VR30oOomtj9M/

[italobusi]

2024-01-19 TE Call

No conclusive answer from Netmod WG about BC/NBC change

Agreed to implement the change in the draft without mentioning the NBC issue

In the description, clarify that the v6 address type is re-used for the formatting but the te-node-id is still an identifier and not a routable address

Reference for IS-IS IPv6 Router ID: https://datatracker.ietf.org/doc/html/rfc6119