I reviewed version 08 as a RTG Area reviewer.

This is a well written document that has a few editorial issues that could usefully  be looked at before proceeding. Some affect the text that the reader will see, some affect the production process.

It is not clear that all abbreviations are expanded on first use and a detailed check by the editor should be carried out. The editor could usefully include a terminology section or a glossary to help the new reader with the not-officially-well-known abbreviations. I picked up ASLA, FAPM, FAEMB there may be others.

=========

The nits checker picked up:


  ** There are 13 instances of too long lines in the document, the longest
     one being 11 characters in excess of 72.

and

 ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479)

  ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492)

  -- Obsolete informational reference (is this intentional?): RFC 5316
     (Obsoleted by RFC 9346)

It also picked up RFC-ietf-lsr-flex-algo-bw-con-04 meaning "This RFC" perhaps consider that to avoid all the reviewers figuring out what is happening.

=======
Minor English
   constraint based paths in IGP.  This draft documents a generic metric
SB> s/in/in an/

=======

 The micro-loop avoidance procedures
   described in [I-D.bashandy-rtgwg-segment-routing-uloop] can be used
   to avoid micro-loops when the automatic metric calculation is
   deployed.
SB> Indeed, but so can any micro-loop avoidance method.

=======
          A------B====C====F====D
                  |              |
                   ------E-------

                       Figure 7: Parallel interfaces

   For exmple, in the above diagram, there are two parallel links
   between B->C, C->F, F->D.  Let us assume the link bandwidth is
   uniform 10Gbps on all links and the metric for each link will be the
   same.  Traffic from B to D will be forwarded B->E->D.  Since the
   bandwidth is higher on the B->C->F->D path, the metric for that path
   should be lower, and that path should be selected.  Interface Group
   Mode is preferred in cases where there are parallel layer-3 links.

SB> This paragraph is not well expressed. Please consider rewording.
SB> I think that you man to say that the B C F D path needs to have a lower metric than B E D to attract the traffic via B C F D, but it is not well expressed in the text.

   In the interface group mode, every node MUST identify the set of
   parallel links between a pair of nodes based on IGP link
   advertisements and MUST consider cumulative bandwidth of the parallel
   links while arriving at the metric of each link.
SB> Of course it is a bit more subtle because there will be additional forwarding delay in F and we need to consider ingress traffic at C, F and E.

=======

In the text you use a uniform term TBD and in IANA a uniform term TBA. For clarity in later stages of the publication process it might be useful to give each IANA parameter a unique identifier, for example TBD1, TBD2 etc.