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

[Vishnu Pavan Beeram <[e-mail]>]

Eric,

Ver. 44 (https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/44/)
includes all the updates that were discussed on and off-list. Please review
the changes and let us know if anything is amiss.

Regards,
-Pavan

On Tue, Mar 17, 2026 at 8:18 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> 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]>
> 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]>
> *Date: *Sunday, 15 February 2026 at 12:03
> *To: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
> *Cc: *[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)
>
> 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]>
> *Date: *Wednesday, February 4, 2026 at 3:47 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <[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...
>
>
>
>
>