Re: [Gen-art] Genart last call review of draft-ietf-trill-multilevel-single-nickname-09

[Dan Romascanu <[e-mail]>]

Hi,

Thank you for your answers and clarifications. They look fine to me. One
recommendation, it would be to clarify in text, in the introduction, what
you explained concerning the one major issue that I raised:

> 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.

Regards,

Dan


On Fri, May 22, 2020 at 9:47 AM Zhangmingui (Martin) <[e-mail]>
wrote:

> Hi Dan,
>
> Thanks for your review. Please see authors' comments in-line below.
>
> Best regards,
> Mingui
>
> --------------------------------------------
> Dr. Zhang Mingui (Martin) 张民贵
> M：0033763471939
> E：[e-mail]
> 华为2012实验室-巴黎研究所数通实验室
> DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei
>
> > -----Original Message-----
> > From: Dan Romascanu via Datatracker [mailto:[e-mail]]
> > Sent: Wednesday, May 20, 2020 10:37 AM
> > To: [e-mail]
> > Cc: [e-mail];
> [e-mail];
> > [e-mail]
> > 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.
>