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

[Rakesh Gandhi <[e-mail]>]

Many thanks Eric, Adrian, Tarek, Pavan and co-authors for your
dedicated work to reach this milestone.

Thanks,
Rakesh


On Mon, Mar 30, 2026 at 7:33 PM Vishnu Pavan Beeram <
[e-mail]> wrote:

> Eric - Thanks for the discussion and for clarifying the document's scope.
>
> Adrian - Thanks for shepherding this work.
>
> Tarek et al - Thanks for addressing all the comments.
>
> Regards,
> -Pavan
>
> Regards,
> -Pavan
>
> On Mon, Mar 30, 2026 at 3:36 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
>> Pavan,
>>
>> As you may have seen by now, I have updated my ballot to a non-blocking
>> No Objection.
>>
>> Thanks for the discussions (facilitated by Adrian)
>>
>> Regards
>>
>> -éric
>>
>>
>> *From: *Vishnu Pavan Beeram <[e-mail]>
>> *Date: *Saturday, 28 March 2026 at 01:03
>> *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,
>>
>> 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...
>>
>>
>>
>>
>> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>