RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

"Zhangmingui (Martin)" <zhangmingui@huawei.com> Thu, 09 July 2020 18:53 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA653A0E18; Thu, 9 Jul 2020 11:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level:
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_YOUR_INFO=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6oNAaXa-RLT; Thu, 9 Jul 2020 11:52:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC413A0E24; Thu, 9 Jul 2020 11:52:56 -0700 (PDT)
Received: from lhreml715-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9C532BA54F20394E0BDB; Thu, 9 Jul 2020 19:52:52 +0100 (IST)
Received: from fraeml710-chm.china.huawei.com (10.206.15.59) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 9 Jul 2020 19:52:52 +0100
Received: from fraeml711-chm.china.huawei.com (10.206.15.60) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 9 Jul 2020 20:52:51 +0200
Received: from fraeml711-chm.china.huawei.com ([10.206.15.60]) by fraeml711-chm.china.huawei.com ([10.206.15.60]) with mapi id 15.01.1913.007; Thu, 9 Jul 2020 20:52:51 +0200
From: "Zhangmingui (Martin)" <zhangmingui@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "Yemin (Amy)" <amy.yemin@huawei.com>, "draft-ietf-trill-multilevel-single-nickname.all@ietf.org" <draft-ietf-trill-multilevel-single-nickname.all@ietf.org>
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11
Thread-Topic: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11
Thread-Index: AdZQYG1NzKJfk7rhTrm8SEI3Mp5zPACf204gAB2ZDQMAAXct8gBxuZZwAAQHhxAAOxi7AA==
Date: Thu, 09 Jul 2020 18:52:51 +0000
Message-ID: <b9c7f467c325464885640d01945f465e@huawei.com>
References: <AM0PR03MB4499EF7E78EFF2351A7A060E9D6A0@AM0PR03MB4499.eurprd03.prod.outlook.com>, <18d08245fd854c0baaaddbf2966cadfa@huawei.com>, <AM0PR03MB44990EECEB48C26D6E31A01A9D690@AM0PR03MB4499.eurprd03.prod.outlook.com> <AM0PR03MB449952AE0122342B1C84E7779D690@AM0PR03MB4499.eurprd03.prod.outlook.com> <8be8a754ac3d4189bede66adb303c93e@huawei.com> <AM0PR03MB4499BCB269EB74F03A8133849D670@AM0PR03MB4499.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB4499BCB269EB74F03A8133849D670@AM0PR03MB4499.eurprd03.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.64.4]
Content-Type: multipart/alternative; boundary="_000_b9c7f467c325464885640d01945f465ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/DsKtWSd_5HppLu4k5DcebcidFiw>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 18:53:03 -0000

Hi Alexander,

Please refer to the responses inline below with <Authors3>.

All changes have been incorporated in the version 12.

Thanks
Mingui

--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M:0033763471939
E:zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person to whom it is addressed. If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by HUAWEI.
HUAWEI Technologies France SASU (“HUAWEI”) respects your privacy and is committed to the protection of your personal data. Your personal data included in this email and/or its attachments may be processed by HUAWEI. In compliance with Regulation (EU) 2016/679 (GDPR) and French data protection law of 6 January 1978 as amended, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing by sending us your request via the form available at https://www.huawei.com/fr/personal-data-request or a letter to the following address: HUAWEI Technologies France, Privacy Officer, 18 quai point du jour, 92100 Boulogne-Billancourt, France. To know more about how HUAWEI processes your personal data, please contact us<https://www.huawei.com/fr/personal-data-request/>.

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@rbbn.com]
Sent: Wednesday, July 8, 2020 4:36 PM
To: Zhangmingui (Martin) <zhangmingui@huawei.com>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; rtgwg@ietf.org; Yemin (Amy) <amy.yemin@huawei.com>; draft-ietf-trill-multilevel-single-nickname.all@ietf.org
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Mingui,
Lots of thanks for a prompt and detailed response.

Please see a few additional comments inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: rtgwg <rtgwg-bounces@ietf.org<mailto:rtgwg-bounces@ietf.org>> On Behalf Of Zhangmingui (Martin)
Sent: Wednesday, July 8, 2020 4:43 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>; draft-ietf-trill-multilevel-single-nickname.all@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname.all@ietf.org>
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Thanks for the further comments. Please refer to the responses inline below with prefix <Authors2>.
The suggested changes will be incorporated in the next updated version.

