Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Sun, 5 Jul 2020 18:11:25 +0000

Hi Alexander,

Please refer to our responses prefixed with <Authors>.

Thanks,
Mingui
--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M：0033763471939
E：[email-masked]
华为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. 

On Fri, Jul 3, 2020 at 12:19 PM Alexander Vainshtein <[email-masked]> 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 
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> 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.

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

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

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

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

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

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

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

> Hopefully, these comments will be useful.
>
> Regards,
> Sasha
>
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   [email-masked]
> ________________________________
> 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.
> ________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 3 Jul 2020 15:57:34 +0000

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 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

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:

Comments:

Major Issues:
None found

Minor Issues:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 6 Jul 2020 05:31:16 +0000

Mingui,

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: rtg-dir <[email-masked]> on behalf of Zhangmingui (Martin) <[email-masked]>
Sent: Sunday, July 5, 2020, 21:11
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; Yemin (Amy); [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Thanks,
Mingui
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 <[email-masked]> wrote:
> https://clicktime.symantec.com/3KUaokLoA25q8MsVZwHpkr96H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 6 Jul 2020 09:01:45 +0000

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

________________________________
From: Alexander Vainshtein <[email-masked]>
Sent: Monday, July 6, 2020, 08:31
To: Zhangmingui (Martin); Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; Yemin (Amy); [email-masked]
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>

Hi Alexander,

Thanks,
Mingui

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

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

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

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

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

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

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

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

> Email:   [email-masked]

___________________________________________________________________________

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

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Wed, 8 Jul 2020 13:43:07 +0000

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：[email-masked]<mailto:[email-masked]>
华为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:[email-masked]]
Sent: Monday, July 6, 2020 11:02 AM
To: Zhangmingui (Martin) <[email-masked]>; Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]
Subject: Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui and all,

Regards,
Sasha

________________________________
From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 6, 2020, 08:31
To: Zhangmingui (Martin); Alexander Vainshtein; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yemin (Amy); [email-masked]<mailto:[email-masked]>
Subject: Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui,

________________________________
From: rtg-dir <[email-masked]<mailto:[email-masked]>> on behalf of Zhangmingui (Martin) <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, July 5, 2020, 21:11
To: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yemin (Amy); [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Thanks,
Mingui
E：[email-masked]<mailto:[email-masked]>

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

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

<Authors2> This is a general topology change event and had been addressed by adding the text in Section 5 in version 11.

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

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

> Email:   [email-masked]<mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 8 Jul 2020 14:36:19 +0000

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

From: rtgwg <[email-masked]> On Behalf Of Zhangmingui (Martin)
Sent: Wednesday, July 8, 2020 4:43 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Best regards,
Martin
--------------------------------------------
Dr. Zhang Mingui (Martin) 张民贵
M：0033763471939
E：[email-masked]<mailto:[email-masked]>
华为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:[email-masked]]
Sent: Monday, July 6, 2020 11:02 AM
To: Zhangmingui (Martin) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui and all,

Regards,
Sasha

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

Mingui,

Hi Alexander,

Thanks,
Mingui

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

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

[[Sasha]] OK

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

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Thu, 9 Jul 2020 18:52:51 +0000

Hi Alexander,

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

All changes have been incorporated in the version 12.

Thanks
Mingui

Sent: Wednesday, July 8, 2020 4:36 PM

Hi Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Zhangmingui (Martin)
Sent: Wednesday, July 8, 2020 4:43 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Best regards,
Martin

Mingui and all,

Regards,
Sasha

Mingui,

Hi Alexander,

Thanks,
Mingui

<Authors3>  The text has been added in Section 8.

<Authors3>  Yes, RFC8243 is referred.

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jul 2020 15:07:56 +0000

Mingui,
Lots of thanks for posting the -12 version of the draft and apologies for a belated response.

The new version addresses most the issues raised in my original review.

There is, however, one point that, IMHO, requires additional clarification:

Section 8 says that:

-          The single-nickname multi-level TRILL mechanism is enabled in an RBridge that has L1 and L2 adjacencies and is configured with a L1 nickname

-          The unique-nickname multi-level TRILL mechanism defined in 8397 is enabled in an RBridge that has L1 and L2 adjacencies and is not configured with an L1 nickname

-          A multi-level RBridge that has been configured to use the single-nickname mechanism MUST also support 8397 and fall back to using this mechanism in certain conditions.

I assume that:

-          An RBridge that has both L1 and L2 adjacencies cannot be configured with just L1 nickname but without any L2 nickname

-          When a bridge that has been configured to use the single-nickname mechanism falls back to using unique-nickname mechanism it uses the L2 nickname with which it has been configured.
If these assumptions are correct, it would be useful, IMHO, to explicitly state that in the draft even if they may look obvious to TRILL experts.

I also think that an RBridge that has been configured to use the single nick-name mechanism but falls back to using the unique-nickname mechanism should notify the operator, say, by logging an appropriate message. Section 8 looks like the natural place to state that (if this is indeed the intention of the authors).

I have also detected a couple of additional nits in the first statement of Section 5:

OLD:
   The following topology change scenarios will trigger the discover
   processes as defined in Sections 5.1<https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname-12#section-5.1> and Section 5.2<https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname-12#section-5.2>:

PROPOSED:
   The following topology change scenarios will trigger the discovery
   processes as defined in Sections 5.1<https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname-12#section-5.1> and 5.2<https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname-12#section-5.2>:

Hopefully these comments will be useful.

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: rtg-dir <[email-masked]> On Behalf Of Zhangmingui (Martin)
Sent: Thursday, July 9, 2020 9:53 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Thanks
Mingui

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/32mCBPsssJSFigRuqYhJR2g6H2?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/3UyfGtmoHT34EG4ZXErcaBx6H2?u=https%3A%2F%2Fwww.huawei.com%2Ffr%2Fpersonal-data-request%2F>.

Hi Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Best regards,
Martin

Mingui and all,

Regards,
Sasha

Mingui,

Hi Alexander,

Thanks,
Mingui

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Thu, 16 Jul 2020 09:37:15 +0000

Hi Alexander,

Please take a look at the responses in-line below with <Authors>.

We will capture the changes in the next updated version.

Thanks,
Mingui

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, July 14, 2020 5:08 PM
To: Zhangmingui (Martin) <[email-masked]>; [email-masked]
Cc: [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui,

Section 8 says that:

<Authors> Correct.

-          The unique-nickname multi-level TRILL mechanism defined in 8397 is enabled in an RBridge that has L1 and L2 adjacencies and is not configured with an L1 nickname
<Authors> This is not true. This RBridge with be configured with an L1 nickname as well. It is the same as its L2 nickname.

-          A multi-level RBridge that has been configured to use the single-nickname mechanism MUST also support 8397 and fall back to using this mechanism in certain conditions.
<Authors> Right. This fall back happens in the mixture of unique-nickname & single-nickname multilevel RBridges being put in the same L1 area.

I assume that:

-          An RBridge that has both L1 and L2 adjacencies cannot be configured with just L1 nickname but without any L2 nickname
<Authors> In both unique- and single- flavors, an RBridge that has L1 and L2 adjacencies is configured with L1 nickname and the same nickname is reused in L2.  The two example topologies also indicate this fact. For example, “RB2” is connecting an L1 area and the L2 area. It uses the same nickname “2”.
<Authors> We could add the text to explicitly point this out in Section 8.

-          When a bridge that has been configured to use the single-nickname mechanism falls back to using unique-nickname mechanism it uses the L2 nickname with which it has been configured.
If these assumptions are correct, it would be useful, IMHO, to explicitly state that in the draft even if they may look obvious to TRILL experts.
<Authors> As stated above, when an L1/L2 RBridge is following RFC8397, it reuses its L1 nickname in L2.

I also think that an RBridge that has been configured to use the single nick-name mechanism but falls back to using the unique-nickname mechanism should notify the operator, say, by logging an appropriate message. Section 8 looks like the natural place to state that (if this is indeed the intention of the authors).
<Authors> OK. We will state this kind of notification should be done in the implementation.

I have also detected a couple of additional nits in the first statement of Section 5:
<Authors> OK. The nits will be fixed.

OLD:

PROPOSED:

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: rtg-dir <[email-masked]<mailto:[email-masked]>> On Behalf Of Zhangmingui (Martin)
Sent: Thursday, July 9, 2020 9:53 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hi Alexander,

Thanks
Mingui

Hi Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Best regards,
Martin

Mingui and all,

Regards,
Sasha

Mingui,

Hi Alexander,

Thanks,
Mingui

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Jul 2020 09:41:37 +0000

Mingui,

I will be waiting for the next version, but it already looks as it would address all my review and follow-up comments.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Zhangmingui (Martin) <[email-masked]>
Sent: Thursday, July 16, 2020 12:37 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Alexander,

Thanks,
Mingui
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/35z9vvxLCgwvLFCwUSdMSdj6H2?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/3XVYtErossEzBQtgbpAemJE6H2?u=https%3A%2F%2Fwww.huawei.com%2Ffr%2Fpersonal-data-request%2F>.

To: Zhangmingui (Martin) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Mingui,

Section 8 says that:

I assume that:

OLD:
   The following topology change scenarios will trigger the discover
   processes as defined in Sections 5.1<https://clicktime.symantec.com/3Ut31igvEY44PK8owQUKN4i6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-trill-multilevel-single-nickname-12%23section-5.1> and Section 5.2<https://clicktime.symantec.com/38HFdcB1N5GjMcmMGrumoRc6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-trill-multilevel-single-nickname-12%23section-5.2>:

PROPOSED:
   The following topology change scenarios will trigger the discovery
   processes as defined in Sections 5.1<https://clicktime.symantec.com/3Ut31igvEY44PK8owQUKN4i6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-trill-multilevel-single-nickname-12%23section-5.1> and 5.2<https://clicktime.symantec.com/38HFdcB1N5GjMcmMGrumoRc6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-trill-multilevel-single-nickname-12%23section-5.2>:

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Mingui

Hi Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Best regards,
Martin

Mingui and all,

Regards,
Sasha

Mingui,

Hi Alexander,

Thanks,
Mingui

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Jul 2020 08:09:17 +0000

Mingui and  all,
I have looked up the -13 version of the draft, and it resolves all my remaining concerns about the draft.
From my POV the draft is now ready for publication.

I would like to thank the authors for their patience and cooperation.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Thursday, July 16, 2020 12:42 PM
To: Zhangmingui (Martin) <[email-masked]>
Cc: [email-masked]; Yemin (Amy) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Zhangmingui (Martin) <[email-masked]<mailto:[email-masked]>>

Hi Alexander,

Thanks,
Mingui

Mingui,

Section 8 says that:

I assume that:

OLD:

PROPOSED:

Regards,
Sasha

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Mingui

Hi Mingui,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Best regards,
Martin

Mingui and all,

Regards,
Sasha

Mingui,

Hi Alexander,

Thanks,
Mingui