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

[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 quot;forward
  direction."

  During forward direction operation, the ONC RPC client is responsible
  for establishing transport connections.

1.3.2.  Backward Direction

  The ONC RPC standard does not forbid passing messages in the other
  direction.  An ONC RPC service endpoint can act as a caller, in which
  case an ONC RPC client endpoint acts as a responder.  This form of
  message passing is referred to as operation in the "backward
  direction."

  During backward direction operation, the ONC RPC client is
  responsible for establishing transport connections, even though ONC
  RPC calls may come from the ONC RPC server.

  ONC RPC clients and services are optimized to perform and scale well
  while handling traffic in the forward direction, and may not be
  prepared to handle operation in the backward direction.  Not until
  recently has there been a need to handle backward direction
  operation.

1.3.3.  Bi-direction

  A pair of endpoints may choose to use only forward or only backward
  direction operations on a particular transport.  Or, the endpoints
  may send operations in both directions concurrently on the same
  transport.

  Bi-directional operation occurs when both transport endpoints act as
  a caller and a responder at the same time.  As above, the ONC RPC
  client is responsible for establishing transport connections.

1.3.4.  XID Values

  Section 9 of [RFC5531] introduces the ONC RPC transaction identifier,
  or "xid" for short.  The value of an xid is interpreted in the
  context of the message's msg_type field.

Lever                  Expires November 30, 2015              [Page 4]
Internet-Draft          RPC-over-RDMA Bidirection              May 2015

  o  The xid of a call is arbitrary but is unique among outstanding
      calls from that caller.

  o  The xid of a reply always matches that of the initiating call.

  A caller matches the xid value in each reply with a call it
  previously sent.

1.3.4.1.  XIDs with Bi-direction

  During bi-directional operation, the forward and backward directions
  use independent xid spaces.

  In other words, a forward direction caller MAY use the same xid value
  at the same time as a backward direction caller on the same transport
  connection.  Though such concurrent requests use the same xid value,
  they represent distinct ONC RPC transactions.

1.4.  Rationale For RPC-over-RDMA Bi-Direction

1.4.1.  NFSv4.0 Callback Operation

  An NFSv4.0 client employs a traditional ONC RPC client to send NFS
  requests to an NFSv4.0 server's traditional ONC RPC service
  [RFC7530].  NFSv4.0 requests flow in the forward direction on a
  connection established by the client.  This connection is referred to
  as a "forechannel."

  NFSv4.0 introduces the use of callback operations, or "callbacks", in
  Section 10.2 of [RFC7530], for managing file delegation.  An NFSv4.0
  server sets up a traditional ONC RPC client, and an NFSv4.0 client
  sets up a traditional ONC RPC service to handle callbacks.  Callbacks
  flow in the forward direction on a connection established by an
  NFSv4.0 server.  This connection is distinct from connections being
  used as forechannels.  This connection is referred to as a
  "backchannel."

  When an RDMA transport is used as a forechannel, an NFSv4.0 client
  typically provides a TCP callback service.  The client's SETCLIENTID
  operation advertises the callback service endpoint with a "tcp" or
  "tcp6" netid.  The server then connects to this service using a TCP
  socket.

  NFSv4.0 implementations are fully functional without a backchannel in
  place.  In this case, the server does not grant file delegations.
  This might result in a negative performance effect, but functional
  correctness is unaffected.

Lever                  Expires November 30, 2015              [Page 5]
Internet-Draft          RPC-over-RDMA Bidirection              May 2015

1.4.2.  NFSv4.1 Callback Operation

  NFSv4.1 supports file delegation in a similar fashion to NFSv4.0, and
  extends the repertoire of callbacks to manage pNFS layouts, as
  discussed in Chapter 12 of [RFC5661].

  For various reasons, NFSv4.1 requires that all transport connections
  be initiated by NFSv4.1 clients.  Therefore, NFSv4.1 servers send
  callbacks to clients in the backward direction on connections
  established by NFSv4.1 clients.

  An NFSv4.1 client or server indicates to its peer that a backchannel
  capability is available on a given transport when sending a
  CREATE_SESSION or BIND_CONN_TO_SESSION operation.

  NFSv4.1 clients may establish distinct transport connections for
  forechannel and backchannel operation, or they may combine
  forechannel and backchannel operation on one transport connection
  using bi-directional operation.

  When an RDMA transport is used as a forechannel, an NFSv4.1 client
  must additionally connect using a transport with backward direction
  capability to use as a backchannel.  Without a backward direction
  RPC-over-RDMA capability, TCP is the only choice at present for an
  NFSv4.1 backchannel connection.

  Some implementations find it more convenient to use a single combined
  transport (ie. a transport that is capable of bi-directional
  operation).  This simplifies connection establishment and recovery
  during network partitions or when one endpoint restarts.

  As with NFSv4.0, if a backchannel is not in use, an NFSv4.1 server
  does not grant delegations.  But because of its reliance on callbacks
  to manage pNFS layout state, pNFS operation is not possible without a
  backchannel.

1.5.  Design Considerations

  As of this writing, the only use case for backward direction ONC RPC
  messages is the NFSv4.1 backchannel.  The conventions described in
  this document take advantage of certain characteristics of NFSv4.1
  callbacks, namely:

  o  NFSv4.1 callbacks typically bear small argument and result
      payloads

  o  NFSv4.1 callback payloads are insensitive to alignment relative to
      system pages

Lever                  Expires November 30, 2015              [Page 6]
Internet-Draft          RPC-over-RDMA Bidirection              May 2015

  o  NFSv4.1 callbacks are infrequent relative to forechannel
      operations

1.5.1.  Backward Compatibility

  Existing clients that implement RPC-over-RDMA version 1 should
  interoperate correctly with servers that implement RPC-over-RDMA with
  backward direction support, and vice versa.

  The approach taken here avoids altering the RPC-over-RDMA version 1
  XDR specification.  Keeping the XDR the same enables existing RPC-
  over-RDMA version 1 implementations to interoperate with
  implementations that support operation in the backward direction.

1.5.2.  Performance Impact

  Support for operation in the backward direction should never impact
  the performance or scalability of forward direction operation, where
  the bulk of ONC RPC transport activity typically occurs.

1.5.3.  Server Memory Security

  RDMA transfers involve one endpoint exposing a section of its memory
  to the other endpoint, which then drives RDMA READ and WRITE
  operations to access or modify the exposed memory.  RPC-over-RDMA
  client endpoints expose their memory, and RPC-over-RDMA server
  endpoints initiate RDMA data transfer operations.

  If RDMA transfers are not used for backward direction operations,
  there is no need for servers to expose their memory to clients.
  Further, this avoids the client complexity required to drive RDMA
  transfers.

1.5.4.  Payload Size

  Small RPC-over-RDMA messages are conveyed using only RDMA SEND
  operations.  SEND is used to transmit both ONC RPC calls and replies.

  To send a large payload, an RPC-over-RDMA client endpoint registers a
  region of memory known as a chunk, and transmits its coordinates to a
  server endpoint, who uses an RDMA transfer to move data to or from
  the client.  See Sections 3.1, 3.2, and 3.4 of [RFC5666].

  To transmit RPC-over-RDMA messages larger than the receive buffer
  size (typically 1024 bytes), a chunk must be used.  For example, in
  an RDMA_NOMSG type message, the entire RPC header and Upper Layer
  payload are contained in chunks.  See Section 5.1 of [RFC5666] for
  details.

Lever                  Expires November 30, 2015              [Page 7]
Internet-Draft          RPC-over-RDMA Bidirection              May 2015

  If chunks are not allowed to be used for conveying backward direction
  messages, an RDMA_NOMSG type message cannot be used to convey a
  backward direction message using the conventions described in this
  document.  Therefore, backward direction messages sent using the
  conventions in this document can be no larger than a single receive
  buffer.

  Stipulating such a limit on backward direction message size assumes
  that either Upper Layer Protocol consumers of backward direction
  messages can advertise this limit to peers, or that ULP consumers can
  agree by convention on a maximum size of their backchannel payloads.

  In addition, using only inline forms of RPC-over-RDMA messages and
  never populating the RPC-over-RDMA chunk lists means that the RPC
  header's msg_type field is always at a fixed location in messages
  flowing in the backward direction, allowing efficient detection of
  the direction of an RPC-over-RDMA message.

  With few exceptions, NFSv4.1 servers can break down callback requests
  so they fit within this limit.  There are potentially large NFSv4.1
  callback operations, such as a CB_GETATTR operation where a large ACL
  must be conveyed.  Although we are not aware of any NFSv4.1
  implementation that uses CB_GETATTR, this state of affairs is not
  guaranteed in perpetuity.

2.  Conventions For Backward Operation

  Performing backward direction ONC RPC operations over an RPC-over-
  RDMA transport can be accomplished within limits by observing the
  conventions described in the following subsections.  For reference,
  the XDR description of RPC-over-RDMA version 1 is contained in
  Section 4.3 of [RFC5666].

2.1.  Flow Control

  For an RDMA SEND operation to work, the receiving consumer must have
  posted an RDMA RECV Work Request to provide a receive buffer in which
  to capture the incoming message.  If a receiver hasn't posted enough
  RECV WRs to catch incoming SEND operations, the RDMA provider is
  allowed to drop the RDMA connection.

  The RPC-over-RDMA version 1 protocol provides built-in send flow
  control to prevent overrunning the number of pre-posted receive
  buffers on a connection's receive endpoint.  This is fully discussed
  in Section 3.3 of [RFC5666].

Lever                  Expires November 30, 2015              [Page 8]
Internet-Draft          RPC-over-RDMA Bidirection              May 2015

2.1.1.  Forward Credits

  An RPC-over-RDMA credit is roughly the capability to handle one RPC-
  over-RDMA transaction.  Each forward direction RPC-over-RDMA call
  requests a number of credits from the responder.  Each forward
  direction reply informs the caller how many credits the responder is
  prepared to handle in total.  The value of the request and grant are
  carried in each RPC-over-RDMA message's rdma_credit field.

  Practically speaking, the critical value is the value of the
  rdma_credit field in RPC-over-RDMA replies.  When a caller is
  operating correctly, it sends no more outstanding requests at a time
  than the responder&, 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