Best regards,
Martin
--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M:0033763471939
E:zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person to whom it is addressed. If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by HUAWEI.
HUAWEI Technologies France SASU (“HUAWEI”) respects your privacy and is committed to the protection of your personal data. Your personal data included in this email and/or its attachments may be processed by HUAWEI. In compliance with Regulation (EU) 2016/679 (GDPR) and French data protection law of 6 January 1978 as amended, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing by sending us your request via the form available at https://www.huawei.com/fr/personal-data-request<https://clicktime.symantec.com/36USaGsPQpHygADngGkBEdN6H2?u=https%3A%2F%2Fwww.huawei.com%2Ffr%2Fpersonal-data-request> or a letter to the following address: HUAWEI Technologies France, Privacy Officer, 18 quai point du jour, 92100 Boulogne-Billancourt, France. To know more about how HUAWEI processes your personal data, please contact us<https://clicktime.symantec.com/32VzqA6s7TqmVQECV6WEcsy6H2?u=https%3A%2F%2Fwww.huawei.com%2Ffr%2Fpersonal-data-request%2F>.
From: Alexander Vainshtein [mailto:Alexander.Vainshtein@rbbn.com]
Sent: Monday, July 6, 2020 11:02 AM
To: Zhangmingui (Martin) <zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-trill-multilevel-single-nickname.all@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname.all@ietf.org>; Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui and all,
Apologies -this has been inadvertently sent without any comments.

Lots of thanks for a prompt and very encouraging response.

Your answers and proposed updates look very promising, and I think that it would not be too difficult to resolve remaining open issues.

Please see some specific comments inline below marked [[Sasha]].


Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3Nu5o6hkh1yH237tAmTbTmi6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

________________________________
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: Monday, July 6, 2020, 08:31
To: Zhangmingui (Martin); Alexander Vainshtein; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-trill-multilevel-single-nickname.all@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname.all@ietf.org>; Yemin (Amy); rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui,

Get Outlook for Android<https://clicktime.symantec.com/3AQVSdZnv9Rf9G47J4kEk1m6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

________________________________
From: rtg-dir <rtg-dir-bounces@ietf.org<mailto:rtg-dir-bounces@ietf.org>> on behalf of Zhangmingui (Martin) <zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>>
Sent: Sunday, July 5, 2020, 21:11
To: Alexander Vainshtein; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-trill-multilevel-single-nickname.all@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname.all@ietf.org>; Yemin (Amy); rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Please refer to our responses prefixed with <Authors>.

Thanks,
Mingui
--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M:0033763471939
E:zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>
华为2012实验室-巴黎研究所数通实验室
DataCom’s Lab, 2012 Laboratories-Paris Research Center, Huawei
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person to whom it is addressed. If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by HUAWEI.
HUAWEI Technologies France SASU (“HUAWEI”) respects your privacy and is committed to the protection of your personal data. Your personal data included in this email and/or its attachments may be processed by HUAWEI. In compliance with Regulation (EU) 2016/679 (GDPR) and French data protection law of 6 January 1978 as amended, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing by sending us your request via the form available at https://clicktime.symantec.com/396H3URsQm6PUD5garb5BGF6H2?u=https%3A%2F%2Fwww.huawei.com%2Ffr%2Fpersonal-data-request or a letter to the following address: HUAWEI Technologies France, Privacy Officer, 18 quai point du jour, 92100 Boulogne-Billancourt, France. To know more about how HUAWEI processes your personal data, please contact us.

On Fri, Jul 3, 2020 at 12:19 PM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>> wrote:
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> https://clicktime.symantec.com/3KUaokLoA25q8MsVZwHpkr96H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
>
> Document:  draft-ietf-trill--multilevel-single-nickname-11
> Reviewer: Alexander (“Sasha”) Vainshtein Review Date: 02-Jul-20 IETF
> LC End Date: 07-Jul-20 Intended Status: Proposed Standard
>
> Summary:
>
> I have some minor concerns about this document that I think should be resolved before publication.

<Authors> Thanks for your review and comments.

> Comments:
>
> I have done an early review of the -01 version of this draft more than 4 years ago. I have to admit that my knowledge of TRILL has not improved since then, so that my comments should be taken with a grain of salt by the ADs.
>
>
> I have tried, to the best of my ability, to track the changes that have happened to the draft and around it as part of my review. One of the changes that I have noticed is publication of RFC 8423 (Informational) and RFC 8397 (Standards Track) that have been just Work in Progress at the time of my previous review.  The former describes the motivation for multi-level TRILL and identifies two alternative approaches for it while the latter defines the necessary protocol extensions for one of these approaches - “unique nickname”.

<Authors> I think you mean RFC 8243, not 8423.
[[Sasha]] Oops! Lots of thanks for catching the typo.

