Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-multilevel-single-nickname-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-12-03
|
17 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2022-02-10
|
17 | (System) | Received changes through RFC Editor sync (created alias RFC 9183, changed title to 'Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection … Received changes through RFC Editor sync (created alias RFC 9183, changed title to 'Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)', changed abstract to 'A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, area border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.', changed pages to 13, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-02-10, changed IESG state to RFC Published) |
2022-02-10
|
17 | (System) | RFC published |
2022-02-09
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-01-10
|
17 | (System) | RFC Editor state changed to AUTH48 |
2021-12-08
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-11-17
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-11-17
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-11-17
|
17 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-11-16
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-11-16
|
17 | (System) | RFC Editor state changed to EDIT |
2021-11-16
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-11-16
|
17 | (System) | Announcement was received by RFC Editor |
2021-11-16
|
17 | (System) | IANA Action state changed to In Progress |
2021-11-16
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-11-16
|
17 | Cindy Morgan | IESG has approved the document |
2021-11-16
|
17 | Cindy Morgan | Closed "Approve" ballot |
2021-11-16
|
17 | Cindy Morgan | Ballot approval text was generated |
2021-11-16
|
17 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-11-16
|
17 | Martin Vigoureux | Ballot approval text was generated |
2021-11-12
|
17 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-17.txt |
2021-11-12
|
17 | (System) | New version accepted (logged-in submitter: Donald Eastlake) |
2021-11-12
|
17 | Donald Eastlake | Uploaded new revision |
2021-11-10
|
16 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-16.txt |
2021-11-10
|
16 | (System) | New version accepted (logged-in submitter: Donald Eastlake) |
2021-11-10
|
16 | Donald Eastlake | Uploaded new revision |
2021-10-05
|
15 | Samuel Weiler | Request for Telechat review by SECDIR Completed: Not Ready. Reviewer: Samuel Weiler. Sent review to list. |
2021-09-23
|
15 | (System) | Removed all action holders (IESG state changed) |
2021-09-23
|
15 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2021-09-23
|
15 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the efforts on this specification. I would like to echo what Benjamin Kaduk had already said - I doubt the market … [Ballot comment] Thanks for the efforts on this specification. I would like to echo what Benjamin Kaduk had already said - I doubt the market demand of this technology even if this specification solves some tidentified TRILL issues as mentioned in the shepherd write up. I think the section 3.2 has been a bit confusing and my IESG colleagues have already covered them - like "MUST agree on a pseudorandom algorithm...". I am a bit struggling with the below procedure though - The packet is flooded on the Level 2 tree to reach both RB3 and RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will drop the packet. If RB3 is already selected then why do we need to flood the tree and bother sending the packet to RB30? Is the packet send just because it is a multicast packet? Why can't it switch to unicast mode? I think I am missing something there in the description. I would also suggest to put Appendix A in the context of the main text i.e. refer from where this is relavent. |
2021-09-23
|
15 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-09-22
|
15 | Murray Kucherawy | [Ballot comment] Section 1: * "Informational [RFC8243] is an educational document ..." -- I suggest removing "Informational", or replacing it with the actual … [Ballot comment] Section 1: * "Informational [RFC8243] is an educational document ..." -- I suggest removing "Informational", or replacing it with the actual title of that RFC. |
2021-09-22
|
15 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-09-22
|
15 | Roman Danyliw | [Ballot comment] Thank you to Samuel Weiler for the SECDIR review. |
2021-09-22
|
15 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-09-22
|
15 | Benjamin Kaduk | [Ballot comment] As a general remark, it seems that the use of the set of border nicknames to designate an L1 area means that for … [Ballot comment] As a general remark, it seems that the use of the set of border nicknames to designate an L1 area means that for a degenerate case where there are exactly two L1 areas and the L2 area consists of all the border RBridges, we don't actually distinguish the L1 areas and so the setup is essentially degenerate with a non-multilevel TRILL. This doesn't seem problematic, though, and once the L2 topology becomes more complex (while remaining connected), uniqueness of L1 area identifiers seems guaranteed. It also feels a little like this draft is being progressed for sake of completeness rather than due to specific demand -- the shepherd writeup doesn't convey much sense of market demand (rather, it expresses a desire from the WG to press ahead to try to get traction in the market, even though there is IPR disclosed), and the history of the draft includes two periods of expiration and a few years of only minimal revision at the 6-month expiration boundary, that doesn't indicate much urgency to complete it. That said, the data I have at the moment isn't really strong enough to push me over to balloting Abstain instead of No Objection. Section 3.1 - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44). (The I strongly suggest spending a few words to reiterate how RB3 knows to replace 3 with 44 in this scenario. (I.e., looking up based on D from the packet contents.) Section 3.2 All border RBridges of an area MUST agree on a pseudorandom algorithm as the tie-breaker to locally determine the DBRB. The same pseudorandom algorithm will be reused in Section 4 for the purpose of load balancing. It's also possible to implement a certain election protocol to elect the DBRB. However, such kind of implementations are out the scope of this document. By default, the border RBridge with the smallest nickname, considered as an unsigned integer, is elected DBRB. (Editorial) It seems a little weird to me to write this as "MUST agree on a pseudorandom algorithm ... oh but you could use leader election instead as well, we just don't say how to" -- the "MUST" requirement doesn't seem to match up with the actual requirement for correct operation. I tried to shuffle things around to make the actual "MUST" requirement match up, as follows, though I'm not fully confident that my proposal is actually correct... NEW: All border RBridges of an area MUST agree on a procedure for determining the DBRB for the area. This document assumes that the border RBridge with smallest nickname (considered as an unsigned integer) is elected DBRB, and that there is an agreed pseudo-random algorithm as a tie-breaker (and reuses that algorithm in Section 4 for the purpose of load balancing), but that does not preclude the use of leader-election or similar procedures. - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with the root RBridge nickname of a distribution tree of L1 area {3,30} say 30. (Here, the ingress nickname MAY be replaced with a different area nickname selected from {2,20}, the set of border RBridges to the ingress area, as specified in Section 4.) Now suppose that RB27 has learned the location of D (attached to nickname 3), but RB3 does not know where D is. In that case, RB3 must turn the packet into a multi- destination packet and floods it on the distribution tree of L1 area {3,30}. I think either there's a missing paragraph break here, or we need to s/RB27/RB3/ -- RB27 is attached to S, but this part of the procedure is discussing how RB3 is performing level transition to inject the packet into area {3,30}. - RB30, will receive the packet flooded on the L1 tree by RB3. It is important that RB30 does not transition this packet back to L2. RB30 should also examine the ingress nickname of this packet. If this nickname is found to be an L2 border RBridge nickname, RB30 must not transition the packet back to L2. The way this condition is written ("to be an L2 border RBridge nickname", with no restriction to the area in which it's received) seems to imply an assumption that any given border RBridge is in exactly one level 1 area. Since §6 of this document says that a given border RBridge can connect multiple L1 areas, I think we should examine more carefully the situation here when a given border RBridge uses multiple nicknames for different L1 areas. As written, this procedure might result in failing to flood some packets to L2 at all. Section 6 RBridge's nickname. For a multicast packet: either RB1 is not the DBRB and RB1 will not transition the packet or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the following rules: We write "the DBRB" as if there is a single distinguished one. But when there are multiple L1 areas in play, IIUC each area can have a distinct DBRB. Should we specify which area RB1 needs to be the DBRB in in order to trigger these procedures (or whether it must do so if it is a DBRB in *any* area)? dropped by RB1. It recognizes such packets by their ingress nickname being the nickname of one of the border RBridges of an L1 area to which the receiving border RBridge is attached. Similarly, if RB1 is not the DBRB for an area, the earlier requirement to drop draffic from L2 and not pass it to that area, regardless of the ingress nickname in use, seems to take priority. So perhaps this should be "of an L1 area for which the receiving border RBridge is the DBRB"? Section 8 Is there anything useful to say about the transient behavior as information about a partition/repair propagates to the border RBridges of the area? If an L1 Border RBridge Nickname is configured at an RBridge and that [...] nickname multilevel do not support the configuration of an L2 Border RBridge Nickname. [...] Just to confirm, the distinction between "L1 Border RBridge Nickname" and "L2 Border RBridge Nickname" is correct and as intended? I think I see one or two other instances of the "L2" form in the document, but this one leaves me most uncertain of the group. If there are multiple border RBridges between an L1 area and L2 and one or more of them only support or are only configured for unique nickname multilevel ([RFC8397]), any of these border RBridges that are configured to used single nickname multilevel as specified in this document MUST support [RFC8397] and fall back to behaving as a unique nickname border RBridge for that L1 area. [...] Since this condition is predicated on the deployment environment, not the local implementation, it seems to be a de facto requirement on all implementations of this document to also support RFC 8397 and the fallback. Perhaps it's better to frame it that way. I think we should also say something about how an implementation will detect that there are other border RBridges in a given area that are using unique nickname multilevel. Section 9 The newly defined TRILL APPsub-TLVs in Section 5 are transported in IS-IS PDUs whose authenticity can be enforced using regular IS-IS security mechanism [IS-IS] [RFC5310]. This document raises no new security issues for IS-IS. Thanks for mentioning that IS-IS has a mechanism for authenticating PDUs (and the corresponding implication that it's not the default behavior). That said, I'm not sure that "raises no new security issues" is quite correct, and would propose to adopt a formulation similar to what RFC 8397 uses. E.g., "malicious devices may fake the [sub-TLVs] to [attract traffic, partition areas, induce excessive state on L2 RBridges, etc.]. For this reason, RBridges SHOULD be configured to use the IS-IS Authenticaiton TLV (10) in the IS-IS PDUs, particularly those containing [sub-TLVs], so that IS-IS security [RFC5310] can be used to authenticate those PDUs and discard them if they are forged." Using a variation of aggregated nicknames, and the resulting possible duplication of nicknames between areas, increases the possibility of a TRILL Data packet being delivered to the wrong egress RBridge if Increases compared to what baseline? areas are unexpectedly merged. However, in many cases the data would be discarded at that egress RBridge because it would not match a known end station data label/MAC address. Is that true for broadcast/multicast or just unicast? Section 11.2 It seems that [IS-IS] ought to be a normative reference. NITS Section 4.1, 4.2 nickname. The selection is simply based on a pseudorandom algorithm as defined in Section 5.3 of [RFC7357]. With the random ingress Pedantically, the referenced document gives an example of a PRF, but does not definitively define "a pseudorandom algorithm". So "described" or "discussed" might be more appropriate than "defined". Section 8 Other than the manageability considerations specified above, the manageability specifications in [RFC6325] still apply. Is this an "other than" or an "in addition to"? |
2021-09-22
|
15 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-09-22
|
15 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. With no previous knowledge of TRILL, I scanned the document for ART issues and did … [Ballot comment] Thank you for the work on this document. With no previous knowledge of TRILL, I scanned the document for ART issues and did not find any. The only comment I have is the one Alvaro already brought up: I would have much preferred if the example was split from the general specification behaviour, and would encourage the authors to rephrase the text accordingly. Francesca |
2021-09-22
|
15 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-09-22
|
15 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-09-20
|
15 | Alvaro Retana | [Ballot comment] (1) The specification of the forwarding is done by using normative language while presenting an "illustrative example" (§3). While the example is thorough, … [Ballot comment] (1) The specification of the forwarding is done by using normative language while presenting an "illustrative example" (§3). While the example is thorough, this way of specifying behavior is not ideal and, from my point of view, can result in confusion and underspecification. Please remove the normative language from the example and include a section where the behavior is clearly and generally specified (i.e., not specific to the example). Then, the example can, as needed, refer to the specification section. (2) §3.2 -- the wording here is confusing: ... All border RBridges of an area MUST agree on a pseudorandom algorithm as the tie-breaker to locally determine the DBRB. The same pseudorandom algorithm will be reused in Section 4 for the purpose of load balancing. It's also possible to implement a certain election protocol to elect the DBRB. However, such kind of implementations are out the scope of this document. By default, the border RBridge with the smallest nickname, considered as an unsigned integer, is elected DBRB. The requirement to "agree on a pseudorandom algorithm" sounds misleading to me (pointing to the "same pseudorandom algorithm" used later) because a default is mentioned later. Suggestion> By default, the border RBridge with the smallest nickname, considered as an unsigned integer, is elected DBRB. All border RBridges of an area MUST agree on the mechanism used to determine the DBRB locally. The use of an alternative is possible, but out of the scope of this document; one such mechanism is used in Section 4 for load balancing. [Note that even though I'm suggesting normative text in §3, see my point above about putting the specification separate from the example.] (3) §4.1: "RBridge MAY select one area nickname" This selection is needed to achieve per-flow load balancing, so it is not clear to me why the action is optional. §4.2 uses the same phrase but adds a recommended action ("SHOULD choose..."). Is the action in this case recommended or optional? (4) The Introduction says that "the nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned to represent L1 areas as such." I take that to mean that there is a single nickname used for both L1 and L2. Is that the right interpretation? If so, then I am confused by §6 not requiring a single nickname: "RB1 SHOULD use a single area nickname for all these areas." What am I missing? When is it ok not to use a single nickname? (5) Should there be a reference to the appendix form the main text? |
2021-09-20
|
15 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-09-20
|
15 | Lars Eggert | [Ballot comment] All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as … [Ballot comment] All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3.1. , paragraph 8, nit: - reamins 3.) Also RB2 learns that S is attached to nickname 27 in - - + remains 3.) Also RB2 learns that S is attached to nickname 27 in + + Section 3.1. , paragraph 3, nit: > ose the egress nickname remains 3.) Also RB2 learns that S is attached to ni > ^^^^ A comma may be missing after the conjunctive/linking adverb "Also". Section 3.2. , paragraph 2, nit: > for the multi-destination packet. For a unknown-unicast packet, if the DBRB h > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 3.2. , paragraph 4, nit: > e of the area {2,20}, RB2 must not forwarded the packet into this area. - The > ^^^^^^^^^ The modal verb "must" requires the verb's base form. Section 3.2. , paragraph 10, nit: > will see one source MAC address flip flopping among multiple ingress RBridge > ^^^^^^^^^^^^^ This word is normally spelled with a hyphen. These URLs in the document can probably be converted to HTTPS: * http://www.painless-security.com |
2021-09-20
|
15 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-09-19
|
15 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2021-09-17
|
15 | Martin Duke | [Ballot comment] Thanks for the clearly written document -- I was able to follow it with no background in the subject. (3.2) "However, such kind … [Ballot comment] Thanks for the clearly written document -- I was able to follow it with no background in the subject. (3.2) "However, such kind of implementations are out the scope of this document. By default, the border RBridge with the smallest nickname, considered as an unsigned integer, is elected DBRB." This default seems suboptimal, as the lowest value nickname will get all the traffic. Perhaps some sort of xor with flow-based entropy (e.g. the source and destination MAC) would be a better choice here? (4.1) Relatedly, "Note that the value of the destination MAC address SHOULD be excluded from the input of this pseudorandom algorithm, otherwise the egress RBridge will see one source MAC address flip flopping among multiple ingress RBridges." I have thought about this for a while and cannot understand this assertion. Why is it a problem for an RBridge to route different flows to different RBridges if the intent is to load balance? |
2021-09-17
|
15 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-09-16
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2021-09-16
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2021-09-16
|
15 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Samuel Weiler |
2021-09-16
|
15 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Samuel Weiler |
2021-09-15
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-09-13
|
15 | Cindy Morgan | Placed on agenda for telechat - 2021-09-23 |
2021-09-13
|
15 | Martin Vigoureux | Ballot has been issued |
2021-09-13
|
15 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2021-09-13
|
15 | Martin Vigoureux | Created "Approve" ballot |
2021-09-13
|
15 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-09-13
|
15 | Martin Vigoureux | IESG state changed to Waiting for Writeup from AD Evaluation |
2021-09-13
|
15 | Martin Vigoureux | IESG state changed to AD Evaluation from AD Evaluation::AD Followup |
2021-09-13
|
15 | Martin Vigoureux | Ballot writeup was changed |
2021-08-24
|
15 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-15.txt |
2021-08-24
|
15 | (System) | New version accepted (logged-in submitter: Donald Eastlake) |
2021-08-24
|
15 | Donald Eastlake | Uploaded new revision |
2021-07-12
|
14 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-07-12
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-07-12
|
14 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-14.txt |
2021-07-12
|
14 | (System) | New version approved |
2021-07-12
|
14 | (System) | Request for posting confirmation emailed to previous authors: Donald Eastlake , Hongjun Zhai , Margaret Cullen , Mingui Zhang , Radia Perlman |
2021-07-12
|
14 | Donald Eastlake | Uploaded new revision |
2021-07-09
|
13 | (System) | Changed action holders to Radia Perlman, Donald Eastlake, Martin Vigoureux, Mingui Zhang, Hongjun Zhai, Margaret Cullen (IESG state changed) |
2021-07-09
|
13 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from Waiting for Writeup |
2021-07-08
|
13 | Susan Hares | (1) What type of RFC: Proposed standard a) Why is this the proper type of RFC? adds 2 TLVs to TRILLs APPsub-TLV. Must be standard … (1) What type of RFC: Proposed standard a) Why is this the proper type of RFC? adds 2 TLVs to TRILLs APPsub-TLV. Must be standard to add these TLVs. Is this type of RFC indicated in the title page header? This draft is aimed at Proposed Standard as it specifies an aggregated nickname protocol for multilevel TRILL. (Informational RFC 8243 describes the difference between aggregated and unique nickname protocols for multilevel TRILL. RFC 8397 is the Proposed Standard for unique nickname multilevel TRILL and this draft is intended to become the Proposed Standard for aggregated nickname multilevel 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 a protocol for multilevel TRILL using a form of aggregated nicknames where level 1 areas are identified by the set of border RBridges connecting them to level 2. Nicknames can be re-used in multiple level 1 areas of this type while nicknames used in level 2, including by boarder RBridges, must be unique across the TRILL campus. Working Group Summary This document was adopted by the TRILL Working Group but that working group was dissolved before the document was progressed. The WG designed two approaches (unique nickname and an aggregated nickname) and documented these in RFC8243. The aggregated approach has discussed these improvements, but implementation "proof of concepts" were considered useful prior to standardization. Document Quality This document is of good quality. Document Shepherd: Susan Hares (past TRILL co-chair + shepherd) Responsible AD:Martin Vigoureux (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. The shepherd review the document for design that resolved many of the issue brought up in the TRILL WG discussions. Four problems were considered in the TRILL WG: 1) appropriate multicast and broadcast distribution, 2) re-use of nicknames within an L1, 3) bridge/routers that handle multiple areas, 4) load balancing of traffic between TRILL Area border routers The text of this draft solves all these problems. See the shepherd's review at: https://mailarchive.ietf.org/arch/msg/trill/f9SAPaA2wg-1G4W_tGVsQBdiPV4/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This draft stands on the shoulders of lengthy discussions and proposals within the TRILL working group prior to its closure. I appreciate the authors completing this work. LSR flexible algorithms work is rediscovering all of these issues as it decides how to handle multiple algorithms. As far as the shepherd can tell, LSR has not detect any new issues. (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 such additional review is needed. This draft has received two RTGDIR reviews (early and IETF Last Call), a SECDIR review, a GENART review, an AD review, and been through IETF Last Call. It just missed the last document flow through TRILL. (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. Mingui Zhang https://mailarchive.ietf.org/arch/msg/trill/SWI-m8R3tOyvwHfC0DfLkKJGN0E/ Donald Eastlake https://mailarchive.ietf.org/arch/msg/trill/i0vUpVG94cpjyaqdduH6bqXS_Sw/ Radia Perlman https://mailarchive.ietf.org/arch/msg/trill/sUfbC8PPJ9Okx808cute-Jo7aak/ Margaret Cullen https://mailarchive.ietf.org/arch/msg/trill/zvGHPJvdlRElSwezWH46GicH0Vw/ Honjun Zhai https://mailarchive.ietf.org/arch/msg/trill/MQZ1RAihrdIbPiEIpO_Bvph7-1I/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. Yes, https://datatracker.ietf.org/ipr/2587/ has been filed. There were no objections to the disclosure. The WG made an early decisions and repeated decisions to push this technology with IPR to get traction in the market place. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There was a good consensus in the TRILL community for this draft. (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 are no nits other than some some values suggested to IANA in square brackets that are incorrectly thought to be possible references by the nits checker. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No such formal review is required for this document. (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? All references are to RFCs except for one reference to the ISO/IEC IS-IS standard. (15) Are there downward normative references references (see RFC 3967)? There are no downward normative references in this document. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? This document does not change the status of any other RFC. (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. This document only requires the assignment of two new values in one already existing registry as documented in the IANA Considerations section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document does not create any new IANA registries. (19) Describe reviews and automated checks performed to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. There are no such formal languages used in this document. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? There is no YANG in this document. |
2021-07-08
|
13 | Susan Hares | (1) What type of RFC: Proposed standard a) Why is this the proper type of RFC? adds 2 TLVs to TRILLs APPsub-TLV. Must be standard … (1) What type of RFC: Proposed standard a) Why is this the proper type of RFC? adds 2 TLVs to TRILLs APPsub-TLV. Must be standard to add these TLVs. Is this type of RFC indicated in the title page header? This draft is aimed at Proposed Standard as it specifies an aggregated nickname protocol for multilevel TRILL. (Informational RFC 8243 describes the difference between aggregated and unique nickname protocols for multilevel TRILL. RFC 8397 is the Proposed Standard for unique nickname multilevel TRILL and this draft is intended to become the Proposed Standard for aggregated nickname multilevel 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 a protocol for multilevel TRILL using a form of aggregated nicknames where level 1 areas are identified by the set of border RBridges connecting them to level 2. Nicknames can be re-used in multiple level 1 areas of this type while nicknames used in level 2, including by boarder RBridges, must be unique across the TRILL campus. Working Group Summary This document was adopted by the TRILL Working Group but that working group was dissolved before the document was progressed. The WG designed two approaches (unique nickname and an aggregated nickname) and documented these in RFC8243. The aggregated approach has discussed these improvements, but implementation "proof of concepts" were considered useful prior to standardization. Document Quality This document is of good quality. Document Shepherd: Susan Hares (past TRILL co-chair + shepherd) Responsible AD:Martin Vigoureux (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. The shepherd review the document for design that resolved many of the issue brought up in the TRILL WG discussions. Four problems were considered in the TRILL WG: 1) appropriate multicast and broadcast distribution, 2) re-use of nicknames within an L1, 3) bridge/routers that handle multiple areas, 4) load balancing of traffic between TRILL Area border routers The text of this draft solves all these problems. See the shepherd's review at: https://mailarchive.ietf.org/arch/msg/trill/f9SAPaA2wg-1G4W_tGVsQBdiPV4/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This draft stands on the shoulders of lengthy discussions and proposals within the TRILL working group prior to its closure. I appreciate the authors completing this work. LSR flexible algorithms work is rediscovering all of these issues as it decides how to handle multiple algorithms. As far as the shepherd can tell, LSR has not detect any new issues. (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 such additional review is needed. This draft has received two RTGDIR reviews (early and IETF Last Call), a SECDIR review, a GENART review, an AD review, and been through IETF Last Call. It just missed the last document flow through TRILL. (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. Mingui Zhang https://mailarchive.ietf.org/arch/msg/trill/SWI-m8R3tOyvwHfC0DfLkKJGN0E/ Donald Eastlake https://mailarchive.ietf.org/arch/msg/trill/i0vUpVG94cpjyaqdduH6bqXS_Sw/ Radia Perlman https://mailarchive.ietf.org/arch/msg/trill/sUfbC8PPJ9Okx808cute-Jo7aak/ Margaret Cullen https://mailarchive.ietf.org/arch/msg/trill/zvGHPJvdlRElSwezWH46GicH0Vw/ Honjun Zhai https://mailarchive.ietf.org/arch/msg/trill/MQZ1RAihrdIbPiEIpO_Bvph7-1I/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. Yes, https://datatracker.ietf.org/ipr/2587/ has been filed. There were no objections to the disclosure. The WG made an early decisions and repeated decisions to push this technology with IPR to get traction in the market place. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There was a good consensus in the TRILL community for this draft. (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 are no nits other than some some values suggested to IANA in square brackets that are incorrectly thought to be possible references by the nits checker. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No such formal review is required for this document. (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? All references are to RFCs except for one reference to the ISO/IEC IS-IS standard. (15) Are there downward normative references references (see RFC 3967)? There are no downward normative references in this document. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? This document does not change the status of any other RFC. (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. This document only requires the assignment of two new values in one already existing registry as documented in the IANA Considerations section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document does not create any new IANA registries. (19) Describe reviews and automated checks performed to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. There are no such formal languages used in this document. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? There is no YANG in this document. |
2020-08-21
|
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Samuel Weiler. Sent review to list. |
2020-07-27
|
13 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-13.txt |
2020-07-27
|
13 | (System) | New version accepted (logged-in submitter: Donald Eastlake) |
2020-07-27
|
13 | Donald Eastlake | Uploaded new revision |
2020-07-09
|
12 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-12.txt |
2020-07-09
|
12 | (System) | New version approved |
2020-07-09
|
12 | (System) | Request for posting confirmation emailed to previous authors: Mingui Zhang , Margaret Cullen , Donald Eastlake , Hongjun Zhai , Radia Perlman |
2020-07-09
|
12 | Donald Eastlake | Uploaded new revision |
2020-07-05
|
11 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein. Submission of review completed at an earlier date. |
2020-07-03
|
11 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein. |
2020-06-26
|
11 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-11.txt |
2020-06-26
|
11 | (System) | New version approved |
2020-06-26
|
11 | (System) | Request for posting confirmation emailed to previous authors: Margaret Cullen , Hongjun Zhai , Mingui Zhang , Radia Perlman , Donald Eastlake |
2020-06-26
|
11 | Donald Eastlake | Uploaded new revision |
2020-06-11
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-06-08
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-08
|
10 | Donald Eastlake | New version available: draft-ietf-trill-multilevel-single-nickname-10.txt |
2020-06-08
|
10 | (System) | New version approved |
2020-06-08
|
10 | (System) | Request for posting confirmation emailed to previous authors: Hongjun Zhai , Donald Eastlake , Margaret Cullen , Radia Perlman , Mingui Zhang |
2020-06-08
|
10 | Donald Eastlake | Uploaded new revision |
2020-06-01
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-06-01
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-trill-multilevel-single-nickname-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-trill-multilevel-single-nickname-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at: https://www.iana.org/assignments/trill-parameters/ two, new registrations are to be made as follows from the range greater than 255. These are only usable in contexts permitting a type larger than one byte, such as extended TLVs as defined by [RFC7356]. Type: [ TBD-at-Registration ] Name: L1-BORDER-RBRIDGE Reference: [ RFC-to-be ] Type: [ TBD-at-Registration ] Name: L1-BORDER-RB-GROUP Reference: [ RFC-to-be ] IANA understands that the authors suggest the values 256 and 257 for these two, new registrations. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-05-21
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Samuel Weiler |
2020-05-21
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Samuel Weiler |
2020-05-20
|
09 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list. |
2020-05-19
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-05-19
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-05-18
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Sasha Vainshtein |
2020-05-18
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Sasha Vainshtein |
2020-05-14
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-05-14
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-05-14
|
09 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2020-05-14
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-05-14
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-06-11): From: The IESG To: IETF-Announce CC: draft-ietf-trill-multilevel-single-nickname@ietf.org, martin.vigoureux@nokia.com, shares@ndzh.com Reply-To: last-call@ietf.org Sender: Subject: … The following Last Call announcement was sent out (ends 2020-06-11): From: The IESG To: IETF-Announce CC: draft-ietf-trill-multilevel-single-nickname@ietf.org, martin.vigoureux@nokia.com, shares@ndzh.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel' 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 last-call@ietf.org mailing lists by 2020-06-11. 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 A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, the area border RBridge uses a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2587/ |
2020-05-14
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-05-14
|
09 | Martin Vigoureux | Last call was requested |
2020-05-14
|
09 | Martin Vigoureux | Ballot approval text was generated |
2020-05-14
|
09 | Martin Vigoureux | Ballot writeup was generated |
2020-05-14
|
09 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2020-05-14
|
09 | Martin Vigoureux | Last call announcement was generated |
2020-02-27
|
09 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2019-07-03
|
09 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-09.txt |
2019-07-03
|
09 | (System) | New version approved |
2019-07-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2019-07-03
|
09 | Mingui Zhang | Uploaded new revision |
2019-06-24
|
08 | Martin Vigoureux | Assigned to Routing Area |
2019-06-24
|
08 | Martin Vigoureux | IESG process started in state Publication Requested |
2019-06-24
|
08 | (System) | Earlier history may be found in the Comment Log for /doc/draft-zhang-trill-multilevel-single-nickname/ |
2019-06-24
|
08 | Martin Vigoureux | Shepherding AD changed to Martin Vigoureux |
2019-06-24
|
08 | Martin Vigoureux | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-03-10
|
08 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-08.txt |
2019-03-10
|
08 | (System) | New version approved |
2019-03-10
|
08 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2019-03-10
|
08 | Mingui Zhang | Uploaded new revision |
2019-01-16
|
07 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-07.txt |
2019-01-16
|
07 | (System) | New version approved |
2019-01-16
|
07 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2019-01-16
|
07 | Mingui Zhang | Uploaded new revision |
2018-07-18
|
06 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-06.txt |
2018-07-18
|
06 | (System) | New version approved |
2018-07-18
|
06 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2018-07-18
|
06 | Mingui Zhang | Uploaded new revision |
2018-03-19
|
05 | Cindy Morgan | Changed field(s): group,abstract |
2018-01-28
|
05 | Donald Eastlake | IETF WG state changed to In WG Last Call from WG Document |
2018-01-22
|
05 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-05.txt |
2018-01-22
|
05 | (System) | New version approved |
2018-01-22
|
05 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2018-01-22
|
05 | Mingui Zhang | Uploaded new revision |
2017-10-27
|
04 | Donald Eastlake | Changed consensus to Yes from Unknown |
2017-10-27
|
04 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2017-07-31
|
04 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-04.txt |
2017-07-31
|
04 | (System) | New version approved |
2017-07-31
|
04 | (System) | Request for posting confirmation emailed to previous authors: Radia Perlman , Margaret Cullen , Hongjun Zhai , Donald Eastlake , Mingui Zhang |
2017-07-31
|
04 | Mingui Zhang | Uploaded new revision |
2017-02-06
|
03 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-03.txt |
2017-02-06
|
03 | (System) | New version approved |
2017-02-06
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Hongjun Zhai" , "Radia Perlman" , trill-chairs@ietf.org, "Donald Eastlake" , "Mingui Zhang" , "Margaret Cullen" |
2017-02-06
|
03 | Mingui Zhang | Uploaded new revision |
2016-08-11
|
02 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-02.txt |
2016-05-20
|
01 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein. |
2016-05-05
|
01 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Sasha Vainshtein |
2016-05-05
|
01 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Sasha Vainshtein |
2016-04-07
|
01 | Jonathan Hardwick | Closed request for Early review by RTGDIR with state 'No Response' |
2016-02-15
|
01 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-01.txt |
2015-10-14
|
00 | (System) | Notify list changed from "Susan Hares" to (None) |
2015-09-18
|
00 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Brian Weis |
2015-09-18
|
00 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Brian Weis |
2015-09-01
|
00 | Donald Eastlake | Notification list changed to "Susan Hares" <shares@ndzh.com> |
2015-09-01
|
00 | Donald Eastlake | Document shepherd changed to Susan Hares |
2015-09-01
|
00 | Donald Eastlake | This document now replaces draft-zhang-trill-multilevel-single-nickname instead of None |
2015-08-19
|
00 | Mingui Zhang | New version available: draft-ietf-trill-multilevel-single-nickname-00.txt |