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

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

Eric,
Please see inline (prefixed VPB)

Regards,
-Pavan

On Tue, Mar 17, 2026 at 12:11 AM Eric Vyncke (evyncke) <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.
>

[VPB] The draft's title ("A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths, and Interfaces") clearly states the scope of
the constructs being modeled.

Would the following change in the abstract address your concern?
**
OLD:

The model covers data that is independent of any technology or
dataplane encapsulation and is divided into two YANG modules that
cover device-specific, and device independent data.

NEW:
The model covers data pertinent to TE tunnels, TE LSPs, and TE interfaces,
that are independent of any technology or dataplane encapsulation. The
model is divided into two YANG modules that cover device-specific and
device-independent data.
**

>
> 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.
>

Would the following change in Section 3 address your concern?
**
OLD:
This document describes a TE data model that is independent of any
dataplane technology.

NEW:
This document describes a data model for TE tunnels, TE LSPs, and TE
interfaces that are independent of any dataplane technology.
**


> 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...
>
>
>
>
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>