> One of the things that, from my POV, did not really change is readability of the draft: it has not been easy reading then, and remains difficult to read for the people who, like me, are not TRILL experts. I am not sure this can be much improved, however.

<Authors> If there are suggestions for improving readability, we would be happy to consider them.
-[[Sasha]] Unfortunately I do not have any specific suggestions.

> The draft has been at its -09 revision when I have been selected as the reviewer, and has advanced to -11 revision while under review:
> ·         the -10 revision addresses some of the issues in the Gen-Art review
> ·         the -11 revision has addressed some of the issues I have raised in private discussion with the authors. I did not mention the issues that I have raised vs. the -10 revision. I have skipped the issues that have been addressed in the -11 version from this review.
>
>
> I did not check the draft for nits. Not being a native English speaker I also did not check for the grammar.
>
>
> I would like to thank the authors, and especially Mingui, for cooperation and patience.

<Authors> You are welcome.

> Major Issues:
>
> None found
>
>
> Minor Issues:
>
> 1.       The draft updates the base TRILL spec by changing the forwarding rules in the border RBridges, but this is not reflected in the metadata and not made sufficiently clear in the text:
> a.       I have noticed that 8397 is not marked as updating the base TRILL spec. I have been told that the ADs feeling at the time of publication has been that it simply extends the base spec and therefore no metadata markings are necessary
> b.       From my POV, even if 8397 may be considered as just extending the base TRILL spec, this draft – that changes the forwarding rules specified in the base spec -  definitely goes beyond that
> c.       AFAIK  it is customary in similar cases to explicitly state in the text (and not just in the metadata) something like “this draft updates RFC xxx by  ...”. The sentence the authors have added to the Introduction in -11 is not sufficiently clear from my POV

<Authors> We are happy to do whatever the ADs would like about this. If the ADs/IESG would like us to add an "Updates 6325" to the first page header and add a sentence like "This draft updates RFC 6325." at the end of the Abstract and in the Introduction, we would be happy to do that.
[[Sasha]] Sounds good. So the ball is in the ADs court on that.

> 2.       As mentioned above, this draft changes the TRILL forwarding rules by requesting the Border RBridges to replace ingress and/or egress nickname when  a TRILL data packets traverses TRILL L2 area.
>
> a.       My knowledge of TRILLL OAM toolbox is non-existent, but if it contains something resembling “ping” and/or “traceroute”, change of ingress and egress nicknames could potentially hamper such tools
> b.       IMHO and FWIW, impact of the draft on the TRILL OAM tools should be at least discussed in the draft

<Authors> TRILL OAM messages are specified in RFC 7455. The destination is specified not just by a destination RBridge nickname but by a destination MAC (the Inner.MacDA). So, by using a MAC address belonging to the destination RBridge, a TRILL OAM message will be forwarded through the multilevel single nickname TRILL campus. Text could be added about this.
[[Sasha]] Adding such text would definitely help, especially as my attempt to read and understand 7455 have not yielded sufficient understanding of the TRILL OAM principles. One thing that should be clarified in this text, IMHO, is sending an inline response to a TRILL OAM request message (if relevant).
<Authors2> Yes, it is applicable for both request and response messages.
[[Sasha]] Please consider adding short text (e.g., at the end of Section 3?) explicitly specifying that TRILL OAM mechanisms are not hampered by the changes in the data plane because all OAM messages carry also Destination MAC addresses.
<Authors3>  The text has been added in Section 8.

> 3.       I still have doubts regarding the problem this draft tries to solve and its relevance
>
> a.       To the best of my understanding, the motivation for multi-level TRILL are scale and churn prevention. Both these issues are addressed (to some extent) by 8397 with the scale, in theory, reaching 64K of RBridges in a single multi-level campus
> b.       Even simply saying that “this draft answers the problem of what  is the best you can do on scaling if you ...allow change in the data plane processing at border RBridges between Level 1 and Level 2”  would help the readers to understand the problem this draft tries to solve IMHO
> c.       Some input on the real and expected scale of TRILL campuses would also help the readers to understand whether the solution proposed by the draft is or is not relevant for them.

<Authors> Potential TRILL scaling demand is approximately the same as IP based data center scaling. Furthermore, for any particular size in terms of the number of TRILL RBridges, more than one nickname will be required per RBridge if the active-active end-station technique in RFC 7781 is used as discussed in Section 1.2.5 of RFC 8243.
[[Sasha]] Can you please add some text on that, especially regarding Avtive-Active end-station technique and its relationship with multi-level TRILL. I did not notice anything about 7781 in the the draft.
<Authors2> We’d better not mention the “active-active” concept in this document since it might divert readers attention to an irrelevant topic. In the context of Section 1.2.5 of RFC8243, it is actually about the concept of “pseudo-nickname“ instead, which allows one RBridge to consume multiple nickname.
[[Sasha]] Please consider adding some text on the potential TRILL scale demand (if this is explained in 8243, a reference should suffice).
<Authors3>  Yes, RFC8243 is referred.

