Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
draft-ietf-trill-pseudonode-nickname-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-02-17
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-02-08
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-01-29
|
07 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2016-01-29
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2016-01-28
|
07 | (System) | RFC Editor state changed to REF from AUTH |
2016-01-21
|
07 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-11-02
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2015-10-14
|
07 | (System) | Notify list changed from draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org, trill-chairs@ietf.org, draft-ietf-trill-pseudonode-nickname@ietf.org, draft-ietf-trill-pseudonode-nickname.ad@ietf.org, d3e3e3@gmail.com to (None) |
2015-10-05
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-10-01
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-10-01
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-09-30
|
07 | (System) | RFC Editor state changed to MISSREF |
2015-09-30
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-09-30
|
07 | (System) | Announcement was received by RFC Editor |
2015-09-29
|
07 | (System) | IANA Action state changed to In Progress |
2015-09-29
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-09-29
|
07 | Amy Vezza | IESG has approved the document |
2015-09-29
|
07 | Amy Vezza | Closed "Approve" ballot |
2015-09-29
|
07 | Amy Vezza | Ballot approval text was generated |
2015-09-29
|
07 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-09-29
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2015-09-28
|
07 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points. |
2015-09-28
|
07 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2015-09-25
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-09-25
|
07 | Mingui Zhang | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-09-25
|
07 | Mingui Zhang | New version available: draft-ietf-trill-pseudonode-nickname-07.txt |
2015-09-17
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-09-17
|
06 | Jari Arkko | [Ballot discuss] I am referring to Russ Housley's Gen-ART review. I believe we still has to resolve what to do about the sort order. (Maybe … [Ballot discuss] I am referring to Russ Housley's Gen-ART review. I believe we still has to resolve what to do about the sort order. (Maybe this helps: I’m not actually sure why in a k-element set you order them based mod k because that would seem to produce likely duplicates. Since your backup option in the case of duplicates is proper numeric sort, why just not do that and only that? E.g. "RBridges are sorted in byte string ascending order by their LAALP IDs, or if they are equal, by their System IDs considered as unsigned integers.” But it could also be that it is too early and I have not yet had enough Diet Coke…) Also, I am not sure I understand this in Section 5.2: Assuming there are … k member RBridges in an RBv; ... each RBridge is referred to as RBj where 0 <= j < k-1 Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early here and maybe I’m missing something. |
2015-09-17
|
06 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2015-09-17
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace. |
2015-09-17
|
06 | Stephen Farrell | [Ballot discuss] I have two questions where it's not clear to me if this specification does or does not introduce new vulnerabilities. It could well … [Ballot discuss] I have two questions where it's not clear to me if this specification does or does not introduce new vulnerabilities. It could well be that it does not and these are handled elsewhere, but I'm not sure so... (1) How is authorization for being a member of an RBv handled? (2) If a rogue RB can add itself to an RBv can it arrange things so the rogue RB becomes the DF for the RBv? (If so, that would seem to create new DoS opportunities at least.) |
2015-09-17
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-09-17
|
06 | Alissa Cooper | [Ballot comment] Agree with Spencer's first comment. |
2015-09-17
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-09-16
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-09-16
|
06 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-16
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-16
|
06 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-09-16
|
06 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-09-16
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-09-16
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-09-15
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-15
|
06 | Spencer Dawkins | [Ballot comment] This was an easy document for me to read through (I have some exposure to TRILL but am not skilled in the art). … [Ballot comment] This was an easy document for me to read through (I have some exposure to TRILL but am not skilled in the art). Thank you for that. I did have some questions, but nothing at Discuss level. In this text: Introduction Other methods are possible; for example the specification in this document and the specification in [MultiAttach] could be simultaneously deployed for different AAE groups in the same campus. It is RECOMMENDED that only one method be adopted in a TRILL ^^^^^^^^^^^ campus. For example, if the method is [MultiAttach] is used, TRILL switches need to support the capability indicated by the Capability Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the method defined in this document is adopted, TRILL switches need to support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a TRILL campus that deploys both AAE methods, TRILL switches are required to support both methods. I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but more broadly, I THINK this paragraph is saying, "using multiple methods on a TRILL campus will work, but if you use multiple methods, all of the TRILL switches on the campus MUST support both methods". Did I get that right? If so ... you might give some justification for adopting only one method (my guesses were capital expense? operating expense? complexity in troubleshooting?), and perhaps even some explanation why you might adopt more than one method (I was guessing that you'd use more than one because some of your equipment doesn't support the method you want to use, but if TRILL switches have to support both methods, that isn't the reason, is it?) In this text: 3. Virtual RBridge and its Pseudo-nickname Since RBv is not a physical node and no TRILL frames are forwarded between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be created for an RBv. RBv cannot act as a root when constructing distribution trees for multi-destination traffic and its pseudo- nickname is ignored when determining the distribution tree root for TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST be set to 0, and this nickname SHOULD NOT be listed in the "s" ^^^^^^^^^^ nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the highest priority tree root nickname. what happens if this SHOULD NOT is ignored? Do things still work? |
2015-09-15
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-09-15
|
06 | Ben Campbell | [Ballot comment] -- section 12, last paragraph: Elaboration on the details would be useful. This draft adds new procedures; what analysis was done to show … [Ballot comment] -- section 12, last paragraph: Elaboration on the details would be useful. This draft adds new procedures; what analysis was done to show those new procedures have no new security impact? Editorial: -- 1.1, definition of AAE, "AAE is also referred to as edge group or Virtual RBridge in this document" Why use multiple terms for the same thing? This seems to create awkward wording in several places, where the text repeats things like “In an AAE group (i.e. RBv)…” |
2015-09-15
|
06 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-09-15
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-09-15
|
06 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-09-15
|
06 | Alia Atlas | Ballot has been issued |
2015-09-15
|
06 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-09-15
|
06 | Alia Atlas | Created "Approve" ballot |
2015-09-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Linda Dunbar. |
2015-09-11
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2015-09-11
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2015-09-08
|
06 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Ready. Reviewer: Russ White. |
2015-09-06
|
06 | Mingui Zhang | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-09-06
|
06 | Mingui Zhang | New version available: draft-ietf-trill-pseudonode-nickname-06.txt |
2015-09-01
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2015-09-01
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2015-09-01
|
05 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Al Bolivar was rejected |
2015-09-01
|
05 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-08-31
|
05 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2015-08-31
|
05 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-trill-pseudonode-nickname-05. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-trill-pseudonode-nickname-05. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which IANA needs to complete. In the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at: https://www.iana.org/assignments/trill-parameters/ four new registrations will be made as follows: Type: [ TBD-at-Registration ] Name: PN-LAALP-Membership Reference: [ RFC-to-be ] Type: [ TBD-at-Registration ] Name: PN-RBv Reference: [ RFC-to-be ] Type: [ TBD-at-Registration ] Name: PN-MAC-RI-LAALP-INFO-START Reference: [ RFC-to-be ] Type: [ TBD-at-Registration ] Name: PN-MAC-RI-LAALP-INFO-END Reference: [ RFC-to-be ] IANA understands that these registrations are to come from the type range below the value 255. 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. |
2015-08-25
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Russ White |
2015-08-25
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Russ White |
2015-08-23
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Bolivar |
2015-08-23
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Bolivar |
2015-08-20
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2015-08-20
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2015-08-20
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2015-08-20
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2015-08-18
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-08-18
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL: Pseudo-Nickname for Active-Active Access) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL: Pseudo-Nickname for Active-Active Access) 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: Pseudo-Nickname for Active-Active Access' 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 2015-09-01. 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 support for flow level multi-pathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (TRILL switch) group providing active-active access to such an end station are represented as a Virtual RBridge. Based on the concept of Virtual RBridge along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2083/ https://datatracker.ietf.org/ipr/2444/ |
2015-08-18
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-08-18
|
05 | Alia Atlas | Ballot writeup was changed |
2015-08-18
|
05 | Alia Atlas | Placed on agenda for telechat - 2015-09-17 |
2015-08-18
|
05 | Alia Atlas | Last call was requested |
2015-08-18
|
05 | Alia Atlas | Last call announcement was generated |
2015-08-18
|
05 | Alia Atlas | Ballot approval text was generated |
2015-08-18
|
05 | Alia Atlas | Ballot writeup was generated |
2015-08-18
|
05 | Alia Atlas | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-08-17
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-08-17
|
05 | Mingui Zhang | New version available: draft-ietf-trill-pseudonode-nickname-05.txt |
2015-07-30
|
04 | Alia Atlas | 1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic idea of DF is to elect one … 1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic idea of DF is to elect one RBridge per VLAN from an RBv to egress multi-destination TRILL Data traffic and replicate locally-received multi-destination native frames to the CEs served by the RBv." but then on p. 16 in Step 4 part 1), it says: "RBv ports associated with the same pseudo-nickname as that of the incoming port, no matter whether RBi is the DF for the frame's VLAN on the outgoing ports except that the frame MUST NOT be replicated back to the incoming port". This seems to be contradictory. Moreover, if one say CE1, CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the packet to CE1 and CE2 while RB1 would also do so as the DF? Could you please clarify what is causing the inconsistency and problem? Maybe the text in 6.1 on p. 18 helps describe that there are actually two cases to the text on p. 16? 2) On p.23 in Sec 9.1: There is no way of identifying what the type of the LAALP ID is. Assuming it is a number and meaning doesn't matter, it would be really good to clarify that. 3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv APPsub-TLV? Could you please describe that sequence? |
2015-07-30
|
04 | Alia Atlas | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-07-30
|
04 | Alia Atlas | IESG state changed to AD Evaluation from Publication Requested |
2015-03-26
|
04 | Donald Eastlake | (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? … (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? This is targeted at Proposed Standard as indicated on the title page. This document specifies protocol behavior of TRILL switches to implement active-active services at the TRILL edge using a pseudo-nickname to represent an edge group of RBridges. (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: Active-active access at the TRILL edge is the extension of flow level multi-pathing and rapid fail-over service available in the interior of a TRILL campus to end stations that are multiply connected to a TRILL campus edge as discussed in RFC 7379. In this document, a Virtual RBridge's pseudo-nickname represents the edge RBridge group providing active-active access to such an end station. Working Group Summary: Early discussion in the TRILL WG favored a pseudo-node nickname approach similar to that in this draft. Later analysis resulted in the three alternatives described in the Introduction to draft-ietf-trill-aa-multi-attach. Two of these, which can be deployed simultaneously in a TRILL campus, are being advanced by the WG, an evolved version of alternative 1 using a pseudo-nickname in this draft and alternative 3 in draft-ietf-trill-aa-multi- attach. There was good WG support for this draft. Document Quality: This document was developed by the WG over a two-year period. The document is of good quality and is being implemented. Personnel: Document Shepherd: Donald Eastlake, 3rd Responsible Area Director: Alia Atlas (3) Briefly describe the review of this document that was performed by the Document Shepherd. The Shepherd has reviewed this document at various stages and provided feedback. The most recent and formal Shepherd review is here: http://www.ietf.org/mail-archive/web/trill/current/msg06637.html (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? No. (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. (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. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Two IPR disclosures have been filed against this draft. See https://datatracker.ietf.org/ipr/2083/ and https://datatracker.ietf.org/ipr/2444/ These IPR disclosures were not noted in the first WG Last Call on this draft and a 2nd WG Last Call was specifically held due to that oversight. There were no objections. (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? Many members of the WG have been involved in the development of strategies to provide active-active support at the TRILL edge [RFC7379]. This draft represents the original direction decided by the original active-active design team coordinated by Tissa Senevirathne. Consensus for this draft continues to be 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. There are no actual nits. The nits checker complains about non-RFC5735-compliant IPv4 addresses, but these are references to level 4 sections in other documents. (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 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? This document has normative references to draft-ietf-trill-cmt and draft-ietf-trill-rfc7180bis both of which have passed WG Last Call. (15) Are there downward normative references (see RFC 3967)? No, although there is a reference to the ISO/IEC IS-IS standard about which the nits checker warns. (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. 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). The IANA Considerations were carefully compared with the rest of the text. It requests appropriate assignments from the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" Registry. No other registries are used and no new registries created. (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 IANA 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 review required. |
2015-03-25
|
04 | Amy Vezza | Shepherding AD changed to Alia Atlas |
2015-03-22
|
04 | Susan Hares | (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? … (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? This is targeted at Proposed Standard as indicated on the title page. This document specifies protocol behavior of TRILL switches to implement active-active services at the TRILL edge using a pseudo-nickname to represent an edge group of RBridges. (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: Active-active access at the TRILL edge is the extension of flow level multi-pathing and rapid fail-over service available in the interior of a TRILL campus to end stations that are multiply connected to a TRILL campus edge as discussed in RFC 7379. In this document, a Virtual RBridge's pseudo-nickname represents the edge RBridge group providing active-active access to such an end station. Working Group Summary: Early discussion in the TRILL WG favored a pseudo-node nickname approach similar to that in this draft. Later analysis resulted in the three alternatives described in the Introduction to draft-ietf-trill-aa-multi-attach. Two of these, which can be deployed simultaneously in a TRILL campus, are being advanced by the WG, an evolved version of alternative 1 using a pseudo-nickname in this draft and alternative 3 in draft-ietf-trill-aa-multi- attach. There was good WG support for this draft. Document Quality: This document was developed by the WG over a two-year period. The document is of good quality and is being implemented. Personnel: Document Shepherd: Donald Eastlake, 3rd Responsible Area Director: Ted Lemon (3) Briefly describe the review of this document that was performed by the Document Shepherd. The Shepherd has reviewed this document at various stages and provided feedback. The most recent and formal Shepherd review is here: http://www.ietf.org/mail-archive/web/trill/current/msg06637.html (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? No. (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. (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. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Two IPR disclosures have been filed against this draft. See https://datatracker.ietf.org/ipr/2083/ and https://datatracker.ietf.org/ipr/2444/ These IPR disclosures were not noted in the first WG Last Call on this draft and a 2nd WG Last Call was specifically held due to that oversight. There were no objections. (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? Many members of the WG have been involved in the development of strategies to provide active-active support at the TRILL edge [RFC7379]. This draft represents the original direction decided by the original active-active design team coordinated by Tissa Senevirathne. Consensus for this draft continues to be 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. There are no actual nits. The nits checker complains about non-RFC5735-compliant IPv4 addresses, but these are references to level 4 sections in other documents. (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 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? This document has normative references to draft-ietf-trill-cmt and draft-ietf-trill-rfc7180bis both of which have passed WG Last Call. (15) Are there downward normative references (see RFC 3967)? No, although there is a reference to the ISO/IEC IS-IS standard about which the nits checker warns. (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. 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). The IANA Considerations were carefully compared with the rest of the text. It requests appropriate assignments from the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" Registry. No other registries are used and no new registries created. (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 IANA 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 review required. |
2015-03-22
|
04 | Susan Hares | State Change Notice email list changed to draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org, trill-chairs@ietf.org, draft-ietf-trill-pseudonode-nickname@ietf.org, draft-ietf-trill-pseudonode-nickname.ad@ietf.org, trill@ietf.org, d3e3e3@gmail.com |
2015-03-22
|
04 | Susan Hares | Responsible AD changed to Ted Lemon |
2015-03-22
|
04 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-03-22
|
04 | Susan Hares | IESG state changed to Publication Requested |
2015-03-22
|
04 | Susan Hares | IESG process started in state Publication Requested |
2015-03-20
|
04 | Donald Eastlake | Changed document writeup |
2015-03-10
|
04 | Donald Eastlake | Changed document writeup |
2015-03-09
|
04 | Hongjun Zhai | New version available: draft-ietf-trill-pseudonode-nickname-04.txt |
2015-03-06
|
03 | Donald Eastlake | Changed document writeup |
2015-02-18
|
03 | Hongjun Zhai | New version available: draft-ietf-trill-pseudonode-nickname-03.txt |
2015-02-11
|
02 | Donald Eastlake | Tag Doc Shepherd Follow-up Underway set. |
2015-02-11
|
02 | Donald Eastlake | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2014-11-23
|
02 | Donald Eastlake | IETF WG state changed to In WG Last Call from WG Document |
2014-11-23
|
02 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2014-10-26
|
02 | Hongjun Zhai | New version available: draft-ietf-trill-pseudonode-nickname-02.txt |
2014-09-26
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-trill-pseudonode-nickname-01 | |
2014-09-08
|
01 | Donald Eastlake | Document shepherd changed to Donald E. Eastlake 3rd |
2014-09-05
|
01 | Hongjun Zhai | New version available: draft-ietf-trill-pseudonode-nickname-01.txt |
2014-07-23
|
00 | Donald Eastlake | This document now replaces draft-hu-trill-pseudonode-nickname instead of None |
2014-07-23
|
00 | Hongjun Zhai | New version available: draft-ietf-trill-pseudonode-nickname-00.txt |