Hi Dan, Thanks for your review. Please see authors' comments in-line below.
Best regards, Mingui -------------------------------------------- Dr. Zhang Mingui (Martin) 张民贵 M：0033763471939 E：zhangmin...@huawei.com 华为2012实验室-巴黎研究所数通实验室 DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei > -----Original Message----- > From: Dan Romascanu via Datatracker [mailto:nore...@ietf.org] > Sent: Wednesday, May 20, 2020 10:37 AM > To: gen-art@ietf.org > Cc: draft-ietf-trill-multilevel-single-nickname....@ietf.org; > last-c...@ietf.org; > droma...@gmail.com > Subject: Genart last call review of > draft-ietf-trill-multilevel-single-nickname-09 > > Reviewer: Dan Romascanu > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-trill-multilevel-single-nickname-09 > Reviewer: Dan Romascanu > Review Date: 2020-05-20 > IETF LC End Date: 2020-06-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This is not easy reading for non-TRILL experts, but I can guess that this > document > is useful and clear enough for the people working in the field. The document > is > READY but there are a few issues that seem to be in need of being clarified > and > addressed if necessary. > > Major issues: > > 1. Something is not clear to me about the Intended Status of this document. > It is > supposed to solve a problem introduced or left unclear by RFC 8243, but that > document is Informational. Why is then the Intended Status Standards Track? Authors> Informational RFC 8243 is an educational document to explain multilevel TRILL and list possible concerns. It does not to specify a protocol; however, it classifies protocol solutions into two flavors: unique nickname and aggregated nickname. RFC 8397 is the standards track document specifying a "unique nickname" flavor of TRILL multilevel. This document is standards track because it specifies "an aggregated nickname" flavor TRILL multilevel protocol. RFC 8243 makes the case that, while unique nickname multilevel solutions are simpler, aggregated nickname solutions scale better. > > Minor issues: > > 1. All the examples in the text are static. Changes however happen in the > configuration of the network. What happens when an Rbridge is added at the > border of an L1 area? Authors> If an RBridge which is configured to be a border RBridge is attached at the border of an L1 area, it will follow Sections 5.1 and 5.2 to discover other border RBridges and to be discovered by border RBridges, through exchanging LSPs that carry the TLVs as specified. > > 2. Section 6 'RB1 SHOULD use a single area nickname for all these areas.' - > why is > this only a SHOULD? It seems to me that in any exception case the scheme > breaks Authors> Say RB1 is a boarder RBridge between L2 and two difference L1 areas, L1 area X and L1 area Y. RB1 could use the same single nickname, say N1, in L2, L1-X, and L1-Y. Or it could announce N1 for itself in L1-X and a different nickname N2 in L1-Y. If it did that it would have to announce in L2 that it was holding both N1 and N2 (the base TRILL protocol, RFC 6325, permits an RBridge to hold multiple nicknames). However, the purpose of this TRILL multilevel single nickname protocol is to improve scaling by conserving nicknames, so RB1 SHOULD use a single nickname. > > 3. I am used with documents in the routing area to include Operational and > Manageability considerations. These are missing here, with the exception of > backwards compatibility which is addressed. Are any configuration operations > necessary for example? If these are addressed in other documents a reference > would be useful. Authors> Operations shall be discussed in the future when there is some operational experience about TRILL multilevel. While for manageability, a new section can be added after the current Section 7. 8. Manageability Considerations If an L1 Border RBridge Nickname is configured, the multilevel feature as specified in this document is turned on. If an RBridge is configured with an L1 Border RBridge Nickname for any a Level 1 area, this nickname will be used across the Level 2 area. This L1 Border RBridge Nickname cannot be reused by any other Level 1 area except the Level 1 area for which this L1 Border RBridge Nickname is configured. Other than the manageability considerations as specified above, manageability specifications specified per RFC 6325 still apply. > > Nits/editorial comments: > > 1. Need to correct grammar/syntax problems 2. Inconsistent writing Level 1 / > Level-1 ; Level 2 / Level-2 Authors> Thanks for pointing out. Will update the document to use Level 1, Level 2 consistently. > 3. Section 1: s/nicknames in L2 MUST be > unique/nicknames in L2 areas MUST be unique/ Authors> In IS-IS/TRILL there is only one L2 area so the update will be conducted as follows. s/nicknames in L2 MUST be unique/nicknames in the L2 area MUST be unique/ > 4. It would be useful to add Level > to the terminology Authors> OK. We can add the following terminology. Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 for inter-area. Routing information is exchanged between Level 1 RBridges within the same Level 1 area, and Level 2 RBridges can only form relationships and exchange information with other Level 2 RBridges. > 5. Section 3.1: > s/D's location is learned by the relevant TRILL switches already/D's location > has > been learned by the relevant TRILL switches already/ Authors> Will be updated as such. > 6. Section 3.2: > s/ESADI protocol/ESADI protocol [RFC7357]/ Authors> OK. Will be inserted. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