> 4.       I could  not understand from the  discussion of discovery in Section 5 of -011 whether such “positive” events as recovery of a link/node whose failure has caused partitioning of a L1 area, or addition of a new Border Rbridge between L2 and L1 areas would result in a relatively long traffic hit due to re-discovery process or not:
>
> a.       I do not expect such positive events to have prolonged impact on traffic with the solution defined in 8397 (can be wrong, of course)
> b.       An explicit statement, one way or another, regarding prolonged traffic hit in the case of positive events would be useful IMHO

<Authors> The merger of L1 areas under this draft is about the same as the merger of two single-level TRILL campuses. How long is "prolonged"?
<Authors> Going to multi-level speeds up routing convergence enormously (see Sections 1.2.1 and 1.2.3 of RFC 8243). RBridges are identified in the LSDB by router ID, not nickname. So, while nicknames might change and have to settle after a merger this happens in parallel with least-cost-path settling and the like. It is the case that if nicknames were duplicated between the areas that are merging, some traffic might be misdelivered while the combined area is unconverged.
<Authors> This is called out in the Security Considerations section. In summary, we do not think that such merger events would cause "prolonged" impact on traffic.
[Sasha]] I think that the problematic positive event is a new (or previously failed) Border RBridge coming up. This looks to me as different from the merger of two L1 domains in IS-IS in general and specifically in TRILL with 8397. Any details on this scenario would be most helpful.
<Authors2> This is a general topology change event and had been addressed by adding the text in Section 5 in version 11.
[[Sasha]] OK


> 5.       Section 8 discusses the situation when one (or more) of the Border RBridges of a certain L1 area supports only 8397, while one (or more) Border RBridges of the same area support this draft.
>
> a.       The draft says that in this case all Border RBridges of the L1 area in question must fall back to 8397.
> b.       This seems to suggest  that all RBridges that implement this draft SHOULD (or possibly even MUST) also implement 8397; otherwise they would not to be able to fall back to the 8397 in the case of mixed configuration as required
> c.       If this understanding is correct, I think that it has to be made explicit

<Authors> We think that saying they MUST fall back to RFC 8397 behavior implies that MUST support such behavior.
[[Sasha]] IMHO this is a very important point with multiple implications and it should be stated up front. I agree that it can be implied from the current text (well, I have been able to guess it in my review  in spite of my definitely limited understanding of TRILL😉), but it can also easily be lost on the reader.
<Authors2> We will address it by saying “…MUST support [RFC8397] and fall back to ...” to make it explicit.
[[Sasha]] I am not sure this would be enough. My gut feeling is that Section 8 of the draft may require some editing because it (at least implicitly) seems to treat support of 8397 and support of this draft as mutually exclusive (it uses such expressions as “in contrast”) while in fact support of this draft is conditional on support of 8397. Or did I miss something?

<Authors3>  As explained in the introduction, “unique” and “aggregated” are two  different approaches (expressed in contrast) to achieve TRILL multilevel. Meanwhile, the “aggregated” approach has the additional capability of allowing nicknames to be reused inside different areas. That is why the “aggregated” approach scales better.


> 6.       The text in Section 8 that says that  “duplicated {MAC, Data Label} across these areas ought not occur ” looks as a requirement to me, but neither MUST nor SHOULD are used. And it is not clear to me what happens if this requirement is violated.

<Authors> It is an axiom of L2 networks that the same end station MAC and data label SHOULD not occur on more than one end station. If you violate that, it probably doesn't matter much which instance of the {MAC, Data Label} receives some frame being forwarded by TRILL. There are some tie breaking rules in Section 4.2.6 of RFC 6325. If a border RBridge is connected to multiple L1 areas and uses the same nickname to represent itself in L2 for those areas, and it receives a frame from L2 for a {MAC, Data Label} that occurs in more than one of those L1 areas, it is about the same situation as a single level RBridge that receives a frame with a {MAC, Data Label} that is duplicated in its TRILL campus. Possibly we could add some text here referring to Section 4.2.6 of RFC 6325.
[Sasha]] This would be quite useful IMHO.
<Authors2> Right. Incorporated.


> Hopefully, these comments will be useful.
>
> Regards,
> Sasha
>
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>
> ________________________________
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
> ________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________