Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
draft-ietf-trill-rbridge-bfd-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-07
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-04-14
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-07
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-03-17
|
07 | (System) | RFC Editor state changed to REF from EDIT |
2014-02-03
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2012-10-03
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-10-02
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-10-02
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-10-01
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-10-01
|
07 | (System) | IANA Action state changed to In Progress from On Hold |
2012-10-01
|
07 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-09-29
|
07 | (System) | IANA Action state changed to On Hold from In Progress |
2012-09-29
|
07 | (System) | IANA Action state changed to In Progress |
2012-09-29
|
07 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2012-09-29
|
07 | Cindy Morgan | IESG has approved the document |
2012-09-29
|
07 | Cindy Morgan | Closed "Approve" ballot |
2012-09-29
|
07 | Cindy Morgan | Ballot approval text was generated |
2012-09-29
|
07 | Cindy Morgan | Ballot writeup was changed |
2012-08-14
|
07 | Stewart Bryant | [Ballot comment] Thank you for addressing my concerns with this document. |
2012-08-14
|
07 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-07-18
|
07 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-07-17
|
07 | Martin Stiemerling | [Ballot comment] Thank you for addressing my discuss. |
2012-07-17
|
07 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2012-07-17
|
07 | Adrian Farrel | [Ballot comment] Thanks for working on the Discuss points and my Comments. The new revision has resolved most of them and I am downgrading the … [Ballot comment] Thanks for working on the Discuss points and my Comments. The new revision has resolved most of them and I am downgrading the remaing two Discuss points to be Comments. I still hope they will be looked at, but I do not think they merit blocking the document. --- In looking for a a reference to be added to draft-ietf-trill-rbridge-oam (and/or to draft-ietf-trill-oam-req or draft-salam-trill-oam-framework) I am seeking joined-up thinking about OAM within Trill such that the reader can see that BFD is just part of the overall OAM solution and can understand when other tools might be more appropriate. Although the document is self-contained wrt motivation for BFD, it does not present the necessary hooks for seeing the whole OAM picture. In general, one would expect the OAM requirements and framework to be developed first, and solutions to follow. But I understand that carts often get ahead of horses. Thus normative references might not be an absolute requirement. But some form of reference is really desirable. --- > Finally, although I understand that the scope of this document is > limited to encapsulation, I think that this leaves the solution > deficient. It needs a description of bootstrapping in the Trill > environment. The authors proposed adding text to section 2.1 to say: For many applications, a means of triggering or bootstrapping the BFD session is required. This will be specified with the particular use of BFD over TRILL. For example, see draft-hpothetical-trill-rfc6327bis. This would be good. |
2012-07-17
|
07 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2012-07-16
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-16
|
07 | Donald Eastlake | New version available: draft-ietf-trill-rbridge-bfd-07.txt |
2012-06-09
|
06 | Adrian Farrel | [Ballot discuss] I've updated my Discuss to take into account some email exchanges with the authors. The net effect is to move points 1 and … [Ballot discuss] I've updated my Discuss to take into account some email exchanges with the authors. The net effect is to move points 1 and 2 of the Discuss to a Comment with a suggested action. === John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back." The use of "RECOMMENDED" contradicts "left to the discretion of" because "RECOMMENDED" is a very strong encouragement to do something. I think you need "suggested" as this is just general advice to an implementation. 4. In two places text like the following appears: "Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document." If multi-destination doesn't make sense in the context of TRILL, it is fine to exclude it by enforcing that the M-bit be zero. However, "beyond the scope of this document" normally means something like "we may do it in the future but haven't worked it out yet". By forcing the discard under these conditions you are doing more than putting the function out of scope: you are disabling it. You might solve this by mandating the setting of the bit to zero, and saying that if the bit is non-zero the behavior is future description, and that an implementation MAY discard the packet. 5. The Security Considerations section specifies how authentication is to be done, but doesn't provide an analysis of it or of any broader issues. According to RFC 3552 (Section 5) the Security Considerations section should include an analysis of issues that arise from the operation of the protocol defined in the rest of the document, including but not limited to the security features of that protocol. You could place the current text in a subsection of the Security Considerations (called "Authentication") and add more text to the core section. Additionally, I think you are missing a normative reference to https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/ This is necessary to set the context for why you are using BFD and for what purpose. It would also clarify which BFD features are needed and what OAM features (from the whole set) are addressed by BFD. Finally, although I understand that the scope of this document is limited to encapsulation, I think that this leaves the solution deficient. It needs a description of bootstrapping in the Trill environment. |
2012-06-09
|
06 | Adrian Farrel | [Ballot comment] It is very odd to bring this document forward ahead of the normatively referenced draft-ietf-trill-rbridge-channel Doing this makes the review less certain. … [Ballot comment] It is very odd to bring this document forward ahead of the normatively referenced draft-ietf-trill-rbridge-channel Doing this makes the review less certain. --- It is not clear why demand mode was explicitly excluded. TRILL would actually seem to be a reasonable fit for demand mode. Please either include demand mode, or a short note on why it is excluded. It is clear from email exchanges that the authors consider that demand mode is redundant because asynchronous will always need to be supported and because the underlying connectivity will often encompass multiple hops in the lower layer. It would be helpful if this was stated as a reason. --- "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL." This text is a little hard to parse and may be ambiguous. Please find a way to re-write it with reference to a pair of RBridges RB1 and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like that. |
2012-06-09
|
06 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-06-07
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-06-06
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-06-06
|
06 | Adrian Farrel | [Ballot discuss] John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 1. It is … [Ballot discuss] John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 1. It is not clear why demand mode was explicitly excluded. TRILL would actually seem to be a reasonable fit for demand mode. Please either include demand mode, or a short note on why it is excluded. 2. "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL." This text is a little hard to parse and may be ambiguous. Please find a way to re-write it with reference to a pair of RBridges RB1 and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like that. 3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back." The use of "RECOMMENDED" contradicts "left to the discretion of" because "RECOMMENDED" is a very strong encouragement to do something. I think you need "suggested" as this is just general advice to an implementation. 4. In two places text like the following appears: "Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document." If multi-destination doesn't make sense in the context of TRILL, it is fine to exclude it by enforcing that the M-bit be zero. However, "beyond the scope of this document" normally means something like "we may do it in the future but haven't worked it out yet". By forcing the discard under these conditions you are doing more than putting the function out of scope: you are disabling it. You might solve this by mandating the setting of the bit to zero, and saying that if the bit is non-zero the behavior is future description, and that an implementation MAY discard the packet. 5. The Security Considerations section specifies how authentication is to be done, but doesn't provide an analysis of it or of any broader issues. According to RFC 3552 (Section 5) the Security Considerations section should include an analysis of issues that arise from the operation of the protocol defined in the rest of the document, including but not limited to the security features of that protocol. You could place the current text in a subsection of the Security Considerations (called "Authentication") and add more text to the core section. Additionally, I think you are missing a normative reference to https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/ This is necessary to set the context for why you are using BFD and for what purpose. It would also clarify which BFD features are needed and what OAM features (from the whole set) are addressed by BFD. Finally, although I understand that the scope of this document is limited to encapsulation, I think that this leaves the solution deficient. It needs a description of bootstrapping in the Trill environment. |
2012-06-06
|
06 | Adrian Farrel | Ballot discuss text updated for Adrian Farrel |
2012-06-06
|
06 | Adrian Farrel | [Ballot discuss] John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 1. It is … [Ballot discuss] John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 1. It is not clear why demand mode was explicitly excluded. TRILL would actually seem to be a reasonable fit for demand mode. Please either include demand mode, or a short note on why it is excluded. 2. "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL." This text is a little hard to parse and may be ambiguous. Please find a way to re-write it with reference to a pair of RBridges RB1 and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like that. 3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back." The use of "RECOMMENDED" contradicts "left to the discretion of" because "RECOMMENDED" is a very strong encouragement to do something. I think you need "suggested" as this is just general advice to an implementation. 4. In two places text like the following appears: "Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document." If multi-destination doesn't make sense in the context of TRILL, it is fine to exclude it by enforcing that the M-bit be zero. However, "beyond the scope of this document" normally means something like "we may do it in the future but haven't worked it out yet". By forcing the discard under these conditions you are doing more than putting the function out of scope: you are disabling it. You might solve this by mandating the setting of the bit to zero, and saying that if the bit is non-zero the behavior is future description, and that an implementation MAY discard the packet. 5. The Security Considerations section specifies how authentication is to be done, but doesn't provide an analysis of it or of any broader issues. According to RFC 3552 (Section 5) the Security Considerations section should include an analysis of issues that arise from the operation of the protocol defined in the rest of the document, including but not limited to the security features of that protocol. You could place the current text in a subsection of the Security Considerations (called "Authentication") and add more text to the core section. Additionally, I think you are missing a normative reference to https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/ This is necessary to set the context for why you are using BFD and for what purpose. It would also clarify which BFD features are needed and what OAM features (from the whole set) are addressed by BFD. |
2012-06-06
|
06 | Adrian Farrel | [Ballot comment] It is very odd to bring this document forward ahead of the normatively referenced draft-ietf-trill-rbridge-channel Doing this makes the review less certain. |
2012-06-06
|
06 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2012-06-06
|
06 | Ralph Droms | Ballot writeup was changed |
2012-06-06
|
06 | Robert Sparks | [Ballot comment] I agree with the shepherd's recommendation to change the reference for [ASCII] to ANSI X3.4. I suggest looking at the references in RFC5891 … [Ballot comment] I agree with the shepherd's recommendation to change the reference for [ASCII] to ANSI X3.4. I suggest looking at the references in RFC5891 for an example: [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. |
2012-06-06
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-06-06
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-06
|
06 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-06-06
|
06 | Stewart Bryant | [Ballot discuss] This is I believe comparing the TRILL case with MPLS-TP "TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to the way that … [Ballot discuss] This is I believe comparing the TRILL case with MPLS-TP "TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to the way that MPLS OAM protocols use the MPLS Generic Associated Channel [RFC5586]. However, the RBridges that implement TRILL are IS-IS [IS-IS] based routers, not label switched routers; thus TRILL BFD is closer to IPv4/IPv6 BFD than to MPLS BFD." It is unclear what the above statement means. Whilst TRILL uses ISIS and MPLS-TP does not, the fundamentals high speed detection is is common to all. Where TRILL and MPLS-TP are closer than that are to the IP case is that neither have the use of IP addresses available to them. |
2012-06-06
|
06 | Stewart Bryant | [Ballot comment] I am surprised that TRILL did not take the opportunity to profile out the echo mode, since I understand that it is rarely … [Ballot comment] I am surprised that TRILL did not take the opportunity to profile out the echo mode, since I understand that it is rarely used in IP networks and not used in MPLS_TP networks. |
2012-06-06
|
06 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2012-06-06
|
06 | Sean Turner | [Ballot discuss] s6 contains the following: If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between … [Ballot discuss] s6 contains the following: If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges use BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below I think you need to say what the MTI is in this case. That might be as simple as adding "MUST" before "use" but that's a little more than MTI that's mandatory to use. Are you trying to say that in this case, BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below MUST be supported as a configurable option: ey [material derivation here]? |
2012-06-06
|
06 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-06-06
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-06-06
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-06-05
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-06-05
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-06-05
|
06 | Stephen Farrell | [Ballot comment] - I'm not clear if the key derivations described in section 6 are mandatory to implement or not. It says that if IS-IS … [Ballot comment] - I'm not clear if the key derivations described in section 6 are mandatory to implement or not. It says that if IS-IS auth is in effect, then you "use" (would that be better with a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-), but its not clear to me if that means this is MTI or not. - What does "that state of IS-IS shared secret" mean? Maybe s/that state//? - I don't get why this only needs/uses key ID 0, can you explain further? I guess I'd have expected that if the IS-IS-shared-key had a key ID, then that would be used for the derived key(s) defined here. - I'm wondering if the authentication scheme described here is really used or not? I think it'd be good to say if its real or fictional, if that is known. |
2012-06-05
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-05
|
06 | Barry Leiba | [Ballot comment] Minor comments; no need to respond: I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth. (I also … [Ballot comment] Minor comments; no need to respond: I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth. (I also can't remember when I last saw an actual normative reference to ASCII.) |
2012-06-05
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-06-04
|
06 | Alexey Melnikov | Request for Last Call review by GENART Completed. Reviewer: Alexey Melnikov. |
2012-06-04
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-06-04
|
06 | Pearl Liang | IANA has reviewed draft-ietf-trill-rbridge-bfd and has the following comments: The IANA actions in this document are dependent on the approval of another Internet Draft. This … IANA has reviewed draft-ietf-trill-rbridge-bfd and has the following comments: The IANA actions in this document are dependent on the approval of another Internet Draft. This dependency involves the following document: draft-ietf-trill-rbridge-channel If both this document and the dependency were approved, IANA understands that there is a single IANA action required by this document. In the new Rbridge Channel Protocol number registry, created by draft-ietf-trill-rbridge-channel, two new numbers would be registered as follows: Protocol Number -------- ------ BFD Control TBD BFD Echo TBD IANA notes that the authors have suggested 2 and 3 for the protocol numbers above. IANA 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 what actions will be performed. |
2012-06-04
|
06 | Martin Stiemerling | [Ballot discuss] I wonder if what is said about congestion control in Section 7 of RFC 5880 is also applicable to this draft. The current … [Ballot discuss] I wonder if what is said about congestion control in Section 7 of RFC 5880 is also applicable to this draft. The current draft text denies this, as it states in Section 5: > It is up to the operator of an RBridge campus to configure the rates > at which TRILL BFD frames are transmitted on a link to avoid > congestion (e.g., link, I/O, CPU) and false failure detection. This seems to be absolutely contradicting RFC 5880 on the matter of congestion control. |
2012-06-04
|
06 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2012-06-04
|
06 | Brian Haberman | [Ballot comment] Thank you for addressing my DISCUSS so quickly. |
2012-06-04
|
06 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2012-06-01
|
06 | Donald Eastlake | New version available: draft-ietf-trill-rbridge-bfd-06.txt |
2012-05-30
|
05 | Brian Haberman | [Ballot discuss] It is unclear what table the IANA Considerations section is referencing when it asks for two values of out the "Rbridge Channel Protocol" … [Ballot discuss] It is unclear what table the IANA Considerations section is referencing when it asks for two values of out the "Rbridge Channel Protocol" range. The IANA website does not have any such entry under TRILL that fits that description. Please reference the exact table name IANA should use to allocate these values. |
2012-05-30
|
05 | Brian Haberman | [Ballot comment] 1. I don't see the benefit to the discussion of MPLS OAM to this use of BFD. If this use of BFD is … [Ballot comment] 1. I don't see the benefit to the discussion of MPLS OAM to this use of BFD. If this use of BFD is more closely related to IPv4/IPv6 BFD, why mention MPLS OAM? 2. Section 3 contains an exact copy of the frame format from RFC 5880, but leaves the discussion of the frame fields to 5880. I would suggest simply referencing 5880 for both the frame format and the descriptions of the fields. 3. The TRILL Header hop count is specified as having a maximum value of 63 in section 2. After that, all references to the hop count refer to values in hex notation. I would suggest picking one format and be consistent throughout the document. 4. Section 4 states "... ECHO frames SHOULD only be sent on links...". Why is this a SHOULD as opposed to a MUST? 5. Section 4.1 says received Echo frames "should have the MH bit equal to one". Is this a normative SHOULD? If so, why is it not a MUST? |
2012-05-30
|
05 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-05-25
|
05 | Ralph Droms | [Ballot comment] From the shepherd writeup: There are references to section 10 and section 4, which should both be references to section 7. |
2012-05-25
|
05 | Ralph Droms | Ballot comment text updated for Ralph Droms |
2012-05-25
|
05 | Ralph Droms | Ballot has been issued |
2012-05-25
|
05 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2012-05-25
|
05 | Ralph Droms | Created "Approve" ballot |
2012-05-24
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-05-24
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-05-23
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) 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: Bidirectional Forwarding Detection (BFD) Support' 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 2012-06-06. 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 This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-23
|
05 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-05-23
|
05 | Ralph Droms | Placed on agenda for telechat - 2012-06-07 |
2012-05-23
|
05 | Ralph Droms | Last call was requested |
2012-05-23
|
05 | Ralph Droms | Ballot approval text was generated |
2012-05-23
|
05 | Ralph Droms | State changed to Last Call Requested from AD Evaluation |
2012-05-23
|
05 | Ralph Droms | Last call announcement was generated |
2012-05-23
|
05 | Ralph Droms | Ballot writeup was changed |
2012-05-23
|
05 | Ralph Droms | Ballot writeup was generated |
2012-05-14
|
05 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-04-27
|
05 | Donald Eastlake | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-04-27
|
05 | Amy Vezza | TRILL: Bidirectional Forwarding Detection (BFD) Support (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … TRILL: Bidirectional Forwarding Detection (BFD) Support (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated in the title page header. This document specifies the standard method of encapsulating the BFD protocol when used in conjunction with TRILL. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in RBridge campuses based on the RBridge Channel extension to the the TRILL protocol. BFD is a simple, widely deployed OAM mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. Working Group Summary There was a clear consensus in favor of the document with the consensus determination made in late February. There was then some delay due to fixing various editorial problems and nits, many of which were discussed on the mailing list during the WG Last Call, but these have now been fixed. Document Quality BFD and TRILL are both widely implemented although there have been no announced implementations of the BFD encapsulation for TRILL in this document. During the review period, the addition of some material to the Security Considerations section was suggested and adopted. See http://www.postel.org/pipermail/rbridge/2012-February/004768.html http://www.postel.org/pipermail/rbridge/2012-February/004819.html Personnel Who is the Document Shepherd? Erik Nordmark Who is the Responsible Area Director? Ralph Droms (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. Careful review of the whole document, including looking at its dependencies on rbridge-channel and rbridge-extension. There are references to section 10 and section 4, which I think should both be references to section 7. I've told the authors that this nit can be deferred until the AD review has been done. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. See also item 5 below. (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. Review related to the BFD aspects was identified. Notice of this document's working group last call was posted to the BFD WG mailing list and one of the co-authors of this draft is co-chair of the BFD WG and particularly knowledgeable in BFD. (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? None. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures on this document. There is existing and disclosed IPR on the BFD base protocol. (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? The consensus is reasonably broad. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 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. There is an ID-NITS error flags for a Normative Reference to RFC20 (defining ASCII). ** Downref: Normative reference to an Unknown state RFC: RFC 20 That is the only RFC that defines ASCII. If desirable we can change it to a reference to: USA Standard Code for Information Interchange, USAS X3.4-1967, United States of America Standards Institute, July 7, 1967 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply. (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 is a normative reference to RFC 20 whose status, as a legacy, RFC is unknown, as noted above. (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. See item 14 above. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. The IANA Considerations section correctly lists the two code points required to be allocated. These are in a sub-registry of the TRILL Parameters registry. That sub-registry is created by draft-ietf-trill-rbridge-channel, a draft being advanced at the same time as this document. (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 or sub-registries are created by this draft. (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. None. No part of this draft is in a formal language. |
2012-04-27
|
05 | Donald Eastlake | Submitted for publication. |
2012-04-27
|
05 | Amy Vezza | Note added 'Erik Nordmark (nordmark@acm.org) is the document shepherd.' |
2012-04-27
|
05 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-04-27
|
05 | Amy Vezza | IESG process started in state Publication Requested |
2012-04-27
|
05 | (System) | Earlier history may be found in the Comment Log for draft-manral-trill-bfd-encaps |
2012-04-10
|
05 | Donald Eastlake | New version available: draft-ietf-trill-rbridge-bfd-05.txt |
2012-04-09
|
04 | Vishwas Manral | New version available: draft-ietf-trill-rbridge-bfd-04.txt |
2012-04-06
|
03 | Donald Eastlake | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-04-06
|
03 | Donald Eastlake | Annotation tag Other - see Comment Log set. |
2012-03-14
|
03 | Donald Eastlake | IETF state changed to In WG Last Call from WG Document |
2012-03-12
|
03 | Donald Eastlake | Passed WG Last Call. Minor editorial / nit-fix changes needed. |
2012-03-12
|
03 | Donald Eastlake | Has been in WG LC for some time. |
2012-03-12
|
03 | Vishwas Manral | New version available: draft-ietf-trill-rbridge-bfd-03.txt |
2012-01-24
|
02 | (System) | New version available: draft-ietf-trill-rbridge-bfd-02.txt |
2011-10-31
|
01 | (System) | New version available: draft-ietf-trill-rbridge-bfd-01.txt |
2011-05-06
|
00 | (System) | New version available: draft-ietf-trill-rbridge-bfd-00.txt |