Dynamic Flooding on Dense Graphs
draft-ietf-lsr-dynamic-flooding-18

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-lsr-dynamic-flooding and RFC 9667, changed IESG state to RFC Published)

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-dynamic-flooding-17
# Intended RFC status: Experimental

Thank you for the work put into this document. This document is a joy to read and documents an elegant solution to a well known IGP problem problem space.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

Special thanks to Acee Lindem for the shepherd's write-up and to Sue Hares for the Routing Directorate review.

before jumping into some idnits and comment review details, i wanted to express that it was entertaining to read about terminology used within  graph theory discussing Hamiltonian cycle, bipartite graph, K5,9 etc.

Please find some observations and COMMENTS which appeared during my ballot review process. I hope it can help or contribute with the quality of the draft-ietf-lsr-dynamic-flooding-17 document.

409   Similarly, if additional redundancy is added to the flooding
410   topology, specific nodes in that topology may end up with a very high
411   degree.  This could result in overloading the control plane of those

The text reads smooth, until the term 'degree' pops up without explanation what it entails. I (non-native English speaker) suspect it is terminology from graph theory. I do recall it being mentioned within the presentations about this draft in LSR WG. Maybe a short line explaining what degree in graph theory is may help with the document for non-native English speakers.

In my search for some level of understanding on what to understand of degree:

"In graph theory, the degree of a vertex refers to the number of edges connected to that vertex. For undirected graphs, this simply means the count of edges touching the vertex. For directed graphs, you can distinguish between the "in-degree" and the "out-degree" of a vertex: the in-degree is the number of edges coming into the vertex, and the out-degree is the number of edges going out from the vertex.

For example, in an undirected graph, if a vertex has three edges connected to it, its degree is 3. In a directed graph, if a vertex has two arrows pointing to it and one arrow pointing away, its in-degree is 2 and its out-degree is 1."

417   If the leader chooses to include a multi-access broadcast LAN segment
418   as part of the flooding topology, all of the links in that LAN
419   segment should be included as well.  Once updates are flooded on the
420   LAN, they will be received by every attached node.

The links mentioned here seem to not correspond to the physical links but instead to the graph links.
I assume a link here is from each unique router on the LAN segment to the DR/DIS and from the DR/DIS to each unique router connected on the LAN segment?
Or is the term link referencing to something else?

422 4.4.  Topologies on Complete Bipartite Graphs

I agree with the comments from others that a short drawing would make the topology descriptions easier to comprehend

493   If two nodes are adjacent on the flooding topology and there are a
494   set of parallel links between them, then any given update MUST be
495   flooded over a single one of those links.  The selection of the

small proposed re-edit for reading clarity:

"If two nodes are adjacent in the flooding topology and there is a set of parallel links between them, then any given update MUST be flooded over only one of those links"

513   these edges is optional.  Note that this may result in the
514   possibility of "hidden nodes" which are part of the flooding topology

I have sometimes seen the term "stealth" used for hidden nodes or devices

525   Other encodings are certainly possible.  We have attempted to make a
526   useful trade-off between simplicity, generality, and space.

Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it in favor of more
direct or passive constructions to maintain formal tone and objectivity.

662 5.1.3.  IS-IS Area Node IDs TLV

Not sure it is clear from the text paragraph where this TLV is inserted in the hierarchy of TLVs.
For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is explicitly mentioned.
(TLVs in section 5.1.4/5.1.5/5.1.6 do not have a explicit indication of place in the TLV hierarchy either)

693       Length: 3 + ((System ID Length + 1) * (number of node IDs))

Should it be mentioned that the unit is octets? if ever a yang is created it will be in there documented anyway
why does length start with '3'? I am missing a calculation logic

826   In support of advertising which edges are currently enabled in the
827   flooding topology, an implementation MAY indicate that a link is part
828   of the flooding topology by advertising a bit-value in the Link
829   Attributes sub-TLV defined by [RFC5029].

