Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-p2mp-bfd-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-12
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-28
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-02-25
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-02-14
|
09 | (System) | RFC Editor state changed to REF from EDIT |
2018-12-26
|
09 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-02-08
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-02-08
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-02-08
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-02-08
|
09 | (System) | RFC Editor state changed to MISSREF |
2018-02-08
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-02-08
|
09 | (System) | Announcement was received by RFC Editor |
2018-02-08
|
09 | (System) | IANA Action state changed to In Progress |
2018-02-08
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-02-08
|
09 | Cindy Morgan | IESG has approved the document |
2018-02-08
|
09 | Cindy Morgan | Closed "Approve" ballot |
2018-02-08
|
09 | Cindy Morgan | Ballot approval text was generated |
2018-02-08
|
09 | Alia Atlas | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-02-06
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-06
|
09 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-09.txt |
2018-02-06
|
09 | (System) | New version approved |
2018-02-06
|
09 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mingui Zhang |
2018-02-06
|
09 | Mingui Zhang | Uploaded new revision |
2018-02-06
|
09 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mingui Zhang |
2018-02-06
|
09 | Mingui Zhang | Uploaded new revision |
2018-01-25
|
08 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed |
2018-01-25
|
08 | Jean Mahoney | Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2018-01-25
|
08 | Cindy Morgan | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari by Cindy Morgan |
2018-01-25
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2018-01-24
|
08 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-01-24
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-01-24
|
08 | Alia Atlas | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-01-24
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-01-24
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-01-23
|
08 | Ben Campbell | [Ballot comment] There are a number of lower case "should" instances. Please consider using the boilerplate from 8174. (I am starting to sound like a … [Ballot comment] There are a number of lower case "should" instances. Please consider using the boilerplate from 8174. (I am starting to sound like a broken record this week :-) ) |
2018-01-23
|
08 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-01-23
|
08 | Kathleen Moriarty | [Ballot comment] Thanks for the update per the SecDir review. https://mailarchive.ietf.org/arch/msg/secdir/KAZevWuVQAiukpRBKgjm7YIATRg |
2018-01-23
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-01-23
|
08 | Alvaro Retana | [Ballot comment] (1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5; please add one in the Introduction when Multipoint BFD is initially mentioned. (2) … [Ballot comment] (1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5; please add one in the Introduction when Multipoint BFD is initially mentioned. (2) I think that using Normative Language (without quotation marks) to mention what is specified somewhere else can result in confusion as to which is the authoritative document. This seems to be the case in Section 4: "If the M bit of the TRILL Header of the RBridge channel packet containing a BFD Control packet is non-zero, the packet MUST be dropped [RFC7175]." The sentence sounds as if the behavior is specified in rfc7175, but that document says (in Section 3.2 (BFD Control Frame Processing)): "The following tests SHOULD be performed...Is the M bit in the TRILL Header non-zero? If so, discard the frame." Note that the behavior specified in rfc7175 doesn't use a "MUST". The text in this document seems to be used to explain why a new message is needed, and not in a Normative way -- please clarify the text so that there is no inconsistency with respect to rfc7175. (3) Section 5 says that the "processing in Section 3.2 of [RFC7175] applies...If the M bit is zero, the packet is discarded." Section 3.2 has that "SHOULD" that I mentioned above, and it also mentions potential security issues, which are not referenced in this document. Are there reasons to keep the "SHOULD" and not use "MUST" instead (for the p2mp case)? If the same semantics as in rfc7175 are kept, then the Security Considerations should include the concerns. |
2018-01-23
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-01-22
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-01-22
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-01-19
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-01-18
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-01-18
|
08 | Eric Rescorla | [Ballot comment] I'm hoping this can be resolved quickly, as it's probably just a missing cite. If it turns out that there's actually missing content, … [Ballot comment] I'm hoping this can be resolved quickly, as it's probably just a missing cite. If it turns out that there's actually missing content, this may turn into a DISCUSS. Multipoint BFD provides its own authentication but does not provide encryption (see Security Considerations in [I-D.ietf-bfd- multipoint]). As specified in this document, the point-to-multipoint I skimmed the reference here, but wasn't able to figure out what the authentication was. In particular, the document says: If the A bit is set, the packet MUST be authenticated under the rules of section 6.7, based on the authentication type in use (bfd.AuthType.) This may cause the packet to be discarded. But there is no 6.7. So, this makes me worry that I don't understand any of this. |
2018-01-18
|
08 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-01-18
|
08 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-01-18
|
08 | Alia Atlas | Ballot has been issued |
2018-01-18
|
08 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2018-01-18
|
08 | Alia Atlas | Created "Approve" ballot |
2018-01-18
|
08 | Alia Atlas | Ballot writeup was changed |
2018-01-11
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2018-01-11
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2018-01-11
|
08 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2018-01-10
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Shwetha Bhandari. |
2018-01-09
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-01-09
|
08 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-08.txt |
2018-01-09
|
08 | (System) | New version approved |
2018-01-09
|
08 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mingui Zhang |
2018-01-09
|
08 | Mingui Zhang | Uploaded new revision |
2018-01-08
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-01-02
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-01-02
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-trill-p2mp-bfd-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-trill-p2mp-bfd-06. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the RBridge Channel Protocols registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at: https://www.iana.org/assignments/trill-parameters/ a single new protocol will be registered in the Standards Action section of the registry (values 0x002-0x0FF) as follows: Protocol: [ TBD-at-Registration ] Description: P2MP BFD Control Reference: [ RFC-to-be ] The IANA Services Operator understands that this is the only action 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 only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2017-12-28
|
07 | Stephen Farrell | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list. |
2017-12-28
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2017-12-28
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2017-12-26
|
07 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-07.txt |
2017-12-26
|
07 | (System) | New version approved |
2017-12-26
|
07 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mingui Zhang |
2017-12-26
|
07 | Mingui Zhang | Uploaded new revision |
2017-12-20
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-12-20
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-12-19
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2017-12-19
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2017-12-18
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-12-18
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-01-08): From: The IESG To: IETF-Announce CC: Susan Hares , akatlas@gmail.com, trill-chairs@ietf.org, trill@ietf.org, … The following Last Call announcement was sent out (ends 2018-01-08): From: The IESG To: IETF-Announce CC: Susan Hares , akatlas@gmail.com, trill-chairs@ietf.org, trill@ietf.org, draft-ietf-trill-p2mp-bfd@ietf.org, shares@ndzh.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL Support of Point to Multipoint BFD) to Proposed Standard The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Support of Point to Multipoint BFD' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-01-08. 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 Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel message. This document updates RFC 7175 and RFC 7177. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-p2mp-bfd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-p2mp-bfd/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-bfd-multipoint-active-tail: BFD Multipoint Active Tails. (None - IETF stream) |
2017-12-18
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-12-18
|
06 | Alia Atlas | Placed on agenda for telechat - 2018-01-25 |
2017-12-18
|
06 | Alia Atlas | Last call was requested |
2017-12-18
|
06 | Alia Atlas | Ballot approval text was generated |
2017-12-18
|
06 | Alia Atlas | Ballot writeup was generated |
2017-12-18
|
06 | Alia Atlas | IESG state changed to Last Call Requested from Publication Requested |
2017-12-18
|
06 | Alia Atlas | Last call announcement was changed |
2017-11-16
|
06 | Susan Hares | PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL … PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL support of BFD. (2) Document Announcement: Technical Summary: Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel message. Working Group Summary: WG has discussed this technology along with other TRILL extensions for the last 3 years. Trade-offs were discussed at IETF meetings and on the mail list. Final decision on trade-off received good WG consnesus. Document Quality: No implementations of the protocol exist. Huawei may implement this draft in the future, but this depends on customer needs in various deployments (data centers, campus networks, and others) Personnel: Document Shepherd: Sue Hares Responsible Area Director: Alia Atlas (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. RTG-DIR review RTG-DIR REview - few nits need to be addressed. See also review comments by Donald Eastlake at https://www.ietf.org/mail-archive/web/trill/current/msg07751.html that were resolved in version -05 https://www.ietf.org/mail-archive/web/trill/current/msg07753.html and RTG review by Carlos Pignataro at https://www.ietf.org/mail-archive/web/trill/current/msg07729.html resolved here https://www.ietf.org/mail-archive/web/trill/current/msg07731.html (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The draft has recevied good review in the meetings, in discussion with authors, and on the list. The chair sends out specific questions with each TRILL WG last call. TRILL participant commenton these questions. The security considerations section indicates that a "future document will provide for group keying". This document is draft-ietf-trill-group-keying-00.txt. Since the TRILL progressing toward a hiatus and this future document may not pass WG LC, this statement has been left as is. An RFC editor note can link these two documents together if they are both approved, or the authors indicated they would be glad to modify the document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Normal reviews, plus review by the BFD group is useful. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No special concerns. This document has gone through several reviews. It is part of the extension to the TRILL extensions for directory service and local link functions. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, three authors: Prasad Govindan: https://www.ietf.org/mail-archive/web/trill/current/msg07818.html Mingui Zhang: https://www.ietf.org/mail-archive/web/trill/current/msg07816.html Santosh Pallagatti: https://www.ietf.org/mail-archive/web/trill/current/msg07846.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is clear WG consensus for this draft. This document has cycled in the working group as the authors and chair refined the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are references to two BFD WG drafts and one TRILL draft as listed below. These are expected to be advanced soon. draft-ietf-bfd-multipoint draft-ietf-bfd-multipoint-active-tail draft-ietf-trill-resilient-trees (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC 7177 as specified in Section 3 and updates RFC 7175 as specified in Section 4. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document only requires the allocation of a single code point, a new RBridge Channel Protocol number, which is properly provided for in the IANA Considerations Section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such automatic checks required. |
2017-11-16
|
06 | Susan Hares | PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL … PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL support of BFD. (2) Document Announcement: Technical Summary: Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel message. Working Group Summary: WG has discussed this technology along with other TRILL extensions for the last 3 years. Trade-offs were discussed at IETF meetings and on the mail list. Final decision on trade-off received good WG consnesus. Document Quality: No implementations of the protocol exist. Huawei may implement this draft in the future, but this depends on customer needs in various deployments (data centers, campus networks, and others) Personnel: Document Shepherd: Sue Hares Responsible Area Director: Alia Atlas (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. RTG-DIR review RTG-DIR REview - few nits need to be addressed. See also review comments by Donald Eastlake at https://www.ietf.org/mail-archive/web/trill/current/msg07751.html that were resolved in version -05 https://www.ietf.org/mail-archive/web/trill/current/msg07753.html and RTG review by Carlos Pignataro at https://www.ietf.org/mail-archive/web/trill/current/msg07729.html resolved here https://www.ietf.org/mail-archive/web/trill/current/msg07731.html (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The draft has recevied good review in the meetings, in discussion with authors, and on the list. The chair sends out specific questions with each TRILL WG last call. TRILL participant commenton these questions. The security considerations section indicates that a "future document will provide for group keying". This document is draft-ietf-trill-group-keying-00.txt. Since the TRILL progressing toward a hiatus and this future document may not pass WG LC, this statement has been left as is. An RFC editor note can link these two documents together if they are both approved, or the authors indicated they would be glad to modify the document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review required. A normal OPS-DIR, SEC-DIR, RTG-DIR, and GEN-ART review of this document will be sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No special concerns. This document has gone through everal passes. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, three authors: Prasad Govindan: https://www.ietf.org/mail-archive/web/trill/current/msg07818.html Mingui Zhang: https://www.ietf.org/mail-archive/web/trill/current/msg07816.html Santosh Pallagatti: https://www.ietf.org/mail-archive/web/trill/current/msg07846.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is clear WG consensus for this draft. This document has cycled in the working group as the authors and chair refined the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are references to two BFD WG drafts and one TRILL draft as listed below. These are expected to be advanced soon. draft-ietf-bfd-multipoint draft-ietf-bfd-multipoint-active-tail draft-ietf-trill-resilient-trees (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC 7177 as specified in Section 3 and updates RFC 7175 as specified in Section 4. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document only requires the allocation of a single code point, a new RBridge Channel Protocol number, which is properly provided for in the IANA Considerations Section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such automatic checks required. |
2017-11-16
|
06 | Susan Hares | PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL … PROTO for draft-ietf-trill-p2mp-bfd-05 (1) Type of RFC: Standards track as indicated on the title page. This document extends and updates Draft Standard 7175 on TRILL support of BFD. (2) Document Announcement: Technical Summary: Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel message. Working Group Summary: WG has discussed this technology along with other TRILL extensions for the last 3 years. Trade-offs were discussed at IETF meetings and on the mail list. Final decision on trade-off received good WG consnesus. Document Quality: No implementations of the protocol exist. Huawei may implement this draft in the future, but this depends on customer needs in various deployments (data centers, campus networks, and others) Personnel: Document Shepherd: Sue Hares Responsible Area Director: Alia Atlas (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. RTG-DIR review RTG-DIR REview - few nits need to be addressed. See also review comments by Donald Eastlake at https://www.ietf.org/mail-archive/web/trill/current/msg07751.html that were resolved in version -05 https://www.ietf.org/mail-archive/web/trill/current/msg07753.html and RTG review by Carlos Pignataro at https://www.ietf.org/mail-archive/web/trill/current/msg07729.html resolved here https://www.ietf.org/mail-archive/web/trill/current/msg07731.html (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The draft has recevied good review in the meetings, in discussion with authors, and on the list. The chair sends out specific questions with each TRILL WG last call. TRILL participant commenton these questions. The security considerations section indicates that a "future document will provide for group keying". This document is draft-ietf-trill-group-keying-00.txt. Since the TRILL progressing toward a hiatus and this future document may not pass WG LC, this statement has been left as is. An RFC editor note can link these two documents together if they are both approved, or the authors indicated they would be glad to modify the document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No special review required. A normal OPS-DIR, SEC-DIR, RTG-DIR, and GEN-ART review of this document will be sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No special concerns. This document has gone through everal passes. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, three authors: Prasad Govindan: https://www.ietf.org/mail-archive/web/trill/current/msg07818.html Mingui Zhang: https://www.ietf.org/mail-archive/web/trill/current/msg07816.html Santosh Pallagatti: https://www.ietf.org/mail-archive/web/trill/current/msg07846.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is clear WG consensus for this draft. This document has cycled in the working group as the authors and chair sought perfection. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are references to two BFD WG drafts and one TRILL draft as listed below. These are expected to be advanced soon. draft-ietf-bfd-multipoint draft-ietf-bfd-multipoint-active-tail draft-ietf-trill-resilient-trees (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC 7177 as specified in Section 3 and updates RFC 7175 as specified in Section 4. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document only requires the allocation of a single code point, a new RBridge Channel Protocol number, which is properly provided for in the IANA Considerations Section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such automatic checks required. |
2017-11-16
|
06 | Susan Hares | Responsible AD changed to Alia Atlas |
2017-11-16
|
06 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-11-16
|
06 | Susan Hares | IESG state changed to Publication Requested |
2017-11-16
|
06 | Susan Hares | IESG process started in state Publication Requested |
2017-11-16
|
06 | Susan Hares | Changed document writeup |
2017-11-13
|
06 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-06.txt |
2017-11-13
|
06 | (System) | New version approved |
2017-11-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , Mingui Zhang |
2017-11-13
|
06 | Mingui Zhang | Uploaded new revision |
2017-11-13
|
05 | (System) | Document has expired |
2017-11-11
|
05 | Susan Hares | Changed document writeup |
2017-11-11
|
05 | Susan Hares | Changed document writeup |
2017-11-11
|
05 | Donald Eastlake | Changed document writeup |
2017-05-07
|
05 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-05.txt |
2017-05-07
|
05 | (System) | New version approved |
2017-05-07
|
05 | (System) | Request for posting confirmation emailed to previous authors: Vengada Govindan , Juniper Networks , trill-chairs@ietf.org, Mingui Zhang |
2017-05-07
|
05 | Mingui Zhang | Uploaded new revision |
2017-05-02
|
04 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-03-23
|
04 | Carlos Pignataro | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2017-03-17
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2017-03-17
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2017-03-10
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Thomas Morin |
2017-03-10
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Thomas Morin |
2017-03-07
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Danny McPherson |
2017-03-07
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Danny McPherson |
2017-03-06
|
04 | Susan Hares | Requested Early review by RTGDIR |
2017-02-07
|
04 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2017-02-06
|
04 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-04.txt |
2017-02-06
|
04 | (System) | New version approved |
2017-02-06
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Juniper Networks" , trill-chairs@ietf.org, "Vengada Govindan" , "Mingui Zhang" |
2017-02-06
|
04 | Mingui Zhang | Uploaded new revision |
2017-01-14
|
03 | Susan Hares | Notification list changed to "Susan Hares" <shares@ndzh.com> |
2017-01-14
|
03 | Susan Hares | Document shepherd changed to Susan Hares |
2017-01-04
|
03 | Donald Eastlake | Changed consensus to Yes from Unknown |
2017-01-04
|
03 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2016-11-22
|
03 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-03.txt |
2016-11-22
|
03 | (System) | New version approved |
2016-11-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Juniper Networks" , trill-chairs@ietf.org, "Vengada Govindan" , "Mingui Zhang" |
2016-11-22
|
03 | Mingui Zhang | Uploaded new revision |
2016-05-23
|
02 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-02.txt |
2015-12-02
|
01 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-01.txt |
2015-10-14
|
00 | (System) | Notify list changed from "Donald E. Eastlake 3rd" to (None) |
2015-06-18
|
00 | Donald Eastlake | Notification list changed to "Donald E. Eastlake 3rd" <d3e3e3@gmail.com> |
2015-06-18
|
00 | Donald Eastlake | Document shepherd changed to Donald E. Eastlake 3rd |
2015-06-09
|
00 | Donald Eastlake | This document now replaces draft-zhang-trill-p2mp-bfd instead of None |
2015-06-09
|
00 | Mingui Zhang | New version available: draft-ietf-trill-p2mp-bfd-00.txt |