Éric Vyncke's Discuss on draft-ietf-teas-yang-te-41

[italobusi]

É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'

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.

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.

---

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

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.

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 ?

Please run a spell check on the module itself (e.g., s/identfies/identifies/)

Appendix A

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

See: https://mailarchive.ietf.org/arch/msg/teas/ZHOm_H22-gVBlASunxRFAMYJ8P4/