IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
draft-ietf-lsr-isis-srv6-extensions-19

[Ballot discuss]
Thanks for the work on this document.

I was not around for RFC 8986, and I am not sure I understand the use case fully (I agree with Ben there), but I'll trust the responsible AD and the wg. I'll also note that I was hoping to see "Implementation status report" in the draft, as mentioned in the shepherd writeup, and was disappointed not to find any.

However, I'd like to discuss a number of points, mostly on the IANA considerations and on detailed fields descriptions. I also want to bring 7. below regarding the IANA registries names to your attention, although it's not a hill I am willing to die on (that one is a "let's talk" DISCUSS, the rest I hope can be acted upon).

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise.


Francesca

1. -----

Section 7.1

FP: The locator entries ASCII figure is not consistent with the descriptive text following it: specifically, Loc Size should follow Algorithm directly; instead, the picture seems to show there are 2 octets unused between Algorithm and Loc Size.

2. -----

      Type: 5.

FP: For consistency (and to make sure implementers don't rely on the ASCII figure), it would be good to indicate Type's length (1 octet I assume).

3. -----

    Length: variable.

FP: This does not help much understanding what this field is supposed to contain.

4. -----

Section 7.2

FP: Same issue as in 1. for the ASCII figure.

5. -----

Sections 8.1 and 8.2

FP: Same comments as 1. 2. and 3.

6. -----

  If a behavior is advertised it MUST
  only be advertised in the TLV[s] as indicated by "Y" in the table
  below, and MUST NOT be advertised in the TLV[s] as indicated by "N"
  in the table below.

FP: I find the sentence after the comma confusing, and don't understand the presence of the MUST NOT here.

7. -----

Section 11.1.1

FP: It sounds like a bad idea in general to have to rename the registry every time a TLV needs to be added to the registry... Maybe the wg and the AD should consider renaming the registries so not to have this sort of dependency. (I understand that this is a low priority comment, but still, it feels wrong to put in titles what would fit really well in a registry itself). This very much applies to Section 11.6 as well: the registry's name with the hierarchy of TLVs as part of the name feels like a really bad idea. That is typically data that goes into registries.

8. -----

Section 11.3

FP: The registry needs to be defined in the document. In particular, I see that IANA is interpreting the columns as "Value" "Description" "Reference"; is that right or should this be "Type" "Description" "Reference" (I see a mix of the two for different IANA registries)?

9. -----

Section 11.8

FP: Are bits 0, 2-15 reserved or unassigned? The terminology in section 2 is ambiguous, as it talks about "reserved for future use" (but the IANA section leaves them unassigned). Please clarify for IANA.

10. -----

Section 11.10

FP: Please define the registry (I assume it is going to be "Bit #", "Name", "Reference").

[Ballot comment]
Thank you for addressing my discuss point and comments.

The relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered
to be logically local to the node advertising the SID and therefore not
an observable part of the protocol.  In that sense, the wire-visible use
and processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a sub-sub-TLV to specifically carry the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  In the absence of some compelling use case, I
cannot support publishing a mechanism that triggers this controversy.
Indeed, no motivating use case is presented in the document at all (the
usage is "outside of the scope of this document"), which invites
questions about why this mechanism should be defined in a
standards-track RFC at all (the relevant registry procedures are merely
"expert review").

[Ballot comment]
I'm balloting ABSTAIN for the reasons cited by Warren (and, hence, Ben).

I support Erik Kline's DISCUSS position.

Some other unrelated comments:

I suggest asking IANA to review your IANA Considerations section sooner rather than later to be sure they know what you're after.  I found this section somewhat hard to follow.

I concur with John, who suggested that this document doesn't actually update RFC 7370.  I'm aware of the conversation that happened afterwards; just going on the record here.

Section 9:

* "It's usage is outside of the scope of this document." -- s/It's/Its/

[Ballot comment]
[EDIT]: I'm updating my position from Abstain to NoObjection. I wish that there was a sub-position of "Erk, I really don't like this, but my unhappiness isn't actually with your document, but rather something you reference/rely on" :-)
My unhappiness is actually with RFC8986, this just carries that structure.


I have stolen this text from Ben, because it's well written and reflects my position:
"The relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered
to be logically local to the node advertising the SID and therefore not
an observable part of the protocol.  In that sense, the wire-visible use
and processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a sub-sub-TLV to specifically carry the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  In the absence of some compelling use case, I
cannot support publishing a mechanism that triggers this controversy."

My view is somewhat stronger - a number of people agreed to  ABSTAINED on RFC 8986 instead of DISCUSSing because it was agreed that it did not try and redefine what an IPv6 address is. This document (section 9) tries to implement structure.

[Ballot comment]
I support Erik’s DISCUSS especially in light of Warren’s ABSTAIN.

Below are some questions and comments. I'd appreciate a reply, thanks.

1. Abstract

  The Segment Routing (SR) allows for a flexible definition of end-to-

You either have too many, or not enough words here. Either “segment routing“ (remove “the“), or something like “the segment routing architecture“.

  called "segments".  Segment routing architecture can be implemented

And here you do need “the“ in front of “segment”.

  over an MPLS data plane as well as an IPv6 data plane.  This document

“An” -> “the” (two places)

  over an IPv6 data plane.

“An” -> “the”

  This documents updates RFC 7370 by modifying an existing registry.

“Documents” -> “document”

Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an RFC to update an IANA registry, without saying it updates a previous RFC that established that registry. I think the “updates” just confuses matters and clutters things up, and should be removed.

2. Section 1

  This documents updates [RFC7370] by modifying an existing registry
  (Section 11.1.2).

“Documents” -> “document”

See also comment #1 regarding update.

3. Section 4.3

  A non-zero SRH Max H.encaps MSD indicates that the headend can insert
  an SRH up to the advertised value.

“Up to the advertised value” doesn’t make sense. I guess you mean “can insert an SRH with up to the advertised number of SIDs”?

4. Section 4.4

  The Maximum End D MSD Type specifies the maximum number of SIDs
  present in an SRH when performing decapsulation. 

That makes sense.

              These includes, but
  not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with
  USD as defined in [RFC8986].

That doesn’t. How can a number include all those specific things? A number’s just an integer, right? Maybe you are providing some helpful context about the types of SIDs that are permitted to be present? If so, I expect this is specified elsewhere already, and this sentence is not helping; I would suggest removing it. If it does need to stay, it needs a rewrite for grammar and clarity. (Maybe you want something like “As specified in [RFC 8986] the permitted SID types include, but are not limited to, .”)

      If the advertised value is zero or no value is advertised
      then the router cannot apply any behavior that results in
      decapsulation and forwarding of the inner packet if the
      other IPv6 header contains an SRH.

What “other” IP header? Do you mean the outer header? The inner header? Something else?

5. Section 5

  In cases where a locator advertisement is received in both a Prefix
  Reachability TLV and an SRv6 Locator TLV - (e.g. prefix, prefix-
  length, MTID all being equal and Algorithm being 0 in Locator TLV),

Since “e.g.” means “for example” you’re saying the thing in the parentheses is only one example of a locator advertisement received in both? What’s another example? (Maybe the algo being 1 in both cases?)

But in any case the text above appears redundant with the text that immediately follows. Can’t the text above be deleted?

  In case where the same prefix, with the same prefix-length, MTID, and
  algorithm is received in both a Prefix Reachability TLV and an SRv6
  Locator TLV, the Prefix Reachability advertisement MUST be preferred
  when installing entries in the forwarding plane.  This is to prevent
  inconsistent forwarding entries between SRv6 capable and SRv6
  incapable routers.

“In case” -> “in the case” or “in cases”

6. Section 7.2

  Supported behavior values together with parent TLVs in which they
  area advertised are specified in Section 10 of this document.  Please

“Area” -> “are”

      Length: variable.

      Flags: 1 octet.  No flags are currently defined.

When you write “length: variable“, I think you mean “length: a 1 octet field, whose value is variable“, don’t you? Just like you write “flags: 1 octet“? I get that the value placed into the length field is variable, but the way you’ve written it, it says that the length of the length field is itself variable, which would make no sense.

This is not the only place in the document you specify a length field this way, but I guess you should fix all of them. I’m only noting it here.

  The SRv6 End SID MUST be a subnet of the associated Locator.  SRv6
  End SIDs which are not a subnet of the associated locator MUST be
  ignored.

Is a host route (which is what a SID is) technically a “subnet”? Can something which is not a net, be a subnet? It reads funny that way. If you change it, possibly “MUST be covered by the associated Locator“? (Although then for clarity you might need to define “covered“, which might not be any better.) (Same comment applies to Section 8 which also mentions “subnet”.)

7. Section 8.1

        B-Flag: Backup flag.  If set, the SID is eligible for
        protection (e.g., using IPFRR) as described in [RFC8355].

Please expand IPFRR on first use. And since you say “e.g.” meaning “for example”, do you contemplate some other kind of protection which is not IPFRR? If not, I think you could delete the parenthesis without loss of clarity.

8. Section 9

  SRv6 SID Structure Sub-Sub-TLV is used to advertise the as defined in
  [RFC8986].  It has the following format:

You’re missing something between “advertise the” and “as defined”.

      Length: 4 octets.

Similar to my earlier comment, I think what you mean is something like “Length: a 1 octet field, whose value is 4”.

  associated with it.  It's usage is outside of the scope of this
  document.

“It’s” -> “its”

9. Section 11

  and sub-sub-TLVs as well updating the ISIS TLV registry and defining

“As well as”

  a new registry.

Doesn’t it define several new registries?

10. Section 11.2

Shouldn’t there be a new subsection for the registry creation?

[Ballot comment]
(updated position)

I'm balloting ABSTAIN for the reasons already eloquently stated by Ben; and with follow-up from Warren and Murray.

I support Eric Kline's Discuss position.

[Ballot comment]
Hi,

Thanks for this document.

In various places, this document references lists of numerical algorithm numbers, or TLV Ids without any associated human names.  I would have found this document to be a bit more readable if the names of the algorithms and TLVs were also used alongside their numerical ids.

Thanks,
Rob

[Ballot comment]
I'm balloting ABSTAIN for the reasons cited by Warren (and, hence, Ben).

Some other unrelated comments:

I suggest asking IANA to review your IANA Considerations section sooner rather than later to be sure they know what you're after.  I found this section somewhat hard to follow.

I concur with John, who suggested that this document doesn't actually update RFC 7370.  I'm aware of the conversation that happened afterwards; just going on the record here.

Section 9:

* "It's usage is outside of the scope of this document." -- s/It's/Its/

[Ballot comment]
I support Warren's DISCUSS.

Below are some questions and comments. I'd appreciate a reply, thanks.

1. Abstract

  The Segment Routing (SR) allows for a flexible definition of end-to-

You either have too many, or not enough words here. Either “segment routing“ (remove “the“), or something like “the segment routing architecture“.

  called "segments".  Segment routing architecture can be implemented

And here you do need “the“ in front of “segment”.

  over an MPLS data plane as well as an IPv6 data plane.  This document

“An” -> “the” (two places)

  over an IPv6 data plane.

“An” -> “the”

  This documents updates RFC 7370 by modifying an existing registry.

“Documents” -> “document”

Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an RFC to update an IANA registry, without saying it updates a previous RFC that established that registry. I think the “updates” just confuses matters and clutters things up, and should be removed.

2. Section 1

  This documents updates [RFC7370] by modifying an existing registry
  (Section 11.1.2).

“Documents” -> “document”

See also comment #1 regarding update.

3. Section 4.3

  A non-zero SRH Max H.encaps MSD indicates that the headend can insert
  an SRH up to the advertised value.

“Up to the advertised value” doesn’t make sense. I guess you mean “can insert an SRH with up to the advertised number of SIDs”?

4. Section 4.4

  The Maximum End D MSD Type specifies the maximum number of SIDs
  present in an SRH when performing decapsulation. 

That makes sense.

              These includes, but
  not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with
  USD as defined in [RFC8986].

That doesn’t. How can a number include all those specific things? A number’s just an integer, right? Maybe you are providing some helpful context about the types of SIDs that are permitted to be present? If so, I expect this is specified elsewhere already, and this sentence is not helping; I would suggest removing it. If it does need to stay, it needs a rewrite for grammar and clarity. (Maybe you want something like “As specified in [RFC 8986] the permitted SID types include, but are not limited to, .”)

      If the advertised value is zero or no value is advertised
      then the router cannot apply any behavior that results in
      decapsulation and forwarding of the inner packet if the
      other IPv6 header contains an SRH.

What “other” IP header? Do you mean the outer header? The inner header? Something else?

5. Section 5

  In cases where a locator advertisement is received in both a Prefix
  Reachability TLV and an SRv6 Locator TLV - (e.g. prefix, prefix-
  length, MTID all being equal and Algorithm being 0 in Locator TLV),

Since “e.g.” means “for example” you’re saying the thing in the parentheses is only one example of a locator advertisement received in both? What’s another example? (Maybe the algo being 1 in both cases?)

But in any case the text above appears redundant with the text that immediately follows. Can’t the text above be deleted?

  In case where the same prefix, with the same prefix-length, MTID, and
  algorithm is received in both a Prefix Reachability TLV and an SRv6
  Locator TLV, the Prefix Reachability advertisement MUST be preferred
  when installing entries in the forwarding plane.  This is to prevent
  inconsistent forwarding entries between SRv6 capable and SRv6
  incapable routers.

“In case” -> “in the case” or “in cases”

6. Section 7.2

  Supported behavior values together with parent TLVs in which they
  area advertised are specified in Section 10 of this document.  Please

“Area” -> “are”

      Length: variable.

      Flags: 1 octet.  No flags are currently defined.

When you write “length: variable“, I think you mean “length: a 1 octet field, whose value is variable“, don’t you? Just like you write “flags: 1 octet“? I get that the value placed into the length field is variable, but the way you’ve written it, it says that the length of the length field is itself variable, which would make no sense.

This is not the only place in the document you specify a length field this way, but I guess you should fix all of them. I’m only noting it here.

  The SRv6 End SID MUST be a subnet of the associated Locator.  SRv6
  End SIDs which are not a subnet of the associated locator MUST be
  ignored.

Is a host route (which is what a SID is) technically a “subnet”? Can something which is not a net, be a subnet? It reads funny that way. If you change it, possibly “MUST be covered by the associated Locator“? (Although then for clarity you might need to define “covered“, which might not be any better.) (Same comment applies to Section 8 which also mentions “subnet”.)

7. Section 8.1

        B-Flag: Backup flag.  If set, the SID is eligible for
        protection (e.g., using IPFRR) as described in [RFC8355].

Please expand IPFRR on first use. And since you say “e.g.” meaning “for example”, do you contemplate some other kind of protection which is not IPFRR? If not, I think you could delete the parenthesis without loss of clarity.

8. Section 9

  SRv6 SID Structure Sub-Sub-TLV is used to advertise the as defined in
  [RFC8986].  It has the following format:

You’re missing something between “advertise the” and “as defined”.

      Length: 4 octets.

Similar to my earlier comment, I think what you mean is something like “Length: a 1 octet field, whose value is 4”.

  associated with it.  It's usage is outside of the scope of this
  document.

“It’s” -> “its”

9. Section 11

  and sub-sub-TLVs as well updating the ISIS TLV registry and defining

“As well as”

  a new registry.

Doesn’t it define several new registries?

10. Section 11.2

Shouldn’t there be a new subsection for the registry creation?

[Ballot discuss]
[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs being
  claimed to be IPv6 addresses but kinda not really being IPv6 addresses
  if their internal structure is exposed outside of the given SR router.

  If "[i]t's usage is outside of the scope of this document", can this be
  removed for now, and maybe take up the issue at some point in the future
  by which time a motivating use case might have presented itself?

[Ballot comment]
I have stolen this text from Ben, because it's well written and reflects my position:
"The relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered
to be logically local to the node advertising the SID and therefore not
an observable part of the protocol.  In that sense, the wire-visible use
and processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a sub-sub-TLV to specifically carry the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  In the absence of some compelling use case, I
cannot support publishing a mechanism that triggers this controversy."

My view is somewhat stronger - a number of people agreed to  ABSTAINED on RFC 8986 instead of DISCUSSing because it was agreed that it did not try and redefine what an IPv6 address is. This document (section 9) tries to implement structure.

[Ballot discuss]
The prose and tabular IANA considerations in §11.3 are inconsistent
about whether the End.X/LAN End.X SID sub-TLVs are allowed to appear in
TLV 25.  (I may have noted all instances in the prose, in my COMMENT,
but it's worth checking for others.)

[Ballot comment]
ABSTAIN

Once my discuss point is resolved, I intend to change my position to
Abstain.  The relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered
to be logically local to the node advertising the SID and therefore not
an observable part of the protocol.  In that sense, the wire-visible use
and processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a sub-sub-TLV to specifically carry the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  In the absence of some compelling use case, I
cannot support publishing a mechanism that triggers this controversy.
Indeed, no motivating use case is presented in the document at all (the
usage is "outside of the scope of this document"), which invites
questions about why this mechanism should be defined in a
standards-track RFC at all (the relevant registry procedures are merely
"expert review").

COMMENT

(I agree with John that this doesn't inherently seem like an update to
RFC 7030, but I have nothing further to add that he hasn't said already,
so let's keep that topic in his ballot thread.)

Thank you for noting (repeatedly) that multiple TLVs may be needed in
order to advertise all the SIDs for a given neighbor/endpoint/etc. --
the one-byte length field for TLVs is a bit cramped when we have 16-byte
SIDs!

Section 4

  Link MSDs are advertised in a sub-TLV of TLVs 22, 23, 141, 222, and
  223.

The list in RFC 8491 includes TLV 25 as well.  Is TLV 25 somehow not
relevant for this document?

Section 4.3

Does the SRH Max H.encaps MSD type have any bearing on the application
of H.Encaps.Red?  (I assume the L2 encapsulations from RFC 8986 are not
quite so relevant.)

Section 5

  In case where the same prefix, with the same prefix-length, MTID, and
  algorithm is received in both a Prefix Reachability TLV and an SRv6

Others already covered the duplication/mangled nature of this paragraph,
but please also expand MTID on first use.

  Locators associated with Flexible Algorithms (see Section 4 of
  [I-D.ietf-lsr-flex-algo]) SHOULD NOT be advertised in Prefix
  Reachability TLVs (236 or 237).  Advertising the Flexible Algorithm
  locator in regular Prefix Reachability TLV (236 or 237) would make
  the forwarding for it to follow algo 0 path.

Perhaps this is more properly a matter for -flex-algo itself, but if
these locators are not to be advertised in TLVs 236/237 with the goal of
having forwarding for those prefixes not follow the algo(rithm) 0 path,
does that mean that the flexible algorithms can only be deployed in
networks where all routers support the flexible algorithm in question?
Bringing things closer to this document, would the presence of a mixed
deployment give grounds to violate the SHOULD NOT?

  are therefore advertised as sub-TLVs in TLVs 22, 23, 222, 223, and
  141.

[the same list that does not include TLV 25, again]

Section 6

  The A-flag and the N-flag MUST NOT both be set.  If both N-flag and
  A-flag are set in the prefix/SRv6 Locator advertisement, the
  receiving routers MUST ignore the N-flag.

This seems rather backwards-incompatible, since nodes that do not know
about this document will interpret only the N flag in this case.  Thus,
in a mixed network, if a prefix is advertised with both A- and N-flags
set, some nodes will treat it as identifying a node and other nodes will
treat it as an anycast address.  Since this is inherently an error
situation (it violates the quoted "MUST NOT"), what is the benefit from
having the 'A' bit take precedence?  It would seem equally valid, and
provide more uniform treatment across the network, to have the 'N' bit
take precedence in this case.  (Though, given that the N flag is ignored
for non-host-prefixes, I guess the A flag would take precedence in some
cases anyway, so maybe it is not quite so simple.)

Section 7.1

  The SRv6 Locator TLV has the following format:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type        |    Length    |R|R|R|R|    MT ID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I suggest adding some placeholder to the figure for "further entries
follow"; the current formulation suggests that only these four bytes
comprise the TLV.

        Metric: 4 octets. As described in [RFC5305].

I think more specificity is needed in the reference, since RFC 5305
describes both a 3-octet metric field in sub-TLV 18 and a 4-octet metric
field in TLV 135.

        Algorithm: 1 octet. As defined in [RFC8665].

Earlier we used 8667 as the reference for the SR-Algorithm values, since
that's the IS-IS document (8665 is what created the IANA registry, but
is otherwise about OSPF).

        Optional sub-TLVs: Sub-TLVs 1, 2, 4, 5, 11, 12 are allowed.
        Any other Sub-TLVs MUST be ignored.

I don't really understand why we hardcode a list here, given that we
also update the corresponding IANA registry in this document.  Don't we
want the IANA registry to be controlling in the future?

Section 8.1

      Algorithm: 1 octet.  As defined in [RFC8665].

[same comment as above]

Section 12

I'd also reference the security considerations of
draft-ietf-6man-spring-srv6-oam and draft-ietf-lsr-flex-algo.

Are there any new security considerations relating to anycast
announcements?  E.g., if the nodes advertising the same prefix/locator
are configured differently and traffic sent to the one vs the other gets
different treatment?

Given that I failed to convince the authors of RFC 8986 to add any text
about the security considerations of SID sub-structure, I don't expect
to be successful here, either.  But I note that being explicit about the
breakdown into func/arg/etc. makes it easier to construct SIDs that are
not advertised but might be processed on receipt, by combining a
known-valid function code with an argument value that provides semantics
that the advertising endpoint implements but did not choose to advertise
in this case.

Section 14.1

If we switch to using RFC 8667 as the reference for SR Algorithms for
IS-IS, then RFC 8665 could be relegated to an informative reference.

NITS

Abstract

  called "segments".  Segment routing architecture can be implemented
  over an MPLS data plane as well as an IPv6 data plane.  This document

I think an article ("the" or "a" at the start of this sentence would
help.

Section 4.4

      If the advertised value is zero or no value is advertised
      then the router cannot apply any behavior that results in
      decapsulation and forwarding of the inner packet if the
      other IPv6 header contains an SRH.

I think s/other/outer/

Section 6

  All the nodes advertising the same anycast locator MUST instantiate
  the exact same set of SIDs under such anycast locator.  Failure to do
  so may result in traffic being black-holed or mis-routed.

s/such/that/

Section 7.2

      Optional Sub-sub-TLVs.

A forward reference to the registry created in Section 11.5 might help.

Section 8

  This document defines two new sub-TLVs of TLV 22, 23, 222, 223, and
  141 - namely "SRv6 End.X SID sub-TLVs" and "SRv6 LAN End.X SID sub-
  TLVs".

I suggest sorting the list of TLV numbers.
[TLV 25, once again, does not appear in this list, as mentioned
previously.]

Section 8.1

        B-Flag: Backup flag.  If set, the SID is eligible for
        protection (e.g., using IPFRR) as described in [RFC8355].

RFC 8355 doesn't mention "IPFRR", so I think a reference for IPFRR is in
order.

Also, naively I would have expected a flag named "backup" to be set on
the thing that is the backup path, not on the primary path that is
eligible for protection.  So maybe a different mnemonic would be better?

        Reserved bits: MUST be zero when originated and ignored when
        received.

Using "MUST be ignored" would reduce the diff against §8.2.

      Sub-sub-TLV-length: 1 octet.  Number of octets used by sub-sub-
      TLVs.

As above, a forward-reference to the registry would be helpful.

Section 8.2

Putting the note that multiple TLVs might be needed for the same DIS
neighbor at the end of the section would reduce the diff against §8.1

      Sub-sub-TLV-length: 1 octet.  Number of octets used by sub-sub-
      TLVs.

As above, a forward-reference to the registry would be helpful.

Section 10

  registry defined in [RFC8986].  If this behavior is advertised it
  MUST only be advertised in the TLV[s] as indicated by "Y" in the

In a table with multiple entries, "this behavior" is not well defined;
"a behavior" would be more appropriate.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Thank you to Christian Hopps for his shepherd's write-up (including the WG consensus).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2 --
Any reason why the bits of the 'Flags' field are not reserved (except for the O-bit) ?  or be in a to-be-created IANA registry? I would expect the default value for sending them (usually 0) and what to do on the receiving side(s) when the value is not 0 (usually ignore them). E.g., see the section 7.1

-- Section 3 --
Isn't it obvious that the "Segment Routing Algorithm" is also supported by SRv6 routers ? Consider removing this section ?
If you prefer to keep it, then please use the wording "Segment Routing Algorithm" exactly as in the IANA registry.

-- Section 7.1 (also 7.2 and possibly others) --
The header 'Length' should not be defined as 'variable' as it is probably a fixed length of 1 octet. Specifying how it is measured and in which units (octets, 32-bit word, ...) is probably welcome.

-- Section 7.2 --
What is the default value of the "Flags" field?

== NITS ==

-- title-
Should the plural form be used for 'extension' ?

-- Section 1 --
s\topology/algorithm specific\topology/algorithm-specific\ ?

-- Section 13 --
While there is a rather long contributors list, there is no acknowledgement section. The latter is of course optional but usual. Should the doc shepherd or last call reviewers be acknowledged ?

[Ballot comment]
Below are some questions and comments. I'd appreciate a reply, thanks.

1. Abstract

  The Segment Routing (SR) allows for a flexible definition of end-to-

You either have too many, or not enough words here. Either “segment routing“ (remove “the“), or something like “the segment routing architecture“.

  called "segments".  Segment routing architecture can be implemented

And here you do need “the“ in front of “segment”.

  over an MPLS data plane as well as an IPv6 data plane.  This document

“An” -> “the” (two places)

  over an IPv6 data plane.

“An” -> “the”

  This documents updates RFC 7370 by modifying an existing registry.

“Documents” -> “document”

Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an RFC to update an IANA registry, without saying it updates a previous RFC that established that registry. I think the “updates” just confuses matters and clutters things up, and should be removed.

2. Section 1

  This documents updates [RFC7370] by modifying an existing registry
  (Section 11.1.2).

“Documents” -> “document”

See also comment #1 regarding update.

3. Section 4.3

  A non-zero SRH Max H.encaps MSD indicates that the headend can insert
  an SRH up to the advertised value.

“Up to the advertised value” doesn’t make sense. I guess you mean “can insert an SRH with up to the advertised number of SIDs”?

4. Section 4.4

  The Maximum End D MSD Type specifies the maximum number of SIDs
  present in an SRH when performing decapsulation. 

That makes sense.

              These includes, but
  not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with
  USD as defined in [RFC8986].

That doesn’t. How can a number include all those specific things? A number’s just an integer, right? Maybe you are providing some helpful context about the types of SIDs that are permitted to be present? If so, I expect this is specified elsewhere already, and this sentence is not helping; I would suggest removing it. If it does need to stay, it needs a rewrite for grammar and clarity. (Maybe you want something like “As specified in [RFC 8986] the permitted SID types include, but are not limited to, .”)

      If the advertised value is zero or no value is advertised
      then the router cannot apply any behavior that results in
      decapsulation and forwarding of the inner packet if the
      other IPv6 header contains an SRH.

What “other” IP header? Do you mean the outer header? The inner header? Something else?

5. Section 5

  In cases where a locator advertisement is received in both a Prefix
  Reachability TLV and an SRv6 Locator TLV - (e.g. prefix, prefix-
  length, MTID all being equal and Algorithm being 0 in Locator TLV),

Since “e.g.” means “for example” you’re saying the thing in the parentheses is only one example of a locator advertisement received in both? What’s another example? (Maybe the algo being 1 in both cases?)

But in any case the text above appears redundant with the text that immediately follows. Can’t the text above be deleted?

  In case where the same prefix, with the same prefix-length, MTID, and
  algorithm is received in both a Prefix Reachability TLV and an SRv6
  Locator TLV, the Prefix Reachability advertisement MUST be preferred
  when installing entries in the forwarding plane.  This is to prevent
  inconsistent forwarding entries between SRv6 capable and SRv6
  incapable routers.

“In case” -> “in the case” or “in cases”

6. Section 7.2

  Supported behavior values together with parent TLVs in which they
  area advertised are specified in Section 10 of this document.  Please

“Area” -> “are”

      Length: variable.

      Flags: 1 octet.  No flags are currently defined.

When you write “length: variable“, I think you mean “length: a 1 octet field, whose value is variable“, don’t you? Just like you write “flags: 1 octet“? I get that the value placed into the length field is variable, but the way you’ve written it, it says that the length of the length field is itself variable, which would make no sense.

This is not the only place in the document you specify a length field this way, but I guess you should fix all of them. I’m only noting it here.

  The SRv6 End SID MUST be a subnet of the associated Locator.  SRv6
  End SIDs which are not a subnet of the associated locator MUST be
  ignored.

Is a host route (which is what a SID is) technically a “subnet”? Can something which is not a net, be a subnet? It reads funny that way. If you change it, possibly “MUST be covered by the associated Locator“? (Although then for clarity you might need to define “covered“, which might not be any better.) (Same comment applies to Section 8 which also mentions “subnet”.)

7. Section 8.1

        B-Flag: Backup flag.  If set, the SID is eligible for
        protection (e.g., using IPFRR) as described in [RFC8355].

Please expand IPFRR on first use. And since you say “e.g.” meaning “for example”, do you contemplate some other kind of protection which is not IPFRR? If not, I think you could delete the parenthesis without loss of clarity.

8. Section 9

  SRv6 SID Structure Sub-Sub-TLV is used to advertise the as defined in
  [RFC8986].  It has the following format:

You’re missing something between “advertise the” and “as defined”.

      Length: 4 octets.

Similar to my earlier comment, I think what you mean is something like “Length: a 1 octet field, whose value is 4”.

  associated with it.  It's usage is outside of the scope of this
  document.

“It’s” -> “its”

9. Section 11

  and sub-sub-TLVs as well updating the ISIS TLV registry and defining

“As well as”

  a new registry.

Doesn’t it define several new registries?

10. Section 11.2

Shouldn’t there be a new subsection for the registry creation?

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Write-up for draft-ietf-lsr-isis-srv6-extensions-14

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard. Proposed Standard/Standards Track is the proper type of RFC
b/c it is defining the required behavior to allow for interoperability between
multiple implementations of the documented mechanism. Standards Track is
indicated on the title page.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

This draft describes the IS-IS extensions required to support Segment Routing
over an IPv6 data plane.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

There were some vigorous discussions with regards to the extensions (and the
underlying technology being supported by the extensions), but nothing
particularly rough in the resulting consensus on the extensions themselves.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, YANG
    Doctor, Media Type or other expert review, what was its course (briefly)? In
    the case of a Media Type review, on what date was the request posted?

There are multiple implementations of this work deployed.

Some implementation status is given in the document which will be removed prior
to publication.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alvaro Retana

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

The shepherd has reviewed the latest versions of this document.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No concerns based on the latest review.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No broader review is required.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

No concerns.

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

IPR disclosure has been filed, no WG discussion.

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

There is solid support for this document.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

The base document that this document supports was appealed, and that appeal was
declined. The shepherd is not aware of any threat to appeal this IGP extension
document though.

    (11) Identify any ID nits the Document Shepherd has found in this document.
        (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

One over-long line.

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

See (15).

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

There are 2 normative references to WIP, I-D.ietf-6man-spring-srv6-oam (in IETF
Last Call reviews) and I-D.ietf-lsr-flex-algo, which has cleared WGLC, and work
is progressing.

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of
        the document. Confirm that all protocol extensions that the document
        makes are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry,
        that allocations procedures for future registrations are defined, and
        a reasonable name for the new registry has been suggested (see RFC
        8126).

The IANA section seems OK. The registries being created do not include any
specific guidance for the designated experts (other than RFC7370); however, they
do refer to the relevant sections to which the registries relate. All protocol
extensions are correctly associated with reservations in IANA registries and
have been clearly identified.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

The following IANA registries are being created with Expert Review indicated:

- "sub-sub-TLVs of the SRv6 Capability sub-TLV"
- "sub-sub-TLVs for SRv6 End SID (5) (sub-TLV of TLVs 27, 135, 235, 236
  and 237) and SRv6 End.X SID (43)/SRv6 LAN End.X SID (44) (Sub-TLVs
  for TLVs 22, 23, 25, 141, 222, and 223)"
- "ISIS SRv6 Capabilities sub-TLV Flags"
- "ISIS SRv6 Locator TLV Flags"
- "ISIS SRv6 End SID sub-TLV Flags"
- "ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs Flags"

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, YANG modules,
        etc.

N/A

    (20) If the document contains a YANG module, has the module been checked
        with any of the recommended validation tools
        (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
        formatting validation? If there are any resulting errors or warnings,
        what is the justification for not fixing them at this time? Does the
        YANG module comply with the Network Management Datastore Architecture
        (NMDA) as specified in RFC8342?

No YANG.

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Write-up for draft-ietf-lsr-isis-srv6-extensions-14

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard. Proposed Standard/Standards Track is the proper type of RFC
b/c it is defining the required behavior to allow for interoperability between
multiple implementations of the documented mechanism. Standards Track is
indicated on the title page.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

This draft describes the IS-IS extensions required to support Segment Routing
over an IPv6 data plane.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

There were some vigorous discussions with regards to the extensions (and the
underlying technology being supported by the extensions), but nothing
particularly rough in the resulting consensus on the extensions themselves.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, YANG
    Doctor, Media Type or other expert review, what was its course (briefly)? In
    the case of a Media Type review, on what date was the request posted?

There are multiple implementations of this work deployed.

Some implementation status is given in the document which will be removed prior
to publication.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alvaro Retana

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

The shepherd has reviewed the latest versions of this document.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No concerns based on the latest review.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No broader review is required.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

No concerns.

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

IPR disclosure has been filed, no WG discussion.

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

There is solid support for this document.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

The base document that this document supports was appealed, and that appeal was
declined. The shepherd is not aware of any threat to appeal this IGP extension
document though.

    (11) Identify any ID nits the Document Shepherd has found in this document.
        (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

One over-long line.

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

See (15).

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

There are 2 normative references to WIP, I-D.ietf-6man-spring-srv6-oam and
I-D.ietf-lsr-flex-algo.

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of
        the document. Confirm that all protocol extensions that the document
        makes are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry,
        that allocations procedures for future registrations are defined, and
        a reasonable name for the new registry has been suggested (see RFC
        8126).

The IANA section seems OK. The registries being created do not include any
specific guidance for the designated experts (other than RFC7370); however, they
do refer to the relevant sections to which the registries relate. All protocol
extensions are correctly associated with reservations in IANA registries and
have been clearly identified.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

The following IANA registries are being created with Expert Review indicated:

- "sub-sub-TLVs of the SRv6 Capability sub-TLV"
- "sub-sub-TLVs for SRv6 End SID (5) (sub-TLV of TLVs 27, 135, 235, 236
  and 237) and SRv6 End.X SID (43)/SRv6 LAN End.X SID (44) (Sub-TLVs
  for TLVs 22, 23, 25, 141, 222, and 223)"
- "ISIS SRv6 Capabilities sub-TLV Flags"
- "ISIS SRv6 Locator TLV Flags"
- "ISIS SRv6 End SID sub-TLV Flags"
- "ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs Flags"

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, YANG modules,
        etc.

N/A

    (20) If the document contains a YANG module, has the module been checked
        with any of the recommended validation tools
        (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
        formatting validation? If there are any resulting errors or warnings,
        what is the justification for not fixing them at this time? Does the
        YANG module comply with the Network Management Datastore Architecture
        (NMDA) as specified in RFC8342?

No YANG.

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

"Abstract", paragraph 2, nit:
-    The Segment Routing (SR) allows for a flexible definition of end-to-
-  ----
+    Segment Routing (SR) allows for a flexible definition of end-to-

"Abstract", paragraph 3, nit:
-    This documents updates RFC 7370 by modifying an existing registry.
-                -
+    This document updates RFC 7370 by modifying an existing registry.

Section 4.1, paragraph 3, nit:
>  SRH Max Segments Left Type: 41 If no value is advertised the supported va
>                                ^^
"If" at the beginning of a sentence usually requires a 2nd clause. Maybe a
comma, question or exclamation mark is missing, or the sentence is incomplete
and should be joined with the following sentence.

Section 4.4, paragraph 2, nit:
>  when performing decapsulation. These includes, but not limited to, End.DX6,
>                                ^^^^^^^^^^^^^^
The verb 'includes' is singular. Did you mean: "This includes" or "These
include"?

Section 6, paragraph 11, nit:
>  of the embedded "X-bit" in any advertisement of the same prefix in TLVs 236
>                                ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 7.1, paragraph 16, nit:
> T be ignored if the Loc-Size is outside of this range. Locator: 1-16 octe
>                                ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 7.2, paragraph 2, nit:
> ogether with parent TLVs in which they area advertised are specified in Secti
>                                  ^^^^^^^^^^^^
Do not use a noun immediately after the pronoun 'they'. Use a verb or an
adverb, or possibly some other part of speech.

Section 8.1, paragraph 19, nit:
> e required in order to advertise all of the SRv6 SIDs associated with that n
>                                  ^^^^^^^^^^
Consider using "all the".

Section 8.2, paragraph 2, nit:
>  SID is associated. Given that a large number of neighbors may exist on a giv
>                                ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 8.2, paragraph 2, nit:
> bors may exist on a given LAN a large number of SRv6 LAN END.X SID sub- TLVs
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 8.2, paragraph 2, nit:
> e required in order to advertise all of the SRv6 SIDs associated with that n
>                                  ^^^^^^^^^^^^^
Consider using "all the".

Section 9, paragraph 16, nit:
> SID Structure Sub- Sub-TLV MUST be lower or equal to 128 bits. If the sum of
>                                    ^^^^^
Did you mean "less than"?

Section 9, paragraph 17, nit:
> ure of the SID associated with it. It's usage is outside of the scope of this
>                                    ^^^^
Did you mean "Its" (possessive pronoun) instead of 'It's' (short for 'it is')?

Section 9, paragraph 17, nit:
> associated with it. It's usage is outside of the scope of this document. 10.
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 11.1, paragraph 1, nit:
> t makes the following registrations in the the IS-IS TLV Codepoints registry.
>                                        ^^^^^^^
Maybe you need to remove one determiner so that only "the" or "the" is left.

Section 11.8, paragraph 2, nit:
> ts in the Flags field of the ISIS SRv6 SRv6 Locator TLV specified in this doc
>                                  ^^^^^^^^^
Possible typo: you repeated a word

Section 12, paragraph 3, nit:
> hat document apply too. The advertisement of an incorrect MSD value may have
>                            ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Document references draft-ietf-6man-spring-srv6-oam-08, but
draft-ietf-6man-spring-srv6-oam-10 is the latest available revision.

Document references draft-ietf-lsr-flex-algo-13, but
draft-ietf-lsr-flex-algo-15 is the latest available revision.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lsr-isis-srv6-extensions-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are fourteen actions which we must complete.

First, in the TLV Codepoints Registry located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for:

Value: 27
Name: SRv6 Locator TLV

will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the registry will be renamed to:

"Sub-TLVs for TLVs 27, 135, 235, 236, and 237 (SRv6 Locator, Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"

and a reference to [ RFC-to-be ] will be added to the registry.

Third, also in the renamed Sub-TLVs for TLVs 27, 135, 235, 236, and 237 (SRv6 Locator, Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for:

Type: 5
Description: SRv6 End SID sub-TLV

will be made permanent and its reference changed to [ RFC-to-be; Section 7.2 ].

Fourth, also in the renamed Sub-TLVs for TLVs 27, 135, 235, 236, and 237 (SRv6 Locator, Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

IANA will ensure that the registrations currently in the registry have the following parameters set:

Type 27 135 235 236 237

1 y y y y y
2 y y y y y
3 n y y y y
4 y y y y y
5 y n n n n
6 n y y y y
11 y y y y y
12 y y y y y
32 n y y y y

Fifth, in the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) also on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for:

Value: 25
Description: SRv6 Capabilities sub-TLV

will be made permanent and its reference changed to [ RFC-to-be; Section 2 ]

Sixth, a new registry is to be created called the Sub-sub-TLVs of the SRv6 Capability sub-TLV registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

The initial form of this new registry is:

Value Description Reference
0 Reserved [ RFC-to-be ]
1-255 Unassigned

Seventh, in the Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the following pair of temporary registrations:

Value: 43
Description: SRv6 End.X SID sub-TLV
Reference: [ RFC-to-be; Section 8.1 ]

Value: 44
Description: SRv6 LAN End.X SID sub-TLV
Reference: [ RFC-to-be; Section 8.2 ]

will be made permanent.

Eighth, in the IGP MSD-Types registry on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters/

four registrations will have their references changed to [ RFC-to-be ]:

Value Name Reference
-----------------------------------------------
41 SRH Max SL [ RFC-to-be ]
42 SRH Max End Pop [ RFC-to-be ]
44 SRH Max H.encaps [ RFC-to-be ]
45 SRH Max End D [ RFC-to-be ]

Ninth, a new registry is to be created called the Sub-sub-TLVs for SRv6 End SID (5) (sub-TLV of TLVs 27, 135, 235, 236 and 237) and SRv6 End.X SID (43)/SRv6 LAN End.X SID (44) (Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223) registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

The initial form of this new registry is:

Type Description Encoding
Reference
---------------------------------------------------------
0 Reserved
1 SRv6 SID Structure Sub-Sub-TLV [ RFC-to-be ]
2-255 Unassigned

For the registration for Type 1, the registry will note the following Sub-TLV fields:

Type 5 43 44
1 y y y

Tenth, in the Bit Values for Prefix Attribute Flags Sub-TLV registry also on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for:

Bit #: 4
Name: A bit

will be made permanent and changed to

Bit #: 4
Name: Anycast Flag (A-flag)
Reference: [ RFC-to-be; Section 6 ].

Eleventh, a new registry is to be created called the ISIS SRv6 Capabilities sub-TLV Flags registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

There is a single, initial registration in the new registry as follows:

Bit #: 1
Description: O-flag
Reference: [ RFC-to-be; Section 2 ]

Twelfth, a new registry is to be created called the ISIS SRv6 Locator TLV Flags registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

There is a single, initial registration in the new registry as follows:

Bit #: 0
Description: D-flag
Reference: [ RFC-to-be; Section 7.1 ]

Thirteenth, a new registry is to be created called the ISIS SRv6 End SID sub-TLV Flags registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

There are no initial registrations in this new registry.

Fourteenth, a new registry is to be created called the ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs Flags registry. This registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is Expert Review as defined in RFC 8126.

There are four, initial registrations in the new registry as follows:

Bit #: 0
Description: B-flag
Reference: [ RFC-to-be; Section 8.1 ]

Bit #: 1
Description: S-flag
Reference: [ RFC-to-be; Section 8.1 ]

Bit #: 2
Description: P-flag
Reference: [ RFC-to-be; Section 8.1 ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-05-07):

From: The IESG
To: IETF-Announce
CC: Christian Hopps , aretana.ietf@gmail.com, chopps@chopps.org, draft-ietf-lsr-isis-srv6-extensions@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS Extension to Support Segment
Routing over IPv6 Dataplane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Segment Routing (SR) allows for a flexible definition of end-to-
  end paths by encoding paths as sequences of topological sub-paths,
  called "segments".  Segment routing architecture can be implemented
  over an MPLS data plane as well as an IPv6 data plane.  This document
  describes the IS-IS extensions required to support Segment Routing
  over an IPv6 data plane.

  This documents updates RFC 7370 by modifying an existing registry.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3796/
  https://datatracker.ietf.org/ipr/4486/

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Write-up for draft-ietf-lsr-isis-srv6-extensions-11

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

This draft describes the IS-IS extensions required to support Segment Routing
over an IPv6 data plane.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

There were some vigorous discussions with regards to the extensions (and the
underlying technology being supported by the extensions), but nothing
particularly rough in the resulting consensus on the extensions themselves.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, YANG
    Doctor, Media Type or other expert review, what was its course (briefly)? In
    the case of a Media Type review, on what date was the request posted?

There are multiple implementations of this work deployed.

Some implementation status is given in the document which will be removed prior
to publication.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alvaro Retana

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

The shepherd has reviewed the latest versions of this document.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No concerns based on the latest review.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No broader review is required.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

The shepherd has a minor concern that the document that these extensions support
(I-D.ietf-spring-srv6-network-programming) is still progressing in the IETF with
continued controversy. These IS-IS extensions by themselves are not
controversial; however, the shepherd hopes that this document would not be used
in support dismissing Last Call concerns on the base document (i.e., for it to
be used as an "end-run" so to speak).

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

IPR disclosure has been filed, no WG discussion.

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

There is solid support for this document.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

The base document that this document supports was appealed, and that appeal was
declined. The shepherd is not aware of any threat to appeal this IGP extension
document though.

    (11) Identify any ID nits the Document Shepherd has found in this document.
        (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

Unused Reference: 'RFC7370'

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

See (15).

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

There is a reference to the base SPRING documents that this IS-IS extensions
document supports. As mentioned above there continues to be controversy over
the base document, although they do appear to be progressing none-the-less.

[I-D.ietf-6man-spring-srv6-oam]
[I-D.ietf-spring-srv6-network-programming]

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of
        the document. Confirm that all protocol extensions that the document
        makes are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry,
        that allocations procedures for future registrations are defined, and
        a reasonable name for the new registry has been suggested (see RFC
        8126).

The IANA section seems OK. The sub-sub-tlv registry being created does not
include any specific guidance for the designated experts. It does refer to the
relevant sections to which the registry relates.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

The IANA Registry: Sub-Sub-TLVs for SID Sub-TLVs is being created with expert review.

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, YANG modules,
        etc.

N/A

    (20) If the document contains a YANG module, has the module been checked
        with any of the recommended validation tools
        (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
        formatting validation? If there are any resulting errors or warnings,
        what is the justification for not fixing them at this time? Does the
        YANG module comply with the Network Management Datastore Architecture
        (NMDA) as specified in RFC8342?

No YANG.

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Write-up for draft-ietf-lsr-isis-srv6-extensions-11

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

Proposed Standard.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

This draft describes the IS-IS extensions required to support Segment Routing
over an IPv6 data plane.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

There were some vigorous discussions with regards to the extensions (and the
underlying technology being supported by the extensions), but nothing
particularly rough in the resulting consensus on the extensions themselves.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, YANG
    Doctor, Media Type or other expert review, what was its course (briefly)? In
    the case of a Media Type review, on what date was the request posted?

There are multiple implementations of this work deployed.

Some implementation status is given in the document which will be removed prior
to publication.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alvaro Retana

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

The shepherd has reviewed the latest versions of this document.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No concerns based on the latest review.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No broader review is required.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

The shepherd has a minor concern that the document that these extensions support
(I-D.ietf-spring-srv6-network-programming) is still progressing in the IETF with
continued controversy. These IS-IS extensions by themselves are not
controversial; however, the shepherd hopes that this document would not be used
in support dismissing Last Call concerns on the base document (i.e., for it to
be used as an "end-run" so to speak).

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

IPR disclosure has been filed, no WG discussion.

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

There is solid support for this document.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

The base document that this document supports was appealed, and that appeal was
declined. The shepherd is not aware of any threat to appeal this IGP extension
document though.

    (11) Identify any ID nits the Document Shepherd has found in this document.
        (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

Unused Reference: 'RFC7370'

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

See (15).

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

There is a reference to the base SPRING documents that this IS-IS extensions
document supports. As mentioned above there continues to be controversy over
the base document, although they do appear to be progressing none-the-less.

[I-D.ietf-6man-spring-srv6-oam]
[I-D.ietf-spring-srv6-network-programming]

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of
        the document. Confirm that all protocol extensions that the document
        makes are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that newly created IANA registries include
        a detailed specification of the initial contents for the registry,
        that allocations procedures for future registrations are defined, and
        a reasonable name for the new registry has been suggested (see RFC
        8126).

The IANA section seems OK. The sub-sub-tlv registry being created does not
include any specific guidance for the designated experts. It does refer to the
relevant sections to which the registry relates.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

The IANA Registry: Sub-Sub-TLVs for SID Sub-TLVs is being created with expert review.

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, YANG modules,
        etc.

N/A

    (20) If the document contains a YANG module, has the module been checked
        with any of the recommended validation tools
        (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
        formatting validation? If there are any resulting errors or warnings,
        what is the justification for not fixing them at this time? Does the
        YANG module comply with the Network Management Datastore Architecture
        (NMDA) as specified in RFC8342?

No YANG.