[Teas] Re: Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Pavan,

This would indeed address my concern.

-éric

From: Vishnu Pavan Beeram <[e-mail]>
Date: Tuesday, 17 March 2026 at 23:05
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: Tarek Saad <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41: (with DISCUSS and COMMENT)

Eric,

Regarding your comment on extended-tunnel-id, please refer to Tarek's response sent on Feb 14th (reproduced below). We will change the leaf type to tetypes:te-node-id, and that will ensure that an IPv6 address can be used as the extended-tunnel-id. This change, when made, should address your concern.

**
[TS]: RFC3209 defined this as 4 or 16 byte identifiers (depending on session object type IPv4/IPv6). We will update this leaf as follows:

leaf extended-tunnel-id {
  type te-types:te-node-id;
  description
    "A qualifier used to ensure the global uniqueness of the
     tunnel identifier. It carries a 4-byte or 16-byte value,
     typically corresponding to the Extended Tunnel ID extracted
     from the RSVP-TE SESSION object as defined in RFC 3209.";
  reference
    "RFC3209";
}

For reference, the te-node-id is already defined as:

typedef te-node-id {
   type union {
     type yang:dotted-quad;
     type inet:ipv6-address-no-zone;
   }
}
**

Regards,
-Pavan

On Tue, Mar 17, 2026 at 12:11 AM Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>> wrote:
Tarek and authors,

Thanks for the -43 as it addresses some DISCUSS points but also introduces a new one :-)


  *
Appendix A.1 is fixed indeed
  *
extended-tunnel-id the description is fixed *BUT* the YANG type is dotted-quad which can only represent 32-bit quantity

About the remaining DISCUSS, the abstract still contains `The model covers data that is independent of any technology or dataplane encapsulation` which contradicts the title, which is indeed specific to LSP-based.

Section 3 is better with the removal of 'generic' but it still has `This document describes a TE data model that is independent of any dataplane technology.`  while being heavy on the LSP side.

I.e., there are 2 remaining DISCUSS points that are mainly editorial though.

Regards

-éric



From: Tarek Saad <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 15 February 2026 at 12:03
To: Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41: (with DISCUSS and COMMENT)

Hi Eric,

Thank you for your review and comments. Please see inline for responses. I'm also adding a pointer to the work-in-progress diffs<https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/tsaad-dev/drafts/master/te/draft-ietf-teas-yang-te.txt&url_2=https://www.ietf.org/archive/id/draft-ietf-teas-yang-te-41.txt>.

From: Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, February 4, 2026 at 3:47 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-yang-te-41: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-teas-yang-te-41
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Adrian Farrel for the shepherd's *very detailed* write-up
including the WG consensus, the lack of implementation status, but it *lacks*
the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Misleading title & abstract

The abstract contains `The model covers data that is independent of any
technology or dataplane encapsulation` (i.e., not linked to a technology) but
the whole model is about LSP (i.e., linked to specific technologies). The TEAS
charter is explicitly not limited to MPLS/GPLS as it includes `TE is applied to
packet networks via MPLS TE tunnels and LSPs, but may also be provided by other
mechanisms such as forwarding rules similar to policy-based routing.`

Suggest using 'A YANG data model for LSP-based point-to-point TE and the
associated interfaces'

[TS]: we feel the current title "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces" covers LSP based tunnels. To ensure we're in sync with the WG, a new discussion thread will be started on the WG mailing list on proposed new terminology.


### Section 3

Same as above as the text includes `The elements of the generic TE YANG data
model` while it forces the use of LSP.

I won't comment anymore about this model being LSP-only (e.g., leaves
source/destination are about `LSP endpoint`).

### Section 5.3 and extended-tunnel-id

If `extended-tunnel-id` is just a 32-bit ID (such as OSPFv3 router ID) printed
in quad decimal, then do not use IPv4 in the description (currently `by
carrying an IPv4 address of the LSP head end`).

If it is actually an IPv4 address, then this I-D should not be published in
2026 as it does not support IPv6.

[TS]: RFC3209 defined this as 4 or 16 byte identifiers (depending on session object type IPv4/IPv6). We will update this leaf as follows:

        leaf extended-tunnel-id {
          type te-types:te-node-id;
          description
          description
        "A qualifier used to ensure the global uniqueness of the
         tunnel identifier. It carries a 4-byte or 16-byte value,
         typically corresponding to the Extended Tunnel ID extracted
         from the RSVP-TE SESSION object as defined in RFC 3209.";
          reference
            "RFC3209";
        }

For reference, the te-node-id is already defined as:

  typedef te-node-id {
    type union {
      type yang:dotted-quad;
      type inet:ipv6-address-no-zone;
    }



### Appendix A.1

Even if the examples in appendixes are usually non-normative, they should be
easy to understand and the tunnel `Example_LSP_Tunnel_A_2 (IPv6)` appears to be
anchored on 2 IPv6 addresses (thank you) but these addresses do not appear on
the figure 10.

[TS]: The figure is updated with addresses.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Med Boucadair's DISCUSS

I second Med's DISCUSS about the lack of justification about the single choice
of anchoring a tunnel on a single interface (as opposed to a node or multiple
interfaces).

[TS]: we will respond to Med's comment and keep you posted.

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)

### Section 5

Please expand SRLG at first use.

[TS]: done.

### Section 5.1.2

I wonder whether the TEAS WG considered adding other properties for the
tunnels, e.g., MTU, whether to copy the hop-limit/TTL to the outside header, ...

Why is it `LSP head-end` for leaf source and `LSP endpoint` for leaf
destination ?

[TS]: the 'LSP endpoint'​ is used now in both cases - e.g.:

NEW:
leaf source {
  type te-types:te-node-id;
  description
    "The address of the ingress LSP endpoint that identifies the
     start of the tunnel. This typically corresponds to the
     Tunnel Sender Address extracted from the RSVP-TE
     SENDER_TEMPLATE object.";

Please run a spell check on the module itself (e.g., s/identfies/ident*i*fies/)
[TS]: done.

Regards,
Tarek (for the authors)



### Appendix A

Having IPv4-only examples in 2026 does not sound too good...