Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
draft-ietf-trill-clear-correct-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-05
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-04-14
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-07
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-03-26
|
06 | (System) | RFC Editor state changed to REF from EDIT |
2014-02-04
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-02-04
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-02-03
|
06 | (System) | IANA Action state changed to Waiting on Authors from On Hold |
2014-02-03
|
06 | (System) | RFC Editor state changed to EDIT from MISSREF |
2012-08-21
|
06 | Meral Shirazipour | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2012-08-15
|
06 | (System) | IANA Action state changed to On Hold from In Progress |
2012-08-14
|
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-08-10
|
06 | (System) | IANA Action state changed to In Progress |
2012-08-10
|
06 | Amy Vezza | State changed to Approved-announcement to be sent from None |
2012-08-10
|
06 | Amy Vezza | IESG has approved the document |
2012-08-10
|
06 | Amy Vezza | Closed "Approve" ballot |
2012-08-10
|
06 | Amy Vezza | Ballot approval text was generated |
2012-08-10
|
06 | Amy Vezza | Ballot writeup was changed |
2012-08-10
|
06 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup |
2012-07-30
|
06 | Stewart Bryant | [Ballot comment] Thank you for addressing my concerns. |
2012-07-30
|
06 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-07-30
|
06 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-06.txt |
2012-07-16
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-16
|
05 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-05.txt |
2012-07-05
|
04 | Cindy Morgan | State changed to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer |
2012-07-05
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-07-05
|
04 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-07-05
|
04 | Adrian Farrel | [Ballot comment] Section 1.2 is a useful section to have at the top of the document. I would have liked it more had it: - … [Ballot comment] Section 1.2 is a useful section to have at the top of the document. I would have liked it more had it: - listed each non-backward compatible feature (with a section reference) instead of saying "several" - explained in summary how non-compatiblity is handle in general |
2012-07-05
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-07-04
|
04 | Pete Resnick | [Ballot comment] This is strictly a procedural point for the chair/shepherd; The authors may ignore this. The ballot writeup makes me very grumpy and it … [Ballot comment] This is strictly a procedural point for the chair/shepherd; The authors may ignore this. The ballot writeup makes me very grumpy and it makes me concerned that the chair/shepherd did not do their due diligence in passing this document to the IESG. The chair/shepherd being a former AD, I have to assume that this was just a sloppy writeup and not a real problem. But I would like to see a real writeup for the record. I did not make this a DISCUSS since I am sure this COMMENT will generate the right outcome. The writeup template says for "Working Group Summary": Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Your response was: There was consensus in the working group in favor of the document. That's all you're going to say? Perhaps you'd like to add, "Unlike every other document which has gotten serious review in the IETF, this one generated no controversy at all and there were no points of contention. At the end of each face-to-face meeting, the entire WG held hands and sang songs together." :-) Seriously, we all assume there was consensus since you are submitting the document; you would not have submitted it otherwise. To make sure that due diligence was done, the answer the IESG is interested in is what the nature of the consensus was. At the very least say, "There was nothing particularly noteworthy about the consensus around this document. In the end, there was no roughness apparent for any part of the consensus." At least then we could see that you answered the question. Then in the "Document Quality", it asks: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Your answer was: The document has been carefully reviewed in the WG and by the document shepherd. The document was forwarded to the IS-IS WG mailing list, which resulted in some additional improvements. First of all, the document itself says that it is making non-backward-compatible changes to a protocol. I would *hope* that there is a fair bit of implementation of the new stuff already that would justify such changes. But you mention no existing implementations, nor any indication of vendors taking on such implementations, in your writeup. And as far as "reviewers that merit special mention", you call out "the WG and the document shepherd". If the WG and the document shepherd *hadn't* done thorough reviews, that would be worthy of mention; that they have done their jobs is not. (On the other hand, the IS-IS WG *is* worthy of mention.) This document is outside of my area of expertise. The only serious review I do is look through the document for Applications impacts and look to the writeup to see that no procedural nonsense was missed. This writeup is a pretty serious miss. Please give at least some indication on the implementation question. |
2012-07-04
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-07-02
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-07-02
|
04 | Stewart Bryant | [Ballot comment] Section 2. There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode. (note this is correctly used in section 4) … [Ballot comment] Section 2. There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode. (note this is correctly used in section 4) Section 2.2 first line s/A RBridge/An RBridge/ Section 10.1 para below bullet 2. s/Two different encoding are providing above/Two different encodings are provided above/ (I assume) The instances of "encoding" look like they should "encoding mechanisms" ? |
2012-07-02
|
04 | Stewart Bryant | Ballot comment text updated for Stewart Bryant |
2012-07-02
|
04 | Stewart Bryant | [Ballot discuss] The following points are derived from the RTG-DIR review by Mike Shand. === Section 2.1 states "Frames are not least cost routed through … [Ballot discuss] The following points are derived from the RTG-DIR review by Mike Shand. === Section 2.1 states "Frames are not least cost routed through an overloaded TRILL Switch if any other path is available..." However, ISO/IEC precludes the routing of frames through an overloaded router, even when no other path is available. (see clause 7.2.8.1) [ note all references to ISO/IEC 10589 are to the second edition ] Please clarify in the text that there is no intention for TRILL to deviate from the specified ISO/IEC 10589 behaviour. === Section 2.3.1 seems relevant here, but I don't understand the description. I must be missing something, since it would appear that a data frame forwarded to RB2 MUST attempt to forward the frame to ANY non-overloaded neighbor (other than the one it was received from). However, surely that non overloaded neighbor might then have RB2 as its next hop, and forward the frame back to RB2, which would then be required to forward the frame possibly back to the original RBridge from which it was received. Clearly this is not the desired operation, so the text needs clarifying to make it clear what is really supposed to happen. === Section 4 bullet 4 I THINK this is saying that the check must be made on any "new" LSP even if the RBridge is in overload state, and cannot store the received "new" LSP. It may be clearer to explicitly say it must do this even when overloaded. The existing parenthetical remark doesn't seem adequate. === The following issue was raised: Section 5 2nd para I don't understand the term "refragment LSPs". Is this saying that an RBridge may start with some value of originatingL1LSPBufferSize, and then be required to change to a lower value, thus necessitating that it re-generates all its LSPs which were previously larger than this new value? In a subsequent discussion with the reviewer the a some clarification was provided. Please add this clarification to the text. === Section 2.2 second para "...and Bridge RB1 can similarly...." Can is ambiguous. Is that MAY or MUST? |
2012-07-02
|
04 | Stewart Bryant | [Ballot comment] Section 2. There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode. (note this is correctly used in section 4) … [Ballot comment] Section 2. There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode. (note this is correctly used in section 4) Section 2.2 first line s/A RBridge/An RBridge/ Section 10.1 para below bullet 2. s/Two different encoding are providing above/Two different encodings are provided above/ (I assume) |
2012-07-02
|
04 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to Discuss from No Record |
2012-06-28
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2012-06-28
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2012-06-22
|
04 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-04.txt |
2012-06-20
|
03 | Stewart Bryant | [Ballot comment] I apologize for the late defer, but I wish to request a Routing Directorate review of this document. |
2012-06-20
|
03 | Stewart Bryant | Ballot comment text updated for Stewart Bryant |
2012-06-20
|
03 | Stewart Bryant | Telechat date has been changed to 2012-07-05 from 2012-06-21 |
2012-06-20
|
03 | Stewart Bryant | State changed to IESG Evaluation - Defer from Waiting for AD Go-Ahead |
2012-06-20
|
03 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-20
|
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-06-19
|
03 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-06-19
|
03 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-06-19
|
03 | Stephen Farrell | [Ballot comment] - typo in abstract: s/provide/provides/ (same sentence is correct in intro:-) - 2nd para of section 5 is odd, it says its about … [Ballot comment] - typo in abstract: s/provide/provides/ (same sentence is correct in intro:-) - 2nd para of section 5 is odd, it says its about the case where nothing is known, but then says "if it is known that other..." I'd say replacing the opening phrase with some more specific might work, e.g. "If not all MTU information is known for the entire campus..." - 10.1: "...in the Down state out a port..." is an odd phrase, maybe s/out/for/ or something? - 10.1: What is a DRB? - 10.2: I think this needs rephrasing/fixing: "Therefore, the DRB SHOULD NOT appointed an RBridge in overload as Appointed Forwarder for an VLAN unless there is no alternative." I'm not sure what it means really. |
2012-06-19
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-19
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-06-18
|
03 | Pearl Liang | IANA has reviewed draft-ietf-trill-clear-correct-03 and has the following comments: IANA notes that some of the IANA Actions requested in this document are dependent upon approval … IANA has reviewed draft-ietf-trill-clear-correct-03 and has the following comments: IANA notes that some of the IANA Actions requested in this document are dependent upon approval of another Internet-Draft (draft-eastlake-isis-rfc6326bis). Upon approval of this document, IANA understands that there are three actions it must complete. First, in the TRILL Nicknames subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at: http://www.iana.org/assignments/trill-parameters/trill-parameters.xml A new TRILL Nickname will be registered as follows: Name: [ TBD ] Description: Overload Originated Multi-destination Frame (OOMF) Reference: [ RFC-to-be ] IANA notes that the authors have suggested 0xFFC1 as the value for TBD. Second, a registration is to be made in the TRILL Neighbor TLV NEIGHBOR RECORD Flags which would be created upon completion of the IANA Actions requested in draft-eastlake-isis-rfc6326bis. In particular, in the new TRILL Neighbor TLV NEIGHBOR RECORD Flags, bit 1 would be allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service. Note that IANA understands that this action will be completed upon the approval of a different Internet-Draft, specifically: draft-eastlake-isis-rfc6326bis Third, a registration is to be made in the TRILL-PORT-VER sub-TLV subregistry created upon completion of the IANA Actions requested in draft-eastlake-isis-rfc6326bis. Bit 0 will be allocated from the Capability bits in the draft-eastlake-isis-rfc6326bis to indicate support of the VLANs Appointed sub-TLV. Note that IANA understands that this action will be completed upon the approval of a different Internet-Draft, specifically: draft-eastlake-isis-rfc6326bis IANA understands that these three 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 only to confirm what actions will be performed. |
2012-06-15
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-06-14
|
03 | Barry Leiba | [Ballot comment] As this document incorporates errata reported against the other three RFCs, but leaves those three current (not Obsoleted), it would be nice to … [Ballot comment] As this document incorporates errata reported against the other three RFCs, but leaves those three current (not Obsoleted), it would be nice to list the RFC-numbers+errata-numbers that are resolved by this document. How hard would that be to add? |
2012-06-14
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-06-14
|
03 | Ralph Droms | Ballot has been issued |
2012-06-14
|
03 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2012-06-14
|
03 | Ralph Droms | Created "Approve" ballot |
2012-06-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2012-06-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2012-06-06
|
03 | Ralph Droms | Placed on agenda for telechat - 2012-06-21 |
2012-06-06
|
03 | 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: Clarifications, Corrections, and Updates) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (TRILL: Clarifications, Corrections, and Updates) 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: Clarifications, Corrections, and Updates' 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-20. 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 The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-06-06
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-06-06
|
03 | Ralph Droms | Last call was requested |
2012-06-06
|
03 | Ralph Droms | Last call announcement was generated |
2012-06-06
|
03 | Ralph Droms | Ballot approval text was generated |
2012-06-06
|
03 | Ralph Droms | State changed to Last Call Requested from AD Evaluation |
2012-05-25
|
03 | Ralph Droms | Ballot writeup was changed |
2012-05-25
|
03 | Ralph Droms | Ballot writeup was generated |
2012-05-25
|
03 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-05-21
|
03 | Donald Eastlake | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-05-17
|
03 | Amy Vezza | TRILL: Clarifications, Corrections, and Updates draft-ietf-trill-clear-correct-03 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … TRILL: Clarifications, Corrections, and Updates draft-ietf-trill-clear-correct-03 (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. That is needed since this document updates RFC 6325, RFC 6327, and RFC 6439 which are proposed standards. (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 The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. The clarifications, corrections, and updates cover many areas, but the most substantial ones are in the areas of: - Overloaded and/or Unreachable RBridges - Distribution Trees - Nickname selection - Maximum Transmission Unit Note that one change in this document (section 3.4) is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes. Working Group Summary There was consensus in the working group in favor of the document. Document Quality The document has been carefully reviewed in the WG and by the document shepherd. The document was forwarded to the IS-IS WG mailing list, which resulted in some additional improvements. 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. Reviewed the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. The -00 version of the draft was forwarded to the IS-IS list which resulted in comments from Mike Shand which were incorporated in the draft. (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. (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 document has been discussed in the WG first as an individual draft and later as a WG draft with relatively broad participation. However, only a few commented on the actual WG last call. (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. While the abstract says "This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, RFC 6439." the id-nits tool generates comments to the effect that the "abstract doesn't seem to directly say this". I suspect that is because the above "updates" text doesn't follow some unstated formatting assumption in the id-nits tool. id-nits incorrectly generates a warning about a "non-RFC5735-compliant IPv4 addresses" for the text "... Section 4.6.2.1" (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 draft-eastlake-isis-rfc6326bis which is the formal definition of the IS-IS code points and formats. The plan is for that document to become an IS-IS WG draft and be reviewed in the IS-IS WG. That process has already been initiated. (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. (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. Verified that the three items in the IANA considerations section match the text in the 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. (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-05-17
|
03 | Donald Eastlake | Submitted for publication by Erik Nordmark. |
2012-05-17
|
03 | Amy Vezza | Note added 'Erik Nordmark (nordmark@acm.org) is the document shepherd.' |
2012-05-17
|
03 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-05-17
|
03 | Amy Vezza | IESG process started in state Publication Requested |
2012-05-17
|
03 | (System) | Earlier history may be found in the Comment Log for draft-eastlake-trill-rbridge-clear-correct |
2012-05-08
|
03 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-03.txt |
2012-04-27
|
02 | Donald Eastlake | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-04-26
|
02 | Donald Eastlake | This draft has WG consensus. |
2012-04-26
|
02 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-02.txt |
2012-03-14
|
01 | Donald Eastlake | IETF state changed to In WG Last Call from WG Document |
2012-03-10
|
01 | Donald Eastlake | Has been in WG LC for a while. |
2012-03-10
|
01 | Donald Eastlake | New version available: draft-ietf-trill-clear-correct-01.txt |
2012-01-27
|
00 | (System) | New version available: draft-ietf-trill-clear-correct-00.txt |