Subject: [Last-Call] Genart last call review of draft-ietf-trill-multilevel-single-nickname-09

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Wed, 20 May 2020 01:36:52 -0700

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?

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?

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

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.

Nits/editorial comments:

1. Need to correct grammar/syntax problems
2. Inconsistent writing Level 1 / Level-1 ; Level 2 / Level-2
3. Section 1: s/nicknames in L2 MUST be unique/nicknames in L2 areas MUST be
unique/ 4. It would be useful to add Level to the terminology 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/ 6. Section 3.2:
s/ESADI protocol/ESADI protocol [RFC7357]/

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Fri, 22 May 2020 06:47:58 +0000

Hi Dan,

Thanks for your review. Please see authors' comments in-line below.

Best regards,
Mingui

--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M：0033763471939
E：[email-masked]
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei

> -----Original Message-----
> From: Dan Romascanu via Datatracker [mailto:[email-masked]]
> Sent: Wednesday, May 20, 2020 10:37 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Genart last call review of draft-ietf-trill-multilevel-single-nickname-09
> 
> Reviewer: Dan Romascanu
> 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.
> 
> 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

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.

> configuration of the network. What happens when an Rbridge is added at the

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.

> necessary for example? If these are addressed in other documents a reference

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:

Authors> OK. Will be inserted.

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 22 May 2020 10:33:08 +0300

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) <[email-masked]>
wrote:

> > Subject: Genart last call review of
> draft-ietf-trill-multilevel-single-nickname-09
> >
> > Reviewer: Dan Romascanu
> Review
> 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:
> >
> 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.
>
> >
> 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.
>
> >
> 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.
> 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:
> >
> 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:

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Fri, 22 May 2020 09:29:53 +0000

Hi Dan,

This is a good suggestion. The clarifying text will be added in before the publication.

Thanks,
Mingui
--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M：0033763471939
E：[email-masked]<mailto:[email-masked]>
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei

From: Dan Romascanu [mailto:[email-masked]]
Sent: Friday, May 22, 2020 9:33 AM
To: Zhangmingui (Martin) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-trill-multilevel-single-nickname-09

Hi,

Regards,

Dan

On Fri, May 22, 2020 at 9:47 AM Zhangmingui (Martin) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dan,

Best regards,
Mingui

--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M：0033763471939
E：[email-masked]<mailto:[email-masked]>
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei

> From: Dan Romascanu via Datatracker [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>