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 |