Ketan Talaulikar's Discuss on draft-ietf-teas-yang-te-41

[italobusi]

Ketan Talaulikar 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:

Thanks to the authors and the WG for their work on this model.

There are a couple of points that I would like to discuss.

Please excuse if I am missing something here about the
extended-admin-group modeling

/* TE Global Data */
container globals {
  description
    "Globals TE system-wide configuration data container.";
  container named-admin-groups {
    description
      "TE named admin groups container.";
    list named-admin-group {
      if-feature "te-types:extended-admin-groups";
      if-feature "te-types:named-extended-admin-groups";
      key "name";
      description
        "List of named TE admin-groups.";
      leaf name {
        type string;
        description
          "A name that uniquely identifies a TE
           interface named admin-group.";
      }
      leaf bit-position {
        type uint32;
        description
          "Bit position representing the administrative group.
           Uniquely identify a specific administrative group by
           its numerical position within the bitmask.";
        reference
          "RFC3209 and RFC7308";
      }

    }
  }

How does a single uint32 cover the EAG which can be multiples of 32-bit as
specified in RFC7308?

I am not sure if the reference to RFC9012 is appropriate here since
that is just a BGP Color Ext Comm and the tunnels in the BGP Tunnel Encaps is
different. There is not talk about steering services using this color in
RFC9012. I could have suggested RFC9256 and RFC9830 (SR Policies) but not sure
if there is another better reference (remember color in RSVP-TE and PCEP ...)?

color:

A YANG leaf that holds the color associated with the TE tunnel. The color is
used to map or steer services that carry matching color onto the TE tunnel as
described in [RFC9012].

    leaf color {
      type uint32;
      description "The color associated with the TE tunnel.";
      reference "RFC9012";
    }

Also, there is another "color" in the model that refers to affinity/admin-group
so better to use it in only one of those two contexts in this document?

---

COMMENT:

Please find below some comments:

1. RFC6991 has been obsoleted by RFC9911

2. Section 1:

s/such as RSVP-TE ([RFC3209], [RFC3473]), or Segment-Routing TE (SR-TE)
[RFC9256]/such as RSVP-TE ([RFC3209], [RFC3473]), or Segment Routing
([RFC8402], [RFC9256])

3. I support the DISCUSS position of Eric Vyncke about this document being
   about MPLS than really data plane independent. That is not to say that many
   elements from here would not be useful for SRv6 TE (e.g., TE interface readily
   applies). However, the document already states that "Segment-Routing (SR)
   Policies [RFC9256] falls outside the scope of this document" and so why not
   just keep it to MPLS given that it references LSP widely. Perhaps suitable
   adaption for SRv6 TE can be taken up in a separate document? Just an option ...

See: https://mailarchive.ietf.org/arch/msg/teas/kA83V5dkukf2oB_nXj-d1UX3eGo/