The register is standards action. and that seems according RFC8126 section 4 (https://www.rfc-editor.org/rfc/rfc8126.html#section-4) to require a standards track document or a BCP. This document is target to be experimental.

4.9.  Standards Action

  For the Standards Action policy, values are assigned only through
  Standards Track or Best Current Practice RFCs in the IETF Stream.

1978   IANA is requested to set up a registry called "IGP Algorithm Type For
1979   Computing Flooding Topology" under the existing "Interior Gateway
1980   Protocol (IGP) Parameters" IANA registry.

Not explicit mentioned here, but which IANA a Registration Policy is implied?
https://www.rfc-editor.org/rfc/rfc8126.html#section-4

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-dynamic-flooding-17

Thank you for the work put into this document. This document is a joy to read and documents an elegant solution to a well known IGP problem problem space.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

Special thanks to Acee Lindem for the shepherd's write-up and to Sue Hares for the Routing Directorate review.

before jumping into some idnits and comment review details, i wanted to express that it was entertaining to read about terminology used within  graph theory discussing Hamiltonian cycle, bipartite graph, K5,9 etc.

Please find some observations and COMMENTS which appeared during my ballot review process. I hope it can help or contribute with the quality of the draft-ietf-lsr-dynamic-flooding-17 document.

409   Similarly, if additional redundancy is added to the flooding
410   topology, specific nodes in that topology may end up with a very high
411   degree.  This could result in overloading the control plane of those

The text reads smooth, until the term 'degree' pops up without explanation what it entails. I (non-native English speaker) suspect it is terminology from graph theory. I do recall it being mentioned within the presentations about this draft in LSR WG. Maybe a short line explaining what degree in graph theory is may help with the document for non-native English speakers.

In my search for some level of understanding on what to understand of degree:

"In graph theory, the degree of a vertex refers to the number of edges connected to that vertex. For undirected graphs, this simply means the count of edges touching the vertex. For directed graphs, you can distinguish between the "in-degree" and the "out-degree" of a vertex: the in-degree is the number of edges coming into the vertex, and the out-degree is the number of edges going out from the vertex.

For example, in an undirected graph, if a vertex has three edges connected to it, its degree is 3. In a directed graph, if a vertex has two arrows pointing to it and one arrow pointing away, its in-degree is 2 and its out-degree is 1."

417   If the leader chooses to include a multi-access broadcast LAN segment
418   as part of the flooding topology, all of the links in that LAN
419   segment should be included as well.  Once updates are flooded on the
420   LAN, they will be received by every attached node.

The links mentioned here seem to not correspond to the physical links but instead to the graph links.
I assume a link here is from each unique router on the LAN segment to the DR/DIS and from the DR/DIS to each unique router connected on the LAN segment?
Or is the term link referencing to something else?

422 4.4.  Topologies on Complete Bipartite Graphs

I agree with the comments from others that a short drawing would make the topology descriptions easier to comprehend

493   If two nodes are adjacent on the flooding topology and there are a
494   set of parallel links between them, then any given update MUST be
495   flooded over a single one of those links.  The selection of the

small proposed re-edit for reading clarity:

"If two nodes are adjacent in the flooding topology and there is a set of parallel links between them, then any given update MUST be flooded over only one of those links"

513   these edges is optional.  Note that this may result in the
514   possibility of "hidden nodes" which are part of the flooding topology

I have sometimes seen the term "stealth" used for hidden nodes or devices

525   Other encodings are certainly possible.  We have attempted to make a
526   useful trade-off between simplicity, generality, and space.

Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it in favor of more
direct or passive constructions to maintain formal tone and objectivity.

662 5.1.3.  IS-IS Area Node IDs TLV

Not sure it is clear from the text paragraph where this TLV is inserted in the hierarchy of TLVs.
For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is explicitly mentioned.
(TLVs in section 5.1.4/5.1.5/5.1.6 do not have a explicit indication of place in the TLV hierarchy either)

693       Length: 3 + ((System ID Length + 1) * (number of node IDs))

Should it be mentioned that the unit is octets? if ever a yang is created it will be in there documented anyway
why does length start with '3'? I am missing a calculation logic

826   In support of advertising which edges are currently enabled in the
827   flooding topology, an implementation MAY indicate that a link is part
828   of the flooding topology by advertising a bit-value in the Link
829   Attributes sub-TLV defined by [RFC5029].

The register is standards action. and that seems according RFC8126 section 4 (https://www.rfc-editor.org/rfc/rfc8126.html#section-4) to require a standards track document or a BCP. This document is target to be experimental.

4.9.  Standards Action

  For the Standards Action policy, values are assigned only through
  Standards Track or Best Current Practice RFCs in the IETF Stream.

1978   IANA is requested to set up a registry called "IGP Algorithm Type For
1979   Computing Flooding Topology" under the existing "Interior Gateway
1980   Protocol (IGP) Parameters" IANA registry.

Not explicit mentioned here, but which IANA a Registration Policy is implied?
https://www.rfc-editor.org/rfc/rfc8126.html#section-4

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-dynamic-flooding-17

Thank you for the work put into this document. This document is a joy to read and documents an elegant solution to a well known IGP problem problem space.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

Special thanks to Acee Lindem for the shepherd's write-up and to Sue Hares for the Routing Directorate review.

before jumping into some idnits and review details i was entertaining experience and education to read about (for myself at least) terminology in graph theory discussing Hamiltonian cycle, bipartite graph, K5,9 etc.

In next section there are some observations or COMMENTS for my ballot review process. I hope it can help or contribute with the ongoing improvement of the draft-ietf-lsr-dynamic-flooding-17 document.

409   Similarly, if additional redundancy is added to the flooding
410   topology, specific nodes in that topology may end up with a very high
411   degree.  This could result in overloading the control plane of those

The text reads smooth, until the term 'degree' pops up without explanation what it entails. I suspect it is terminology from graph theory, and i recall it being mentioned within the presentations about this draft. Maybe a short line explaining what degree in graph theory is may help with the document.

In my search for some level of understanding on what to understand of degree:

"In graph theory, the degree of a vertex refers to the number of edges connected to that vertex. For undirected graphs, this simply means the count of edges touching the vertex. For directed graphs, you can distinguish between the "in-degree" and the "out-degree" of a vertex: the in-degree is the number of edges coming into the vertex, and the out-degree is the number of edges going out from the vertex.

For example, in an undirected graph, if a vertex has three edges connected to it, its degree is 3. In a directed graph, if a vertex has two arrows pointing to it and one arrow pointing away, its in-degree is 2 and its out-degree is 1."

417   If the leader chooses to include a multi-access broadcast LAN segment
418   as part of the flooding topology, all of the links in that LAN
419   segment should be included as well.  Once updates are flooded on the
420   LAN, they will be received by every attached node.

The links mentioned here seem to not correspond to the physical links but instead to the graph links.
I assume a link here is from each unique router on the LAN segment to the DR/DIS and from the DR/DIS to each unique router connected on the LAN segment?
Or is the term link referencing to something else?

422 4.4.  Topologies on Complete Bipartite Graphs

I agree with the comments from others that a short drawing would make the topology descriptions easier to comprehend

493   If two nodes are adjacent on the flooding topology and there are a
494   set of parallel links between them, then any given update MUST be
495   flooded over a single one of those links.  The selection of the

small proposed re-edit for reading clarity:

If two nodes are adjacent in the flooding topology and there is a set of parallel links between them, then any given update MUST be flooded over only one of those links

513   these edges is optional.  Note that this may result in the
514   possibility of "hidden nodes" which are part of the flooding topology

I have sometimes seen the term "stealth" used for hidden nodes or devices

525   Other encodings are certainly possible.  We have attempted to make a
526   useful trade-off between simplicity, generality, and space.

Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it in favor of more
direct or passive constructions to maintain formal tone and objectivity.

662 5.1.3.  IS-IS Area Node IDs TLV

Not sure it is clear from the text paragraph where this TLV is inserted in the hierarchy of TLVs.
For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is explicitly mentioned.
(TLVs in section 5.1.4/5.1.5/5.1.6 do not have a explicit indication of place in the TLV hierarchy either)

693       Length: 3 + ((System ID Length + 1) * (number of node IDs))

Should it be mentioned that the unit is octets? if ever a yang is created it will be in there documented anyway
why does length start with '3'? I am missing a calculation logic

826   In support of advertising which edges are currently enabled in the
827   flooding topology, an implementation MAY indicate that a link is part
828   of the flooding topology by advertising a bit-value in the Link
829   Attributes sub-TLV defined by [RFC5029].

The register is standards action. and that seems according RFC8126 section 4 (https://www.rfc-editor.org/rfc/rfc8126.html#section-4) to require a standards track document or a BCP. This document is target to be experimental.

4.9.  Standards Action

  For the Standards Action policy, values are assigned only through
  Standards Track or Best Current Practice RFCs in the IETF Stream.

1978   IANA is requested to set up a registry called "IGP Algorithm Type For
1979   Computing Flooding Topology" under the existing "Interior Gateway
1980   Protocol (IGP) Parameters" IANA registry.

Not explicit mentioned here, but which IANA a Registration Policy is implied?
https://www.rfc-editor.org/rfc/rfc8126.html#section-4

[Ballot comment]
# Internet AD comments for draft-ietf-lsr-dynamic-flooding-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4

* Just as an observation: a diagram or two might have been helpful (if any
  are actually usefully expressible in our publication format(s)).

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

IANA has completed its review of draft-ietf-lsr-dynamic-flooding-16. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are thirteen actions which we must complete.

First, in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV registry in the IS-IS TLV Codepoints registry group located at:

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

The following temporary registrations for two codepoints will be made permanent and their references changed.

Type: 27
Description: IS-IS Area Leader Sub-TLV
Reference: [ RFC-to-be; Section 5.1.1 ]

Type: 28
Description: IS-IS Dynamic Flooding Sub-TLV
Reference: [ RFC-to-be; Section 5.1.2 ]

Second, in the IS-IS Top-Level TLV Codepoints registry in the IS-IS TLV Codepoints registry group located at:

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

The following temporary registrations for three codepoints will be made permanent and their references changed.

Type: 17
Description: IS-IS Area System IDs TLV
Reference: [ RFC-to-be; Section 5.1.3 ]

Type: 18
Description: IS-IS Flooding Path TLV
Reference: [ RFC-to-be; Section 5.1.4 ]

Type: 19
Description: IS-IS Flooding Request TLV
Reference: [ RFC-to-be; Section 5.1.5]

Third, in the IS-IS Neighbor Link-Attribute Bit Values registry also in the IS-IS TLV Codepoints registry group located at:

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

the "IS-IS Neighbor Link-Attribute Bit Values" registry will be expanded to contain a new "L2BM" column that indicates if a bit may appear in an L2 Bundle Member Attributes TLV. All existing rows should have the value "N" for "L2BM".

In addition, the following explanatory note will be added to the registry:

The "L2BM" column indicates applicability to the L2 Bundle Member Attributes TLV. The options for the "L2BM" column are:

Y - This bit MAY appear in the L2 Bundle Member Attributes TLV.

N - This bit MUST NOT appear in the L2 Bundle Member Attributes TLV.

Fourth, in the IS-IS Neighbor Link-Attribute Bit Values registry also in the IS-IS TLV Codepoints registry group located at:

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

The following temporary registration for a single codepoint will be made permanent and the reference changed.

Value: 0x4
L2BM: N
Name: Local Edge Enabled for Flooding (LEEF)
Reference: [ RFC-to-be ]

Fifth, in the OSPF Router Information (RI) TLVs registry in the Open Shortest Path First (OSPF) Parameters registry group located at:

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

The following temporary registrations for two codepoints will be made permanent and their references changed.

Type: 17
Description: OSPF Area Leader Sub-TLV
Reference: [ RFC-to-be; Section 5.2.1 ]

Type: 18
Description: OSPF Dynamic Flooding Sub-TLV
Reference: [ RFC-to-be; Section 5.2.2 ]

Sixth, in the Opaque Link-State Advertisements (LSA) Option Types registry located at:

https://www.iana.org/assignments/ospf-opaque-types/

The following temporary registration for a single codepoint will be made permanent and the reference changed.

Type: 10
Description: OSPFv2 Dynamic Flooding Opaque LSA
Reference: [ RFC-to-be; Section 5.2.3 ]

Seventh, in the OSPFv3 LSA Function Codes registry in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

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

The following temporary registration for a single codepoint will be made permanent and the reference changed.

Type: 16
Description: OSPFv3 Dynamic Flooding LSA
Reference: [ RFC-to-be; Section 5.2.4 ]

Eighth, in the LLS Type 1 Extended Options and Flags registry in the Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV) registry group located at:

https://www.iana.org/assignments/ospf-lls-tlvs/

the following early registration will be made permanent and have its reference changed:

This document requests a new bit in the "LLS Type 1 Extended Options and Flags" registry:

Bit Position: 0x00000020
Description: Flooding Request bit
Reference: [ RFC-to-be; Section 5.2.7 ]

Ninth, in the OSPFv2 Extended Link TLV Sub-TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

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

The following temporary registration for a single codepoint will be made permanent, the L2BM value will be changed and the reference changed.

Type: 21
Description: OSPFv2 Link Attributes Bits Sub-TLV
Reference: [ RFC-to-be; Section 5.2.8 ]
L2 Bundle Member Attributes (L2BM): Y

Tenth, in the OSPFv3 Extended LSA Sub-TLVs registry in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

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

The following temporary registration for a single codepoint will be made permanent, the L2BM value will be changed and the reference changed.

Type: 10
Description: OSPFv3 Link Attributes Bits Sub-TLV
Reference: [ RFC-to-be; Section 5.2.8 ]
L2 Bundle Member Attributes (L2BM): Y

Eleventh, a new registry will be created called the OSPF Dynamic Flooding LSA TLVs registry. The new registry will be located in the Open Shortest Path First (OSPF) Parameters registry group located at:

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

The registration policy for the new registry is as follows:

0: reserved
1 - 32767: IETF Review or IESG Approval
32768-33023: Experimental Use
33024-65535: Not available for assignment (see [ RFC-to-be ]

There are three initial registrations in the new registry as follows:

Type: 0
Description: Reserved
Reference: [ RFC-to-be ]

Type: 1
Description: OSPF Area Router IDs TLV
Reference: [ RFC-to-be; Section 5.2.5 ]

Type: 2
Description: OSPF Flooding Path TLV
Reference: [ RFC-to-be; Section 5.2.6 ]

Twelveth, a new registry will be created called the OSPF Link Attributes Sub-TLV Bit registry. The new registry will be located in the Open Shortest Path First (OSPF) Parameters registry group located at:

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

The following explanatory note will be added to the registry:

The "L2BM" column indicates applicability to the L2 Bundle Member Attributes sub-TLV. The options for the "L2BM" column are:

Y - This bit MAY appear in the L2 Bundle Member Attributes sub-TLV.

N - This bit MUST NOT appear in the L2 Bundle Member Attributes sub-TLV.

The registration policy for the new registry is as follows: IETF Review or IESG Approval.

The following initial value will be allocated:

Bit Number: 0
Description: Local Edge Enabled for Flooding(LEEF)
Reference: [ RFC-to-be; Section 5.2.8 ]
L2 Bundle Member Attributes (L2BM): N

Thirteenth, a new registry is to be created called the IGP Algorithm Type For Computing Flooding Topology registry. The new registry will be placed in the Interior Gateway Protocol (IGP) Parameters registry group located at:

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

Values in this registry come from the range 0-255.

The registration rules for the new registry are as follows:

0-127: Expert Review
128-254: Reserved for private use
255: Reserved

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

Type: 0
Description: Reserved for centralized mode.
Reference: [ RFC-to-be ]

We understand that these thirteen actions are the only ones 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-29):

From: The IESG
To: IETF-Announce
CC: Acee Lindem , acee.ietf@gmail.com, draft-ietf-lsr-dynamic-flooding@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Dynamic Flooding on Dense Graphs) to Experimental RFC


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Dynamic Flooding on Dense Graphs'
  as Experimental RFC

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 2024-02-29. 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


  Routing with link state protocols in dense network topologies can
  result in sub-optimal convergence times due to the overhead
  associated with flooding.  This can be addressed by decreasing the
  flooding topology so that it is less dense.

  This document discusses the problem in some depth and an
  architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
  and OSPFv3 are described in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/


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

  https://datatracker.ietf.org/ipr/3361/
  https://datatracker.ietf.org/ipr/3684/
  https://datatracker.ietf.org/ipr/3686/
  https://datatracker.ietf.org/ipr/4044/
  https://datatracker.ietf.org/ipr/4017/
  https://datatracker.ietf.org/ipr/3164/

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a strong consensus for this document. Interest peaked during its intial
discussion and evolution.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Initially, there was a controversy with respect to distributed vs centralized
computation of the flooding topology. The draft evolved to support either model.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one existing implementation. It is not reported formally due to a change
in affiliation of the primary author.

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The draft is specific to the IGPs and has been reviewed by the Routing Directorate.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - given that there is only one implementation, the WG decided on experimental
status.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The draft is Experimental due to there only being one IS-IS implementation and the
fact that it represents a significant change to the existing IGP flooding mode.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. There was concern with Huawei's "Resonable and Non-Discriminatory License to
All Implementers with Possible Royalty/Fee." terms. However, there was no change in
terms despite the concern.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.

None - other than the copyright needs to be updated to 2024 due to the review cycles.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.   

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The shepherd was involved in all phases of the IANA review for this document,
the discussion of the new registries. and the reflection of Link Bundle Member
applicability for IS-IS and OSPF Link-Attribute bits.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new registry, "OSPF Link Attributes Sub-TLV Bit Values", requires IETF review
or IETF specification.

The new registry, "IGP Algorithm Type For Computing Flooding Topology", assignments
are made via the "Specificaition Required" policy in RFC 8126.

An existing registry, "IS-IS Neighbor Link-Attribute Bit Values", had a new column
added for Link Bundle Member applicability. The existing Designated Expert review
for this registry will suffice.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a strong consensus for this document. Interest peaked during its intial
discussion and evolution.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Initially, there was a controversy with respect to distributed vs centralized
computation of the flooding topology. The draft evolved to support either model.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one existing implementation.

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The draft is specific to the IGPs and has been reviewed by the Routing Directorate.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes - given that there is only one implementation, the WG decided on experimental
status.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The draft is Experimental due to there only being one IS-IS implementation and the
fact that it represents a significant change to the existing IGP flooding mode.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. There was concern with Huawei's "Resonable and Non-Discriminatory License to
All Implementers with Possible Royalty/Fee." terms. However, there was no change in
terms despite the concern.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.

None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.   

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The shepherd was involved in all phases of the IANA review for this document,
the discussion of the new registries. and the reflection of Link Bundle Member
applicability for IS-IS and OSPF Link-Attribute bits.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new registry, "OSPF Link Attributes Sub-TLV Bit Values", requires IETF review
or IETF specification.

The new registry, "IGP Algorithm Type For Computing Flooding Topology", assignments
are made via the "Specificaition Required" policy in RFC 8126.

An existing registry, "IS-IS Neighbor Link-Attribute Bit Values", had a new column
added for Link Bundle Member applicability. The existing Designated Expert review
for this registry will suffice.

Request for posting confirmation emailed to previous authors: David Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak , Srinath Dontula , Tony Li , Tony Przygienda , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: David Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak , Srinath Dontula , Tony Li , Tony Przygienda , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Dave Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak , Srinath Dontula , Tony Li , Tony Przygienda , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tony Li , Dave Cooper , Srinath Dontula , lsr-chairs@ietf.org, Huaimo Chen , Luay Jalil , Gyan Mishra , Tony Przygienda , Peter Psenak , Les Ginsberg

Request for posting confirmation emailed to previous authors: Peter Psenak , Les Ginsberg , Tony Li , Dave Cooper , Srinath Dontula , Tony Przygienda , Huaimo Chen , Luay Jalil , lsr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Luay Jalil , lsr-chairs@ietf.org, Tony Przygienda , Huaimo Chen , Peter Psenak , Tony Li , Dave Cooper , Les Ginsberg , Srinath Dontula

Request for posting confirmation emailed to previous authors: Les Ginsberg , lsr-chairs@ietf.org, Tony Li , Luay Jalil , Peter Psenak , Huaimo Chen , Tony Przygienda , Srinath Dontula , Dave Cooper

Request for posting confirmation emailed to previous authors: Huaimo Chen , Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , Les Ginsberg , Tony Przygienda

Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , Les Ginsberg , Tony Przygienda

Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , Les Ginsberg , Tony Przygienda

Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , Les Ginsberg , Tony Przygienda