Éric Vyncke's Discuss on draft-ietf-teas-rfc8776-update-20

[italobusi]

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: 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-rfc8776-update/

---

DISCUSS:

Éric Vyncke INT AD comments for draft-ietf-teas-rfc8776-update-20

CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Oscar Gonzalez de Dios for the shepherd's write-up including
the WG consensus and 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.

Title

While I understand that the TEAS WG is limited to MPLS technology, the title of
this IETF draft is misleading as it it not Common YANG Data Types for Traffic Engineering but more about Common YANG Data Types for *MPLS-based* Traffic Engineering.

This also applies to the module names as they should include "mpls" in the name
as they are specific to MPLS and in no way ietf-te-types, or did I miss
something?

Even if RFC 8776 had the some issue, this is not a reason for repeating the
confusion.

More broadly, I find extremely sad that there is IETF-wide effort to have a
real common data model across all TE control planes :-(

Section 3.1

The leading text contains TE types that are independent and agnostic of any specific technology or control-plane instance but its subsection has terms
that are very specific to MPLS-based control planes, e.g., lsp-encoding-types.

Section 3.1.1

Missing text about when the SHOULD can be bypassed or what are the consequences
of bypassing it in: The derived identities SHOULD describe the unit and maximum value of the path metric types they define per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Section 3.1.2

What is 16-octet in full, mixed, shortened, or shortened-mixed IPv6 address notation ? Why not simply requesting to use RFC 5952 ?

Same applies to te-node-id in section

Section 4

It is unclear what is "hex float" in where each of these numbers can be non-negative decimal, hex integer, or *hex float* in the description
ofte-bandwidth. There is a hint to 'bandwidth-ieee-float32' but it should
not be a hint.

---

COMMENT:

COMMENTS (non-blocking)

Section 2

It would have been useful to also provide references to the terms beyond acronyms expansions.

Section 3.1.1.1

Please expand or add a reference to "RWA" in No RWA constraints met

See: https://mailarchive.ietf.org/arch/msg/teas/tMTDQbdBdXHTOA6OAstCohlMXro/

[italobusi]

2026-01-09 TE call

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: 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-rfc8776-update/

---

DISCUSS:

Éric Vyncke INT AD comments for draft-ietf-teas-rfc8776-update-20

CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Oscar Gonzalez de Dios for the shepherd's write-up including
the WG consensus and 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.

Title

While I understand that the TEAS WG is limited to MPLS technology, the title of
this IETF draft is misleading as it it not Common YANG Data Types for Traffic Engineering but more about Common YANG Data Types for *MPLS-based* Traffic Engineering.

This also applies to the module names as they should include "mpls" in the name
as they are specific to MPLS and in no way ietf-te-types, or did I miss
something?

Even if RFC 8776 had the some issue, this is not a reason for repeating the
confusion.

More broadly, I find extremely sad that there is IETF-wide effort to have a
real common data model across all TE control planes :-(

• Follow-up mailing list discussion

From Rakesh:

As specified in [RFC9603], the term "LSP"
used in the PCEP specifications would be equivalent to an SRv6 path
(represented as a list of SRv6 segments) in the context of supporting
SRv6 in PCEP using SRv6 path setup type.

Section 3.1

The leading text contains TE types that are independent and agnostic of any specific technology or control-plane instance but its subsection has terms
that are very specific to MPLS-based control planes, e.g., lsp-encoding-types.

Authors: clarified via previous mail discussion that the document is applicable also to GMPLS

Section 3.1.1

Missing text about when the SHOULD can be bypassed or what are the consequences
of bypassing it in: The derived identities SHOULD describe the unit and maximum value of the path metric types they define per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Authors: Change the SHOULD to a MUST

Section 3.1.2

What is 16-octet in full, mixed, shortened, or shortened-mixed IPv6 address notation ? Why not simply requesting to use RFC 5952 ?

Same applies to te-node-id in section

Authors: Replace as 16-octet in an [RFC5952] IPv6 address notation

Section 4

It is unclear what is "hex float" in where each of these numbers can be non-negative decimal, hex integer, or *hex float* in the description
ofte-bandwidth. There is a hint to 'bandwidth-ieee-float32' but it should
not be a hint.

• @italobusi Check for references to improve the description

---

COMMENT:

COMMENTS (non-blocking)

Section 2

It would have been useful to also provide references to the terms beyond acronyms expansions.

• @italobusi check for the references

Section 3.1.1.1

Please expand or add a reference to "RWA" in No RWA constraints met

Authors: We have removed the example since it is a WDM technology-specific example defined elsewhere

See: https://mailarchive.ietf.org/arch/msg/teas/tMTDQbdBdXHTOA6OAstCohlMXro/

[italobusi]

Follow-up discussion based on initial commits on draft PR #334 :

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: 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-rfc8776-update/

---

DISCUSS:

Éric Vyncke INT AD comments for draft-ietf-teas-rfc8776-update-20

CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Oscar Gonzalez de Dios for the shepherd's write-up including
the WG consensus and 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.

Title

While I understand that the TEAS WG is limited to MPLS technology, the title of
this IETF draft is misleading as it it not Common YANG Data Types for Traffic Engineering but more about Common YANG Data Types for *MPLS-based* Traffic Engineering.

This also applies to the module names as they should include "mpls" in the name
as they are specific to MPLS and in no way ietf-te-types, or did I miss
something?

Even if RFC 8776 had the some issue, this is not a reason for repeating the
confusion.

More broadly, I find extremely sad that there is IETF-wide effort to have a
real common data model across all TE control planes :-(

• Follow-up mailing list discussion

From Rakesh:

As specified in [RFC9603], the term "LSP"
used in the PCEP specifications would be equivalent to an SRv6 path
(represented as a list of SRv6 segments) in the context of supporting
SRv6 in PCEP using SRv6 path setup type.

Section 3.1

The leading text contains TE types that are independent and agnostic of any specific technology or control-plane instance but its subsection has terms
that are very specific to MPLS-based control planes, e.g., lsp-encoding-types.

Authors: We think that the mail discussion has already clarified that the document is applicable also to GMPLS

Section 3.1.1

Missing text about when the SHOULD can be bypassed or what are the consequences
of bypassing it in: The derived identities SHOULD describe the unit and maximum value of the path metric types they define per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Authors: The SHOULD has been changed to be a MUST

Section 3.1.2

What is 16-octet in full, mixed, shortened, or shortened-mixed IPv6 address notation ? Why not simply requesting to use RFC 5952 ?

Same applies to te-node-id in section

Authors: The text has been replaced as 16-octet in an [RFC5952] IPv6 address notation

Section 4

It is unclear what is "hex float" in where each of these numbers can be non-negative decimal, hex integer, or *hex float* in the description
ofte-bandwidth. There is a hint to 'bandwidth-ieee-float32' but it should
not be a hint.

• @italobusi Check for references to improve the description

<Italo>
I have added a reference to ISO/IEC 9899:2024 (see initial commits on draft PR #334 ).

However, looking at the current reference, I think that ITU-T G.709 can be removed since it was needed for the OTN bandwidth description in RFC 8776 and removed here.

Need to discuss the second part of the comment where Eric think that the hint to 'bandwidth-ieee-float32' should not be an hint.

Strictly speaking, making it as a MUST would be NBC since existing implementations might not have used 'bandwidth-ieee-float32' for packet-switching types. However, IMHO, this is not a big issue since I am not aware of existing implementations of this typedef.

<\Italo:>

• @ALL discuss the issue above

---

COMMENT:

COMMENTS (non-blocking)

Section 2

It would have been useful to also provide references to the terms beyond acronyms expansions.

• @italobusi check for the references

<Italo>
I have removed the following acronyms since not used in the document:

• DS-TE
• SD
• SF

Some acronyms are considered as well-known by the RFC Editor: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list

• GMPLS
• MPLS
• RSVP
• TE

I am wondering whether we can remove the following acronyms, or avoiding adding a reference
<\Italo:>

• @ALL discuss the issue above

Section 3.1.1.1

Please expand or add a reference to "RWA" in No RWA constraints met

Authors: We have removed the example since it is a WDM technology-specific example defined elsewhere

See: https://mailarchive.ietf.org/arch/msg/teas/tMTDQbdBdXHTOA6OAstCohlMXro/

[italobusi]

2026-01-16 TE Call

I have added a reference to ISO/IEC 9899:2024 (see initial commits on draft PR #334 ).

However, looking at the current reference, I think that ITU-T G.709 can be removed since it was needed for the OTN bandwidth description in RFC 8776 and removed here.

Need to discuss the second part of the comment where Eric think that the hint to 'bandwidth-ieee-float32' should not be an hint.

Strictly speaking, making it as a MUST would be NBC since existing implementations might not have used 'bandwidth-ieee-float32' for packet-switching types. However, IMHO, this is not a big issue since I am not aware of existing implementations of this typedef.

<\Italo:>

• @ALL discuss the issue above

Remove the reference to G.709

c/may follow/MUST follow/

---

I have removed the following acronyms since not used in the document:

• DS-TE
• SD
• SF

Some acronyms are considered as well-known by the RFC Editor: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list

• GMPLS
• MPLS
• RSVP
• TE

I am wondering whether we can remove the following acronyms, or avoiding adding a reference <\Italo:>

• @ALL discuss the issue above

Add references also for:

• GMPLS: RFC3945
• MPLS: RFC3031
• RSVP: RFC2205
• TE: RFC9522

---

Éric Vyncke has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: 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-rfc8776-update/

---

DISCUSS:

Éric Vyncke INT AD comments for draft-ietf-teas-rfc8776-update-20

CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Oscar Gonzalez de Dios for the shepherd's write-up including
the WG consensus and 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.

Title

While I understand that the TEAS WG is limited to MPLS technology, the title of
this IETF draft is misleading as it it not Common YANG Data Types for Traffic Engineering but more about Common YANG Data Types for *MPLS-based* Traffic Engineering.

This also applies to the module names as they should include "mpls" in the name
as they are specific to MPLS and in no way ietf-te-types, or did I miss
something?

Even if RFC 8776 had the some issue, this is not a reason for repeating the
confusion.

More broadly, I find extremely sad that there is IETF-wide effort to have a
real common data model across all TE control planes :-(

• See Title of RFC8776-bis #337

Section 3.1

The leading text contains TE types that are independent and agnostic of any specific technology or control-plane instance but its subsection has terms
that are very specific to MPLS-based control planes, e.g., lsp-encoding-types.

Authors: We think that the mail discussion has already clarified that the document is applicable also to GMPLS

Section 3.1.1

Missing text about when the SHOULD can be bypassed or what are the consequences
of bypassing it in: The derived identities SHOULD describe the unit and maximum value of the path metric types they define per
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Authors: The SHOULD has been changed to be a MUST

Section 3.1.2

What is 16-octet in full, mixed, shortened, or shortened-mixed IPv6 address notation ? Why not simply requesting to use RFC 5952 ?

Same applies to te-node-id in section

Authors: The text has been replaced as 16-octet in an [RFC5952] IPv6 address notation

Section 4

It is unclear what is "hex float" in where each of these numbers can be non-negative decimal, hex integer, or *hex float* in the description
ofte-bandwidth. There is a hint to 'bandwidth-ieee-float32' but it should
not be a hint.

<Authors>

We have:

1. added a reference to ISO/IEC 9899:2024 for the definition of "hex float"; changed
2. c/may follow the type 'bandwidth-ieee-float32'/MUST follow the type 'bandwidth-ieee-float32'/
3. removed the reference to ITU-T G.709 since no longer used by this description

<\Authors>

---

COMMENT:

COMMENTS (non-blocking)

Section 2

It would have been useful to also provide references to the terms beyond acronyms expansions.

<Authors>

We have removed the following acronyms since not used in the document:

• DS-TE
• SD
• SF

We have added references for all the remining acronyms.

<\Authors>

Section 3.1.1.1

Please expand or add a reference to "RWA" in No RWA constraints met

Authors: We have removed the example since it is a WDM technology-specific example defined elsewhere

See: https://mailarchive.ietf.org/arch/msg/teas/tMTDQbdBdXHTOA6OAstCohlMXro/