Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-03-20
17 John Scudder Shepherding AD changed to John Scudder
2024-03-20
17 Cindy Morgan Shepherding AD changed to Gunter Van de Velde
2024-03-17
17 Cindy Morgan Placed on agenda for telechat - 2024-04-04
2024-03-16
17 John Scudder Ballot has been issued
2024-03-16
17 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2024-03-16
17 John Scudder Created "Approve" ballot
2024-03-16
17 John Scudder IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-03-16
17 John Scudder Ballot writeup was changed
2024-03-16
17 (System) Changed action holders to John Scudder (IESG state changed)
2024-03-16
17 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-03-16
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-03-16
17 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-17.txt
2024-03-16
17 Tony Li New version accepted (logged-in submitter: Tony Li)
2024-03-16
17 Tony Li Uploaded new revision
2024-03-06
16 (System) Changed action holders to Tony Li, Peter Psenak, Huaimo Chen, Luay Jalil, Srinath Dontula (IESG state changed)
2024-03-06
16 John Scudder IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-03-06
16 Chris Lonvick Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list.
2024-02-29
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-02-28
16 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-02-28
16 David Dong
(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 …
(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
2024-02-28
16 Reese Enghardt Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Reese Enghardt. Sent review to list.
2024-02-22
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2024-02-16
16 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2024-02-15
16 Jean Mahoney Request for Last Call review by GENART is assigned to Reese Enghardt
2024-02-15
16 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-02-15
16 Cindy Morgan
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, …
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/





2024-02-15
16 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-02-15
16 John Scudder Last call was requested
2024-02-15
16 John Scudder Last call announcement was generated
2024-02-15
16 John Scudder Ballot approval text was generated
2024-02-15
16 John Scudder Ballot writeup was generated
2024-02-15
16 John Scudder IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-02-14
16 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-16.txt
2024-02-14
16 Tony Li New version accepted (logged-in submitter: Tony Li)
2024-02-14
16 Tony Li Uploaded new revision
2024-02-06
15 (System) Changed action holders to John Scudder (IESG state changed)
2024-02-06
15 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-06
15 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-15.txt
2024-02-06
15 Tony Li New version accepted (logged-in submitter: Tony Li)
2024-02-06
15 Tony Li Uploaded new revision
2024-01-24
14 John Scudder See https://mailarchive.ietf.org/arch/msg/lsr/TutLM1AKoPRxSO_-q58-ya0VoD0/
2024-01-24
14 (System) Changed action holders to Tony Li, Peter Psenak, Huaimo Chen, Luay Jalil, Srinath Dontula (IESG state changed)
2024-01-24
14 John Scudder IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2024-01-10
14 Acee Lindem
1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad …
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.
2024-01-10
14 Acee Lindem Notification list changed to Acee Lindem <acee@cisco.com>, acee.ietf@gmail.com from Acee Lindem <acee@cisco.com> because the document shepherd was set
2024-01-10
14 Acee Lindem Document shepherd changed to Acee Lindem
2023-12-06
14 (System) Changed action holders to John Scudder (IESG state changed)
2023-12-06
14 John Scudder IESG state changed to AD Evaluation from Publication Requested
2023-06-15
14 Acee Lindem
1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad …
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.
2023-06-08
14 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-14.txt
2023-06-08
14 (System) New version approved
2023-06-08
14 (System) Request for posting confirmation emailed to previous authors: Huaimo Chen , Luay Jalil , Peter Psenak , Srinath Dontula , Tony Li
2023-06-08
14 Tony Li Uploaded new revision
2023-06-05
13 Susan Hares Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list.
2023-05-23
13 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Susan Hares
2023-05-22
13 Alvaro Retana Assignment of request for Last Call review by RTGDIR to Alvaro Retana was rejected
2023-05-21
13 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Alvaro Retana
2023-05-21
13 Haomian Zheng Assignment of request for Last Call review by RTGDIR to Ravi Singh was rejected
2023-05-08
13 Acee Lindem Responsible AD changed to John Scudder
2023-05-08
13 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2023-05-08
13 Acee Lindem IESG state changed to Publication Requested from I-D Exists
2023-05-08
13 Acee Lindem Document is now in IESG state Publication Requested
2023-05-08
13 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-13.txt
2023-05-08
13 Tony Li New version accepted (logged-in submitter: Tony Li)
2023-05-08
13 Tony Li Uploaded new revision
2023-03-17
12 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Ravi Singh
2023-03-14
12 Acee Lindem IETF WG state changed to In WG Last Call from WG Document
2023-03-14
12 Acee Lindem Requested Last Call review by RTGDIR
2023-02-24
12 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-12.txt
2023-02-24
12 (System) New version approved
2023-02-24
12 (System)
Request for posting confirmation emailed to previous authors: David Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak …
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
2023-02-24
12 Tony Li Uploaded new revision
2022-12-09
11 (System) Document has expired
2022-07-07
11 Acee Lindem Intended Status changed to Experimental from Proposed Standard
2022-06-07
11 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-11.txt
2022-06-07
11 Jenny Bui Posted submission manually
2021-12-07
10 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-10.txt
2021-12-07
10 (System) New version approved
2021-12-07
10 (System)
Request for posting confirmation emailed to previous authors: David Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak …
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
2021-12-07
10 Tony Li Uploaded new revision
2021-06-09
09 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-09.txt
2021-06-09
09 (System) New version approved
2021-06-09
09 (System)
Request for posting confirmation emailed to previous authors: Dave Cooper , Gyan Mishra , Huaimo Chen , Les Ginsberg , Luay Jalil , Peter Psenak …
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
2021-06-09
09 Tony Li Uploaded new revision
2021-02-17
08 Christian Hopps Changed consensus to Yes from Unknown
2021-02-17
08 Christian Hopps Intended Status changed to Proposed Standard from None
2020-12-14
08 Tony Li New version available: draft-ietf-lsr-dynamic-flooding-08.txt
2020-12-14
08 (System) New version approved
2020-12-14
08 (System)
Request for posting confirmation emailed to previous authors: Tony Li , Dave Cooper , Srinath Dontula , lsr-chairs@ietf.org, Huaimo Chen , Luay Jalil , …
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
2020-12-14
08 Tony Li Uploaded new revision
2020-06-23
07 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-07.txt
2020-06-23
07 (System) New version approved
2020-06-23
07 (System)
Request for posting confirmation emailed to previous authors: Peter Psenak , Les Ginsberg , Tony Li , Dave Cooper , Srinath Dontula , Tony Przygienda …
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
2020-06-23
07 Les Ginsberg Uploaded new revision
2020-05-27
06 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-06.txt
2020-05-27
06 (System) New version approved
2020-05-27
06 (System)
Request for posting confirmation emailed to previous authors: Luay Jalil , lsr-chairs@ietf.org, Tony Przygienda , Huaimo Chen , Peter Psenak , Tony Li , …
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
2020-05-27
06 Les Ginsberg Uploaded new revision
2020-05-17
05 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-05.txt
2020-05-17
05 (System) New version approved
2020-05-17
05 (System)
Request for posting confirmation emailed to previous authors: Les Ginsberg , lsr-chairs@ietf.org, Tony Li , Luay Jalil , Peter Psenak , Huaimo Chen , …
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
2020-05-17
05 Les Ginsberg Uploaded new revision
2020-03-06
Jenny Bui Posted related IPR disclosure Arista Networks, Inc.'s Statement about IPR related to draft-ietf-lsr-dynamic-flooding and draft-chen-lsr-dynamic-flooding-algorithm
2020-03-06
Jenny Bui Posted related IPR disclosure Arista Networks, Inc.'s Statement about IPR related to draft-ietf-lsr-dynamic-flooding and draft-chen-lsr-dynamic-flooding-algorithm
2020-02-11
Jenny Bui Posted related IPR disclosure: Arista Networks, Inc.'s Statement about IPR related to draft-ietf-lsr-dynamic-flooding
2019-11-26
04 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-04.txt
2019-11-26
04 (System) New version approved
2019-11-26
04 (System)
Request for posting confirmation emailed to previous authors: Huaimo Chen , Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, 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
2019-11-26
04 Les Ginsberg Uploaded new revision
2019-09-03
03 Acee Lindem Notification list changed to Acee Lindem <acee@cisco.com>
2019-09-03
03 Acee Lindem Document shepherd changed to Acee Lindem
2019-08-16
Jenny Bui Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-lsr-dynamic-flooding
2019-08-14
Jenny Bui Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-lsr-dynamic-flooding
2019-06-04
03 Les Ginsberg
New version available: draft-ietf-lsr-dynamic-flooding-03.txtquot; is the 14-character [RFC20] string indicated, 0x0S is a
  single byte where S is the SType for which …
New version available: draft-ietf-lsr-dynamic-flooding-03.txtquot; is the 14-character [RFC20] string indicated, 0x0S is a
  single byte where S is the SType for which this key derivation is
  being used, and L is the length of output keying material needed.

4.4 SType None

  No security services are being invoked. The length of the Security
  Information field (see Figure 6) is zero.

4.5 RFC 5310 Based Authentication

  The Security Information (see Figure 6) is the flags and Size bytes
  specified in Section 4.1 with the value of the [RFC5310] Key ID and
  Authentication Data as shown in Figure 13.

                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1|0|    RESV  |    Size      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Key ID              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              |
        +
        | Authentication Data (Variable)
        +
        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-...

                  Figure 13. SType 1 Security Information

  o  RESV: Six bits that MUST be sent as zero and ignored or receipt.

  o  Size: Set to 2 + the size of Authentication Data in bytes.

  o  Key ID: specifies the same keying value and authentication
      algorithm that that Key ID specifies for TRILL IS-IS LSP [RFC5310]
      Authentication TLVs. The keying material actually used is derived
      as shown in Section 4.3.

  o  Authentication Data: The authentication data produced by the key
      and algorithm associated with the Key ID acting on the packet as
      specified in Section 4.2. Length of authentication data depends on
      the algorithm.

D. Eastlake & Y. Li                                            [Page 16]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

4.6 DTLS Based Security

  DTLS supports key negotiation and provides both encryption and
  authentication. This optional SType in Channel Tunnel uses DTLS 1.2
  [RFC6347]. It is intended for pairwise use. The presumption is that
  in the RBridge Channel case (Figure 1) the M bit in the TRILL Header
  would be zero and in the native RBridge Channel case (Figure 2), the
  Outer.MacDA would be individually addressed.

  TRILL switches that implement the Channel Tunnel DTLS SType SHOULD
  support the use of certificates for DTLS. In this case the Size field
  shown in Section 4.1 MUST be zero and the Security Information is as
  shown in Figure 14.

  Also, if they support certificates, they MUST support the following
  algorithm:

  o  TLS_RSA_WITH_AES_128_CBC_SHA256 [RFC5246]

                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |1|1|  RESV    |      0      |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 14. DTLS Cert or Special Pre-shared Key Security Information

  TRILL switches that support the Channel Tunnel DTLS SType MUST
  support the use of pre-shared keys for DTLS. The Size field as shown
  in Section 4.1 MUST be either zero or 2. If Size is zero as shown in
  Figure 14, a pre-shared key specifically associated with Channel
  Tunnel DTLS is used. If Size is 2 as shown in Figure 15, a two byte
  [RFC5310] Key ID is present and the pre-shared key is derived from
  the secret key associated with that Key ID as shown in Section 4.3.

  The following cryptographic algorithms MUST be supported for use with
  pre-shared keys:

  o  TLS_PSK_WITH_AES_128_CBC_SHA256 [RFC5487]

                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |1|1|  RESV    |      2      |
                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |          Key ID              |
                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 15. DTLS Derived Pre-shared Key Security Information

D. Eastlake & Y. Li                                            [Page 17]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

  When DTLS security is used, the entire payload of the Channel Tunnel
  packet, starting just after the Security Information and ending just
  before the link trailer, is a DTLS record [RFC6347].

4.7 RFC 5310 Based Encryption and Authentication

  This SType is based on pre-existing [RFC5310] keying material but
  does not use any algorithm that may be associated with a Key ID under
  [RFC5310].  Instead it uses the derived key as specified in Section
  4.3 with the algorithm specified by a Crypto Suite ID. Key
  negotiation is not provided and this SType is intended for multi-
  destination message use. The presumption is that in the RBridge
  Channel case (Figure 1) the M bit in the TRILL Header would be one
  and in the native RBridge Channel case (Figure 2), the Outer.MacDA
  would be group addressed.

                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |1|1|  RESV    |      4      |
                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |          Key ID              |
                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |    Crypto Suite ID          |
                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 16. DTLS Derived Pre-shared Key Security Information

  4.7.1 Channel-Tunnel-CCM

  The initially specified Crypto Suite has ID 0x0001, is called
  Channel-Tunnel-CCM (Channel Tunnel Counter with CBC-MAC), and is
  mandatory to implement if this SType is supported.

  Channel-Tunnel-CCM is based on [RFC3610] using AES-128 as the
  encryption function. The minimum authentication field size permitted
  is 8 octets.  There is additional authenticated data which is the
  authenticated data indicated in Section 4.2 up to but not including
  any of the Tunneled Data (Figure 4). The message size is limited to
  2**16 - 2**8 bytes so the length of the length of message field is
  always 2 bytes. There are thus 13 bytes available for nonce
  [RFC3610]. Since it is possible that the same Key ID could be used by
  different TRILL switches, the nonce MUST include an identifier for
  the originating TRILL switch. It is RECOMMENDED that this be the
  first 6 bytes of its IS-IS System ID as these will be unique across
  the campus.  The remaining 7 bytes (56 bits) need to be such that the
  nonce is always unique for a particular key, for example a counter
  for which care is taken that it is always incremented after each use
  and its value is preserved over TRILL switch crashes, re-starts, and

D. Eastlake & Y. Li                                            [Page 18]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

  the like. Should there be a danger of exhausting such a counter, the
  TRILL switch MUST take steps such as causing re-keying of the
  [RFC5310] key ID it is using and/or changing to use a different Key
  ID.

D. Eastlake & Y. Li                                            [Page 19]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

5. Channel Tunnel Errors

  RBridge Channel Tunnel Protocol errors are reported like RBridge
  Channel level errors. The ERR field is set to one of the following
  error codes:

        ERR  Meaning
        ---  ---------
          6    Unknown or unsupported field value
          7    Authentication failure
          8    Error in nested RBridge Channel message
        (more TBD?)

                        Table 4. Additional ERR Values

5.1 SubERRs under ERR 6

  If the ERR field is 6, the SubERR field indicates the problematic
  field or value as show in the table below.

        SubERR  Meaning (for ERR = 6)
        ------  ---------------------
            0    Non-zero RESV4 nibble
            1    Unsupported SType
            2    Unsupported PType
            4    Unsupported crypto algorithm
            5    Unknown Key ID
        (more TBD)

                      Table 5. SubERR values under ERR 6

5.2 Nested RBridge Channel Errors

  If
      a Channel Tunnel message is sent with security and with a payload
      type (PType) indicating a nested RBridge Channel message
  and
      there is an error in the processing of that nested message that
      results in a return RBridge Channel message with a non-zero ERR
      field,
  then that returned message SHOULD also be nested in an Channel Tunnel
  message using the same type of security. In this case, the ERR field
  in the Channel Tunnel envelope is set to 8 indicating that there is a
  nested error being tunneled back.

D. Eastlake & Y. Li                                            [Page 20]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

6. IANA Considerations

  IANA has assigned tbd1 as the RBridge Channel protocol number the
  "Channel Tunnel" protocol from the range assigned by Standards
  Action.

  The added RBridge Channel protocols registry entry on the TRILL
  Parameters web page is as follows:

        Protocol  Description    Reference
        --------  --------------  ---------

          tbd1    Tunnel Channel  [this document]

D. Eastlake & Y. Li                                            [Page 21]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

7. Security Considerations

  The RBridge Channel tunnel facility has potentially positive and
  negative effects on security.

  On the positive side, it provides optional security that can be used
  to authenticate and/or encrypt RBridge Channel messages. Some RBridge
  Channel message payloads, such as BFD [RFC7175], provide their own
  security but where this is not true, consideration should be give to
  requiring use of the security features of the Tunnel Protocol.

  On the negative side, the optional ability to tunnel various payload
  types and to tunnel them not just between TRILL switches but to and
  from end stations can increase risk unless precautions are taking.
  The processing of decapsulated Tunnel Protocol payloads is not a good
  place to be liberal in what you accept as the tunneling facility
  makes it easier for unexpected messages to pop up in unexpected
  places in a TRILL campus due to accidents or the actions of an
  adversary. Local policies should generally be strict and only process
  payload types required and then only with adequate authentication for
  the particular circumstances.

  In connection with the use of DTLS for security as specified in
  Section 4.5, see [RFC7457].

  See [RFC7178] for general RBridge Channel Security Considerations.

  See [RFC6325] for general TRILL Security Considerations.

D. Eastlake & Y. Li                                            [Page 22]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

Normative References

  [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology
        -- Telecommunications and information exchange between systems
        -- Intermediate System to Intermediate System intra-domain
        routeing information exchange protocol for use in conjunction
        with the protocol for providing the connectionless-mode network
        service (ISO 8473)", 2002.

  [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80,
        RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.

  [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with
        CBC-MAC (CCM)", RFC 3610, September 2003, <http://www.rfc-
        editor.org/info/rfc3610>.

  [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security
        (TLS) Protocol Version 1.2", RFC 5246, August 2008,
        <http://www.rfc-editor.org/info/rfc5246>.

  [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
        and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
        5310
, February 2009.

  [RFC5487] - Badra, M., "Pre-Shared Key Cipher Suites for TLS with
        SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009,
        <http://www.rfc-editor.org/info/rfc5487>.

  [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
        Expand Key Derivation Function (HKDF)", RFC 5869, May 2010,
        <http://www.rfc-editor.org/info/rfc5869>.

  [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
        Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
        July 2011.

  [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer
        Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-
        editor.org/info/rfc6347>.

  [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
        and D. Dutt, "Transparent Interconnection of Lots of Links
        (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.

  [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
        D., and A. Banerjee, "Transparent Interconnection of Lots of
        Links (TRILL) Use of IS-IS", RFC 7176, May 2014,

D. Eastlake & Y. Li                                            [Page 23]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

        <http://www.rfc-editor.org/info/rfc7176>.

  [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
        Ward, "Transparent Interconnection of Lots of Links (TRILL):
        RBridge Channel Support", RFC 7178, May 2014.

  [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
        Scope Link State PDUs (LSPs)", RFC 7356, September 2014,
        <http://www.rfc-editor.org/info/rfc7356>.

  [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A.,
        Ghanwani, A., and S. Gupta, "TRILL: Clarifications,
        Corrections, and Updates", Draft-ietf-trill-rfc7180bis, work in
        progress.

Informative References

  [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
        Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May
        2011.

  [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
        Interconnection of Lots of Links (TRILL) Protocol Control
        Protocol", RFC 6361, August 2011

  [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and
        IETF Protocol and Documentation Usage for IEEE 802 Parameters",
        BCP 141, RFC 7042, October 2013.

  [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
        "Transparent Interconnection of Lots of Links (TRILL):
        Bidirectional Forwarding Detection (BFD) Support", RFC 7175,
        May 2014.

  [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection
        Most of the Time", RFC 7435, December 2014, <http://www.rfc-
        editor.org/info/rfc7435>.

  [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
        Known Attacks on Transport Layer Security (TLS) and Datagram
        TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc-
        editor.org/info/rfc7457>.

D. Eastlake & Y. Li                                            [Page 24]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

Appendix Z: Change History

From -00 to -01

  1. Fix references for RFCs published, etc.

  2. Explicitly mention in the Abstract and Introduction that this
      document updates [RFC7178].

  3. Add this Change History Appendix.

From -01 to -02

  1. Remove section on the "Scope" feature as mentioned in
      http://www.ietf.org/mail-archive/web/trill/current/msg06531.html

  2. Editorial changes to IANA Considerations to correspond to draft-
      leiba-cotton-iana-5226bis-11.txt.

  3. Improvements to the Ethernet frame payload type.

  4. Other Editorial changes.

From -02 to -03

  1. Update TRILL Header to correspond to [rfc7180bis].

  2. Remove a few remnants of the "Scope" feature that was removed from
      -01 to -02.

  3. Substantial changes to and expansion of Section 4 including adding
      details of DTLS security.

  4. Updates and additions to the References.

  5. Other minor editorial changes.

From -03 to -04

  1. Add SType for [RFC5310] keying based security that provides
      encryption as well as authentication.

  2. Editorial improvements and fixes.

D. Eastlake & Y. Li                                            [Page 25]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

Acknowledgements

  The contributions of the following are hereby acknowledged:

        TBD

  The document was prepared in raw nroff. All macros used were defined
  within the source file.

D. Eastlake & Y. Li                                            [Page 26]
INTERNET-DRAFT                            TRILL: RBridge Channel Tunnel

Authors' Addresses

      Donald E. Eastlake, 3rd
      Huawei Technologies
      155 Beaver Street
      Milford, MA 01757 USA

      Phone: +1-508-333-2270
      EMail: d3e3e3@gmail.com

      Mohammed Umair
      IPinfusion

      EMail: mohammed.umair2@gmail.com

      Yizhou Li
      Huawei Technologies
      101 Software Avenue,
      Nanjing 210012, China

      Phone: +86-25-56622310
      EMail: liyizhou@huawei.com

D. Eastlake & Y. Li                                            [Page 27]
2019-06-04
03 (System) New version approved
2019-06-04
03 (System)
Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , …
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
2019-06-04
03 Les Ginsberg Uploaded new revision
2019-05-27
02 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-02.txt
2019-05-27
02 (System) New version approved
2019-05-27
02 (System)
Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , …
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
2019-05-27
02 Les Ginsberg Uploaded new revision
2019-05-21
01 Les Ginsberg New version available: draft-ietf-lsr-dynamic-flooding-01.txt
2019-05-21
01 (System) New version approved
2019-05-21
01 (System)
Request for posting confirmation emailed to previous authors: Srinath Dontula , Tony Li , Luay Jalil , lsr-chairs@ietf.org, Dave Cooper , Peter Psenak , …
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
2019-05-21
01 Les Ginsberg Uploaded new revision
2019-02-25
00 Christian Hopps This document now replaces draft-li-lsr-dynamic-flooding instead of None
2019-02-25
00 Peter Psenak New version available: draft-ietf-lsr-dynamic-flooding-00.txt
2019-02-25
00 (System) WG -00 approved
2019-02-25
00 Peter Psenak Set submitter to "Peter Psenak ", replaces to (none) and sent approval email to group chairs: lsr-chairs@ietf.org
2019-02-25
00 Peter Psenak Uploaded new revision