Subject: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 19 May 2016 10:58:33 +0000

Hi all,
I have been appointed as the QA reviewer for draft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname/?include_text=1>.
Before going into the review proper, I would like to make a couple of introductory statements.

1.       I am NOT a TRILL expert and actually never before has been involved with TRILL. I have been told that this is OK and the ADs are interested into getting reviews from non-experts. Well, in my case this is what they will get.

2.       The time frame for providing the review was quite demanding (at least for me). This probably affected the review quality and it effectively prevented me from discussing the review with the draft authors privately - I owe them a sincere apology for that.

3.       The RtgDirDocQa - Rtg Area Wiki<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa> states that the QA review is usually performed when a draft is going to be adopted as a WG document. While it mentions, that a WG document may be also subjected to such a review at the discretion of the WG Chairs, the initial guidelines for the QA reviewer in the Wiki mention only reviewing the draft for a QA adoption. As a consequence, I had to create my own list of questions that will try to answer based on what I have found in the Wiki. Here is this list:

a.       Is the draft easily readable and understandable?

b.      Does the draft represent an attempt to solve a real problem?

c.       Are there some serious technical gaps that the authors should try to fill?

d.      Are there any potential IETF process issues with the draft in its present form?
Please note that the question about "a good start for a WG draft" which appears in the Wiki does not appear on my list (since the draft is already a WG document).
At the same time I have included the question about solving a real problem (which appeared in the previous version of the Wiki page). The current version only asks if the draft "makes sense" which, from my POV, is something else.

My answers to these questions follow.

Is the draft easily readable and understandable?
Of course, "easily readable and understandable" is in the eye of the beholder. But as a non-expert can say that it was quite difficult for me to understand what this draft is really about.
Eventually, I have succeeded to build the following scheme that helped me to understand what I am dealing with:

*         The TRILL base spec<https://datatracker.ietf.org/doc/rfc6325/?include_text=1>:

o   Explicitly restricts TRILL to a single Level 1 IS-IS

o   Explicitly states that the nicknames of RBridges in the Trill packet header remain unchanged when the packet traverses the TRILL domain from ingress (where the TRILL header is pushed on the original Ethernet frame) to egress (where this header is popped)

*         An Informational Multi-Level TRILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1> WG draft claims that this restriction negatively affects TRILL scalability:

o   It mentions several scalability issues

o   However, it

?  Neither mentions any specific scale parameters where these issues become real

?  Nor provides any explanations about the reasons that make single-level IS-IS used by TRILL less scalable that single-level IS-IS when it is used for distributing IP reachability

o   It claims that some of these issues may be addressed by allowing usage of multi-level IS-IS for TRILL

o   It provides two specific proposals for making multi-level TRILL work:

o   One of these proposals is called "unique nicknames". This proposal:

?   Does not require any changes in the TRILL data plane

?  Requires introducing some structure in the nicknames of RBridges in order to guarantee that these names are unique within the TRILL-based campus

o   The other proposal is called "aggregate nicknames". This proposal:

?  Allows RBridges in different L1 areas of the campus to share nicknames

?  Requires a change in the TRILL data plane: the nicknames in the TRILL header of a packet will be modified by the L12 RBridges

?  Allows two possible flavors (bot mentioned in the draft):

*         The flavor that uses L1 area nicknames

*         The flavor that uses the nicknames of all L12 RBridges connected to a given L1 area as its name

*         The Standards Track Single Nickname draft (one that I have been asked to review) provides details on the second of the above-mentioned flavors of the "Aggregate Nicknames" approach:

o   It also allows sharing the same nickname between RBridges in different L1 areas

o   It also requires the same change in the TRILL data plane

o   It eliminates the need for allocating nicknames to L1 areas. Instead, each such area is identified by the set of nicknames of all L12 RBridges that connect to it.
It took me quite some time to build this scheme, and the text in the draft was not very helpful in this.
The following points contributed to "negative readability" from my POV:

*         The draft positions itself as an alternative to the Aggregate Nicknames approach while, from my POV, it is just provides additional details on one of the possible flavors of this approach

*         The draft is intended for the Standards Track, but it does not say that it updates the base TRILL spec (neither in the text nor in metadata).
(I guess that a TRILL expert would not have any problems with reading and understanding the draft - but I am providing a non-expert review here.
If I may suggest so, the authors could consider making the introduction more structured and clearly present the flow of dependencies  there.)

Does the Draft Represent an Attempt To Solve a Real Problem?

Unfortunately I cannot provide a definite "Yes" or "No" answer for this question:

*         Neither the draft I am reviewing, nor its "parent" multi-level TRILL draft do not provide sufficient information for a non-expert to understand why TRILL scalability is a real issue.

o   I know that these days single-level IS-IS used for distributing IP routing information is expected to support up to 1K nodes in "sparse mesh" topology

o   I do not know whether this level of scale is considered as simply not sufficient for TRILL deployments, be it from the POV of the number of RBridges, or from the POV of topological complexity

o   I also do not know whether there are some aspects of TRILL that make it less scalable than IS-IS used for distributing IP routing information

*         I know (as we all do) that in IP routing the preferred approach to solving IGP scalability issues is by using BGP. I wonder if this (or similar) approach has ever been considered for TRILL, and, if it was, why did the authors go for multi-level IS-IS.

*         I understand that the "Unique Nicknames" approach introduces some issues to TRILL (like structuring the nicknames). But I find it somewhat difficult to believe to the claim (in the Multi-Level TRILL draft) that the pool of 64K nicknames imposes any serious scalability restrictions on TRILL

*         Last but not least, I do not understand why the heed to assign nicknames to L1 areas (in the other flavor of the "aggregate nicknames" approach) carries with it any serious issues.

Are there some serious technical gaps that the authors should try to fill?

I see a potential for one such gap that I believe addressed by the authors: The draft does not say what is supposed to happen when a new border RBridge is added a given L1 area.
The draft mentions that if the L1 area with multiple border RBridges is partitioned so that some RBridges remain in one part and some - in the other part, all reachability information learned from it will be flushed. The resulting traffic hits in this scenario are expected of course.
But when a new border RBridge is connected to a L1 area, or when the failure of a link  (or node) that has caused partition of such an area is repaired - what should happen? Would such a "positive event" also result in flush of all learned reachability information and the accompanying traffic hit?

Are there any potential IETF process issues with the draft in its present form?

As I have said already, I see this draft as a logical extension of the Multi-Level TRILL one, so that,  From my POV the reference to the Multi-Level TRILL draft in this one should be Normative. However, the Multi-Level Trill draft is intended for the Informational track, while the Single Nickname draft positions itself as the Standard Track.  Simply making the reference Informative may be good enough as far as the letter of law goes, but I do not feel this is the right way to handle this.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 May 2016 09:08:22 -0400

Alexander: 

Thank you for the excellent review.  The authors will be responding to you.
I will send further comments later todsay. 

Sue 

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, May 19, 2016 6:59 AM
To: Jonathan Hardwick ([email-masked])
Cc: Susan Hares ([email-masked]); [email-masked];
[email-masked]; [email-masked];
[email-masked]'; [email-masked]
Subject: RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi all,

I have been appointed as the QA reviewer for
draft-ietf-trill-multilevel-single-nickname
<https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nicknam
e/?include_text=1> .

Before going into the review proper, I would like to make a couple of
introductory statements.

1.       I am NOT a TRILL expert and actually never before has been involved
with TRILL. I have been told that this is OK and the ADs are interested into
getting reviews from non-experts. Well, in my case this is what they will
get.

2.       The time frame for providing the review was quite demanding (at
least for me). This probably affected the review quality and it effectively
prevented me from discussing the review with the draft authors privately – I
owe them a sincere apology for that. 

3.       The RtgDirDocQa
<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa> – Rtg Area Wiki
states that the QA review is usually performed when a draft is going to be
adopted as a WG document. While it mentions, that a WG document may be also
subjected to such a review at the discretion of the WG Chairs, the initial
guidelines for the QA reviewer in the Wiki mention only reviewing the draft
for a QA adoption. As a consequence, I had to create my own list of
questions that will try to answer based on what I have found in the Wiki.
Here is this list:

c.       Are there some serious technical gaps that the authors should try
to fill?

d.      Are there any potential IETF process issues with the draft in its
present form?

Please note that the question about “a good start for a WG draft” which
appears in the Wiki does not appear on my list (since the draft is already a
WG document).

At the same time I have included the question about solving a real problem
(which appeared in the previous version of the Wiki page). The current
version only asks if the draft “makes sense” which, from my POV, is
something else.

Of course, “easily readable and understandable” is in the eye of the
beholder. But as a non-expert can say that it was quite difficult for me to
understand what this draft is really about.

Eventually, I have succeeded to build the following scheme that helped me to
understand what I am dealing with:

·         The TRILL base spec
<https://datatracker.ietf.org/doc/rfc6325/?include_text=1> :

o   Explicitly states that the nicknames of RBridges in the Trill packet
header remain unchanged when the packet traverses the TRILL domain from
ingress (where the TRILL header is pushed on the original Ethernet frame) to
egress (where this header is popped)

·         An Informational Multi-Level TRILL
<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?inclu
de_text=1>  WG draft claims that this restriction negatively affects TRILL
scalability:

o   However, it 

§  Neither mentions any specific scale parameters where these issues become
real 

§  Nor provides any explanations about the reasons that make single-level
IS-IS used by TRILL less scalable that single-level IS-IS when it is used
for distributing IP reachability

o   It claims that some of these issues may be addressed by allowing usage
of multi-level IS-IS for TRILL

o   One of these proposals is called “unique nicknames”. This proposal:

§   Does not require any changes in the TRILL data plane

§  Requires introducing some structure in the nicknames of RBridges in order
to guarantee that these names are unique within the TRILL-based campus

o   The other proposal is called “aggregate nicknames”. This proposal:

§  Allows RBridges in different L1 areas of the campus to share nicknames 

§  Requires a change in the TRILL data plane: the nicknames in the TRILL
header of a packet will be modified by the L12 RBridges

§  Allows two possible flavors (bot mentioned in the draft):

·         The flavor that uses L1 area nicknames

·         The flavor that uses the nicknames of all L12 RBridges connected
to a given L1 area as its name

·         The Standards Track Single Nickname draft (one that I have been
asked to review) provides details on the second of the above-mentioned
flavors of the “Aggregate Nicknames” approach:

o   It also allows sharing the same nickname between RBridges in different
L1 areas

o   It eliminates the need for allocating nicknames to L1 areas. Instead,
each such area is identified by the set of nicknames of all L12 RBridges
that connect to it.

It took me quite some time to build this scheme, and the text in the draft
was not very helpful in this.

The following points contributed to “negative readability” from my POV:

·         The draft positions itself as an alternative to the Aggregate
Nicknames approach while, from my POV, it is just provides additional
details on one of the possible flavors of this approach

·         The draft is intended for the Standards Track, but it does not say
that it updates the base TRILL spec (neither in the text nor in metadata).

(I guess that a TRILL expert would not have any problems with reading and
understanding the draft – but I am providing a non-expert review here.

If I may suggest so, the authors could consider making the introduction more
structured and clearly present the flow of dependencies  there.)

Unfortunately I cannot provide a definite “Yes” or “No” answer for this
question:

·         Neither the draft I am reviewing, nor its “parent” multi-level
TRILL draft do not provide sufficient information for a non-expert to
understand why TRILL scalability is a real issue. 

o   I know that these days single-level IS-IS used for distributing IP
routing information is expected to support up to 1K nodes in “sparse mesh”
topology

o   I do not know whether this level of scale is considered as simply not
sufficient for TRILL deployments, be it from the POV of the number of
RBridges, or from the POV of topological complexity

o   I also do not know whether there are some aspects of TRILL that make it
less scalable than IS-IS used for distributing IP routing information

·         I know (as we all do) that in IP routing the preferred approach to
solving IGP scalability issues is by using BGP. I wonder if this (or
similar) approach has ever been considered for TRILL, and, if it was, why
did the authors go for multi-level IS-IS.

·         I understand that the “Unique Nicknames” approach introduces some
issues to TRILL (like structuring the nicknames). But I find it somewhat
difficult to believe to the claim (in the Multi-Level TRILL draft) that the
pool of 64K nicknames imposes any serious scalability restrictions on TRILL 

·         Last but not least, I do not understand why the heed to assign
nicknames to L1 areas (in the other flavor of the “aggregate nicknames”
approach) carries with it any serious issues.

I see a potential for one such gap that I believe addressed by the authors:
The draft does not say what is supposed to happen when a new border RBridge
is added a given L1 area.

The draft mentions that if the L1 area with multiple border RBridges is
partitioned so that some RBridges remain in one part and some – in the other
part, all reachability information learned from it will be flushed. The
resulting traffic hits in this scenario are expected of course.

But when a new border RBridge is connected to a L1 area, or when the failure
of a link  (or node) that has caused partition of such an area is repaired –
what should happen? Would such a “positive event” also result in flush of
all learned reachability information and the accompanying traffic hit?

Are there any potential IETF process issues with the draft in its present
form?

As I have said already, I see this draft as a logical extension of the
Multi-Level TRILL one, so that,  From my POV the reference to the
Multi-Level TRILL draft in this one should be Normative. However, the
Multi-Level Trill draft is intended for the Informational track, while the
Single Nickname draft positions itself as the Standard Track.  Simply making
the reference Informative may be good enough as far as the letter of law
goes, but I do not feel this is the right way to handle this.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 23 May 2016 09:30:44 +0000

Hi Alexander,

Thanks for the review!

The multilevel conception itself is abstract and not easily understandable. However, it was really interesting in designing such a solution. Appreciate the review and the time on relevant documents to figure out the whole scheme.

> ?  Nor provides any explanations about the reasons that make single-level IS-IS
> used by TRILL less scalable that single-level IS-IS when it is used for distributing IP
> reachability

The reason comes from the fact that the length of a nickname is different from an IP address. I think this could be addressed in the updated version of the draft: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1.

> *         The draft positions itself as an alternative to the Aggregate
> Nicknames approach while, from my POV, it is just provides additional details on
> one of the possible flavors of this approach

The WG used to discuss several ways to address the "Aggregate Nickname" approach. One way was to use pseudonode nickname to denote an L1 area. Another way was to let border RBridges swap L1 and L2 nicknames. However, these possible alternatives were never detailed as the one being reviewed, after the WG weighted their issues and complexity. 

> *         The draft is intended for the Standards Track, but it does not say that
> it updates the base TRILL spec (neither in the text nor in metadata)

RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS while the draft being reviewed is talking about how to enable inter-communication between level 1 IS-IS areas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 should not appear in the "Updates" metadata?

Best regards,
Mingui

> -----Original Message-----
> Sent: Thursday, May 19, 2016 6:59 PM
> Cc: Susan Hares ([email-masked]); [email-masked]; Zhangxian (Xian);
> [email-masked]; [email-masked]';
> [email-masked]
> draft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.org/doc/draft-i
> etf-trill-multilevel-single-nickname/?include_text=1>.
> with TRILL. I have been told that this is OK and the ADs are interested into getting
> reviews from non-experts. Well, in my case this is what they will get.
> 
> 2.       The time frame for providing the review was quite demanding (at least
> for me). This probably affected the review quality and it effectively prevented
> me from discussing the review with the draft authors privately - I owe them a
> sincere apology for that.
> 
> 3.       The RtgDirDocQa - Rtg Area
> Wiki<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa> states that the
> QA review is usually performed when a draft is going to be adopted as a WG
> document. While it mentions, that a WG document may be also subjected to
> such a review at the discretion of the WG Chairs, the initial guidelines for the QA
> reviewer in the Wiki mention only reviewing the draft for a QA adoption. As a
> consequence, I had to create my own list of questions that will try to answer
> based on what I have found in the Wiki. Here is this list:
> 
> Please note that the question about "a good start for a WG draft" which appears
> in the Wiki does not appear on my list (since the draft is already a WG document).
> (which appeared in the previous version of the Wiki page). The current version
> only asks if the draft "makes sense" which, from my POV, is something else.
> 
> 
> Of course, "easily readable and understandable" is in the eye of the beholder.
> But as a non-expert can say that it was quite difficult for me to understand what
> this draft is really about.
> *         The TRILL base
> spec<https://datatracker.ietf.org/doc/rfc6325/?include_text=1>:
> 
> o   Explicitly states that the nicknames of RBridges in the Trill packet header
> remain unchanged when the packet traverses the TRILL domain from ingress
> (where the TRILL header is pushed on the original Ethernet frame) to egress
> (where this header is popped)
> 
> *         An Informational Multi-Level
> TRILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include
> _text=1> WG draft claims that this restriction negatively affects TRILL scalability:
> 
> ?  Nor provides any explanations about the reasons that make single-level IS-IS
> used by TRILL less scalable that single-level IS-IS when it is used for distributing IP
> reachability
> 
> ?  Requires introducing some structure in the nicknames of RBridges in order to
> guarantee that these names are unique within the TRILL-based campus
> 
> ?  Requires a change in the TRILL data plane: the nicknames in the TRILL header
> of a packet will be modified by the L12 RBridges
> 
> *         The Standards Track Single Nickname draft (one that I have been
> asked to review) provides details on the second of the above-mentioned flavors
> of the "Aggregate Nicknames" approach:
> 
> o   It eliminates the need for allocating nicknames to L1 areas. Instead, each
> such area is identified by the set of nicknames of all L12 RBridges that connect to
> it.
> *         The draft positions itself as an alternative to the Aggregate
> Nicknames approach while, from my POV, it is just provides additional details on
> one of the possible flavors of this approach
> 
> *         The draft is intended for the Standards Track, but it does not say that
> it updates the base TRILL spec (neither in the text nor in metadata)

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 23 May 2016 10:13:29 +0000

Mingui hi!

Lots of thanks for a prompt response to some of the issues I've raised in the review.

Please see some comments to you responses inline below.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([email-masked])
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares ([email-masked]); [email-masked]
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks for the review!

The multilevel conception itself is abstract and not easily understandable.

[[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level TRILL specifically? I am asking because I believe am reasonably well aware of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSPF, but I would not call it "abstract and not easily understandable".  And there are quite a few excellent introductions to the subject (again in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review.

However, it was really interesting in designing such a solution. Appreciate the review and the time on relevant documents to figure out the whole scheme.

> ?  Nor provides any explanations about the reasons that make

> single-level IS-IS used by TRILL less scalable that single-level IS-IS

> when it is used for distributing IP reachability

The reason comes from the fact that the length of a nickname is different from an IP address.

[[Sasha]] I must admit that I do not understand the connection. By this logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-DIR list to comment on that?

I think this could be addressed in the updated version of the draft: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1.

> details on one of the possible flavors of this approach

The WG used to discuss several ways to address the "Aggregate Nickname" approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of any discussions that have been hold there. I am only speaking about what I could find in the two drafts mentioned in my review.

One way was to use pseudonode nickname to denote an L1 area. Another way was to let border RBridges swap L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames approach always implies swapping of ingress and egress nicknames - at least this is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit. I also do not understand how using L1 area names (which is a control plane functionality) could replace the swapping of nicknames (which is a pure data plane function).

However, these possible alternatives were never detailed as the one being reviewed, after the WG weighted their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not address the issue I've raised, namely that the Single Nickname draft incorrectly positions itself as an alternative approach to that of Aggregate Nicknames in the Multi-Level TRILL draft, and that such incorrect positioning negatively affects ability of a non-expert

[[Sasha]] It seems that we understand the meaning of the RFC metadata differently. From my POV if  you remove/relax a restriction imposed by an already published Standards Track RFC, this means that you update it, and the metadata should reflect that. E.g., you can take a look at RFC 4379 that is marked as updating RFC 1122 because it allows transmission of IP packets with the Destination IP address  in the 127/8 subnet - something that RFC 1122 explicitly prohibits.

Again, it would be interesting to hear what the people on the RTG-DIR list (especially ones that serve now - or have served in the past - as ADs and/or WG Chairs) think on that.

Best regards,

Mingui

> To: Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)

> Cc: Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; Zhangxian

> (Xian); [email-masked]<mailto:[email-masked]>;

> [email-masked]'; [email-masked]<mailto:[email-masked]>

> Subject: RTG-DIR QA review for

> draft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.o

> rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=1>.

> with TRILL. I have been told that this is OK and the ADs are

> interested into getting reviews from non-experts. Well, in my case this is what they will get.

> for me). This probably affected the review quality and it effectively

> prevented me from discussing the review with the draft authors

> privately - I owe them a sincere apology for that.

> Wiki<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa>

> states that the QA review is usually performed when a draft is going

> to be adopted as a WG document. While it mentions, that a WG document

> may be also subjected to such a review at the discretion of the WG

> Chairs, the initial guidelines for the QA reviewer in the Wiki mention

> only reviewing the draft for a QA adoption. As a consequence, I had to

> create my own list of questions that will try to answer based on what I have found in the Wiki. Here is this list:

> c.       Are there some serious technical gaps that the authors should try to

> fill?

> d.      Are there any potential IETF process issues with the draft in its present

> Please note that the question about "a good start for a WG draft"

> which appears in the Wiki does not appear on my list (since the draft is already a WG document).

> At the same time I have included the question about solving a real

> problem (which appeared in the previous version of the Wiki page). The

> current version only asks if the draft "makes sense" which, from my POV, is something else.

> But as a non-expert can say that it was quite difficult for me to

> Eventually, I have succeeded to build the following scheme that helped

> me to understand what I am dealing with:

> remain unchanged when the packet traverses the TRILL domain from

> ingress (where the TRILL header is pushed on the original Ethernet

> frame) to egress (where this header is popped)

> TRILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> evel/?include _text=1> WG draft claims that this restriction

> negatively affects TRILL scalability:

> ?  Neither mentions any specific scale parameters where these issues

> become real

> ?  Nor provides any explanations about the reasons that make

> single-level IS-IS used by TRILL less scalable that single-level IS-IS

> when it is used for distributing IP reachability

> o   It claims that some of these issues may be addressed by allowing usage of

> multi-level IS-IS for TRILL

> ?  Requires introducing some structure in the nicknames of RBridges in

> order to guarantee that these names are unique within the TRILL-based

> campus

> ?  Allows RBridges in different L1 areas of the campus to share

> nicknames

> ?  Requires a change in the TRILL data plane: the nicknames in the

> TRILL header of a packet will be modified by the L12 RBridges

> *         The flavor that uses the nicknames of all L12 RBridges connected to a

> given L1 area as its name

> flavors of the "Aggregate Nicknames" approach:

> o   It also allows sharing the same nickname between RBridges in different L1

> areas

> such area is identified by the set of nicknames of all L12 RBridges

> It took me quite some time to build this scheme, and the text in the

> draft was not very helpful in this.

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 24 May 2016 08:23:25 +0000

Hi Sasha,

Thanks for your comments. Please see responses inline below.

Thanks,
Mingui

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares ([email-masked]); [email-masked]; Jonathan Hardwick ([email-masked])
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Mingui hi!

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks for the review!

[Mingui] Yes, multi-level arch of IS-IS has already been well understood. However, the extending TRILL to multi-levels brings new challenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames and the other issue is on handling multi-destination packet distribution trees. In order not to make the specifications "abstract", the draft carefully designed two walking-through examples in Section 3. If the examples were understood, it would be non-abstract as well. ;-)

[Mingui] For a single-level IS-IS instance, the length of the address determines the name space. In the informational draft, Section 1.1 TRILL Scalability Issues, the following statement is relevant

"   5. the limit of the number of TRILL switches, due to the 16-bit nickname space,"

[Mingui] Actually, the informational draft had included the information of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5.

[[Sasha]] I was under impression that the Aggregate Nicknames approach always implies swapping of ingress and egress nicknames - at least this is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit.

[Mingui] Oh, that's not true. The "Single Nickname" draft is definitely different from "Swapping Nickname" approach. In the "Single Nickname" draft, there is no "ingress swap nickname field" or "egress swap nickname field".

I also do not understand how using L1 area names (which is a control plane functionality) could replace the swapping of nicknames (which is a pure data plane function).

[Mingui] There is no "swapping" action in the "Single Nickname" draft. To explain with an example, if the TRILL data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" draft.

[Mingui] I think the above explanation about the difference between "Single Nickname" and "Swapping Nickname" will clear the confusion.

[Mingui] OK. Thanks for the informational example. I am afraid the relationship between the draft and  RFC 6325 is slightly different. Since specifications of RFC 6325 would still hold after the draft is published.

Best regards,

Mingui

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 24 May 2016 10:45:28 +0000

Mingui hi!
Lots of thanks for a prompt response.

A few short comments inline below.

Regards,
Sasha

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

From: Mingui Zhang [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares; [email-masked]; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Sasha,

Thanks,
Mingui

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Mingui hi!

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks for the review!

[[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider deployment scenarios with more than 64K RBridges in a single TRILL campus? Is this a realistic scenario?

[[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apologies for a long quotation; the relevant places are highlighted):

    -  S transmits an Ethernet frame with source MAC = S and destination

      MAC = D.

   -  RB27 [[Sasha - the ingress RBridge]] encapsulates with a TRILL header with ingress RBridge = 27,

      and egress RBridge = 3 producing a TRILL Data packet.

   -  RB2 and RB20 have announced in the Level 1 IS-IS instance in area

      {2,20}, that they are attached to all those area nicknames,

      including {3,30}. Therefore, IS-IS routes the packet to RB2 (or

      RB20, if RB20 on the least-cost route from RB27 to RB3).

   -  RB2, when transitioning the packet from Level 1 to Level 2,

      replaces the ingress TRILL switch nickname with its own nickname,

      so replaces 27 with 2.

...

   -  The packet is forwarded through Level 2, to RB3, which has

      advertised, in Level 2, its L2 nickname as 3.

   -  RB3, when forwarding into area {3,30}, replaces the egress

      nickname in the TRILL header with RB44's nickname (44). (The

      ingress nickname MAY be replaced with an area nickname selected

      from {2,20}. See Section 4 for the detail of the selection method.

      Here, suppose nickname 2 is selected.) So, within the destination

      area, the ingress nickname will be 2 and the egress nickname will

      be 44.

In other words, your draft explicitly states that the area border RBridges modify the nicknames in the TRILL header of a packet that crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?

[[Sasha]] Please see above.

[[Sasha]] Sorry, but no, it doesn't.

[[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is not marked as obsoleting RFC 6325.

Best regards,

Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 25 May 2016 03:06:51 +0000

Hi Sasha,

Thanks for the comments.

[[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider deployment scenarios with more than 64K RBridges in a single TRILL campus? Is this a realistic scenario?
[Mingui] We can also doubt whether a domain with more that 2^32 IP routers is a realistic scenario. The fact is that a single campus is usually not allowed to use up the entire 64K namespace. Please consider the scenario that lots of TRILL campuses are to be interconnected.

[[Sasha]] In other words, your draft explicitly states that the area border RBridges modify the nicknames in the TRILL header of a packet that crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?
[Mingui] As I said, there is no "swap nickname field" conception in the draft.  Yes, the border RBridge needs to modify the nickname but it does not have to modify it through the "swapping" operation. Instead, the border RBridge "replaces" the nickname in the TRILL data packets with its own nickname (rather than a nickname in the "swap nickname field" provided by the originating RBridge). Why authors prefer the replacing operation than the swapping operation? Because the swapping operation requires a new TRILL header (two additional 16-bit fields) which has not been standardized yet.

As for the "Updates" metadata, let's see if people on the RTG-DIR list would give directions.

Best regards,
Mingui
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 6:45 PM
To: Mingui Zhang
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares; [email-masked]; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Mingui hi!

Regards,
Sasha

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

From: Mingui Zhang [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares; [email-masked]<mailto:[email-masked]>; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Sasha,

Thanks,
Mingui

Mingui hi!

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks for the review!

      MAC = D.

      so replaces 27 with 2.

...

      be 44.

Best regards,

Mingui

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 25 May 2016 12:23:36 +0000

Hi Mingui,
I will try to summarize our agreements and disagreements.

1.       The scale of TRILL deployments:

a.       I have not seen any specific numbers or references to any specific topologies that could really make single-level TRILL not scalable enough - neither in the TRILL drafts I've read nor in our discussions so far

b.      Regarding your  reference to multiple interconnected TRILL-based campuses in your last email: I do not think that TRILL is an alternative to or competes with Internet

c.       I have also noticed that, once upon a time (4 years ago)  there was an attempt to use BGP with TRILL. I wonder why this draft has been left to expire because, from my POV, BGP is greatly preferable to multi-level IS-IS when it comes to scalability issues

2.       Nickname Re-write vs Nickname Swapping: Looks like a clear case of misunderstanding between us, probably due to the fact that I am not a TRILL expert:

a.       I have used the term "swapping" in the same way it is used in MPLS (e.g., see RFC 3031 discussing label swapping). In other words, from my POV "nickname swapping" and "nickname re-write" were synonyms

b.      It seems that some yet to be standardized extension of TRILL considers some dedicated nickname swapping mechanism that carries new nicknames in some extension of the TRILL header.  In this parlance "nickname re-write" and "nickname swapping" are different

c.       I think that we now safely consider this discussion issue as closed

3.       Metadata:

a.       I fully agree that we should hear from other RTG-DIR members on what exactly (if at all) should be specified to clarify the relationship between the Single Nickname draft and RFC 6325

b.      I can only add that, AFAIK, the Multi-Level TRILL draft, being positioned as an Informational, can neither update nor obsolete RFC 6325 (which is Standards Track). So there is no issue with its metadata being empty.

There is one issue in my original review that we have not discussed at all - namely, the behavior implied by the Single Nickname draft when a new border RBridge is added to a certain area.

Regards,
Sasha

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

From: Mingui Zhang [mailto:[email-masked]]
Sent: Wednesday, May 25, 2016 6:07 AM
To: Alexander Vainshtein
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares; [email-masked]; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Sasha,

Thanks for the comments.

Best regards,
Mingui

Mingui hi!

Regards,
Sasha

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

Hi Sasha,

Thanks,
Mingui

Mingui hi!

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks for the review!

      MAC = D.

      so replaces 27 with 2.

...

      be 44.

Best regards,

Mingui

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 May 2016 17:03:54 -0400

Hi Alexander,

Thanks from me also for your review.  I'd like to chime in with a few
thoughts:

On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein
<[email-masked]> wrote:
> a. I have not seen any specific numbers or references to any
> specific topologies that could really make single-level TRILL not
> scalable enough - neither in the TRILL drafts I've read nor in our
> discussions so far

I am puzzled as to why you think there would be some specific numeric
hard boundary, other than number space or memory space exhaustion,
beyond which you cannot scale. Can you point to a documentation of
such a thing for IP use of IS-IS? Surely it depends on how much
computer power the routers have, link stability, and numerous other
factors.

Just looking at convergence time and approximating it as the amount of
computation required at a typical router in the TRILL campus, it is on
the order of N*(log N) for computation of least cost routes where
there are N routers in a single level campus while it is on the order
of (sqrt N)*(log N) for multi-level, in both cases assuming optimized
calculations. The largest TRILL campuses I am aware of are on the
order of 3,000 routers. So one would expect that converting such a
campus to multi-level TRILL would reduce convergence time by
approximately a factor of 50. Furthermore, one would expect the rate
of failures within each Level 1 area in the multi-level case to be
approximately proportional to the number of links/routers and thus
also fall by one and a half orders of magnitude. Do you claim these
improvements would never be valuable?

There are many other scaling factors such as the size of the link
state database, etc. I believe the informational
draft-ietf-trill-rbridge-multi-level gives a good summary.

> b. Regarding your reference to multiple interconnected TRILL-based
> campuses in your last email: I do not think that TRILL is an
> alternative to or competes with Internet.

I agree that TRILL does not compete with the Internet.  :-)

I believe this facet of the discussion was in connection with the
possibility of TRILL nickname space exhaustion. Consider the following
factors:

1) TRILL supports active-active connection of end stations at the
TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for
Active-Active Access) consumes TRILL nicknames for active-active edge
groups.

2) Assuming, for the moment, you are using multi-level with unique
nicknames, the nickname allocation mechanism will waste many nicknames
due to hierarchical assignment, the same way power-of-two sized IP
subnets waste IP addresses.

3) There is a desire to interconnect TRILL campuses that are under
joint or cooperative management with limited control plane coupling so
as to limit error propagation, etc. There are various possible ways to
do this but most of them assume non-conflicting nicknames (or
non-conflicting level 2 nicknames if the campuses are multi-level).

I admit that even taking the largest existing TRILL campuses I know
about and adding extensive active-active end station support at the
edge and multi-level with unique nicknames that are hierarchically
allocated, you would still probably not exhaust the TRILL nickname
space. But you could be getting close to that hard limit. This seems
like enough reason to me to be advancing a standard where Level 1
areas are aggregated (whether by a single nickname or set of border
router nicknames) to, for all practical purposes, eliminate the
nickname space restriction.

> c. I have also noticed that, once upon a time (4 years ago) there
> was an attempt to use BGP with TRILL. I wonder why this draft has
> been left to expire because, from my POV, BGP is greatly preferable
> to multi-level IS-IS when it comes to scalability issues.
>
> 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case
> of misunderstanding between us, probably due to the fact that I am
> not a TRILL expert:
>
> a.       I have used the term "swapping" in the same way it is used
> in MPLS (e.g., see RFC 3031 discussing label swapping). In other
> words, from my POV "nickname swapping" and "nickname re-write" were
> synonyms.
>
> b.      It seems that some yet to be standardized extension of TRILL
> considers some dedicated nickname swapping mechanism that carries
> new nicknames in some extension of the TRILL header.  In this
> parlance "nickname re-write" and "nickname swapping" are different.

Right. The possibility was discussed some time ago of expanding the
TRILL header so that, for TRILL Data packets going between different
Level 1 Areas, there could be, in effect, two ingress nicknames (an
ingress RBridge nickname and an ingress Area nickname) and two egress
nicknames (an egress RBridge nickname and an egress Area nickname).
Appropriate swapping would occur at border routers to avoid changes in
fast path logic at all non-border routers. Within Level 2, the Area
nicknames would be in the existing header slots that are routed on,
etc. However, as far as I can recall, no specification was ever been
produced for this "nickname swapping" although it is mentioned in the
informational multi-level draft.

> c.       I think that we now safely consider this discussion issue
> as closed.
>
> 3.       Metadata:
>
> a.       I fully agree that we should hear from other RTG-DIR
> members on what exactly (if at all) should be specified to clarify
> the relationship between the Single Nickname draft and RFC 6325

I would note that the IESG policy on "updates" has become very strict
recently. It used to be a judgment call. Now, when a Standards Track
RFC merely extends another such RFC so you could implement an instance
of the earlier standard as specified without reference to or violating
the subsequent specification, the IESG will generally prohibit you
from claiming that the subsequent specification "updates" the first.
(I do not particularly agree with this policy change myself.)

> b.      I can only add that, AFAIK, the Multi-Level TRILL draft,
> being positioned as an Informational, can neither update nor
> obsolete RFC 6325 (which is Standards Track). So there is no issue
> with its metadata being empty.
>
> There is one issue in my original review that we have not discussed
> at all - namely, the behavior implied by the Single Nickname draft
> when a new border RBridge is added to a certain area.

I agree that what needs to be done when border RBridges are
added/deleted needs to be clear in the draft.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> [Mingui] Actually, the informational draft had included the information of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 26 May 2016 06:08:10 +0000

Donald,
Lots of thanks for a very detailed response!

Lots of thanks for very important information about the actual and expected scale of TRILL deployments as well as for presenting some of the factors (line active-active TRILL operation) that affect the consumption of the nickname space. It addresses my question about the reason to go for multi-level IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are very popular in IP/MPLS deployments due to LDP  (and, now, IP/LDP FRR techniques), so this information was important to me in order to understand that the multi-level TRILL drafts solve a real problem. I would suggest adding this information to the multi-level TRILL draft.

However, I am still not sure if the Single Nickname draft (one I have been reviewing)  represents an attempt to solve a real problem. My understanding so far has been that it follows the Aggregate Nicknames approach in the multi-level TRILL draft, but eliminates the need to assign nicknames to L1 areas. I do not see if, even with the scale you have mentioned) this could be a serious issue (e.g., contribute significantly to depletion of the nickname space). Do I  miss something here?

The swapping vs. re-write issue I have discussed with Mingui is a pure case of terminology. AsI have said, I consider it as closed.

As for the metadata issue  - I am perfectly ready to follow the guidance of ADs and WG chairs. especially since this policy has recently undergone serious changes.

Two additional questions - for the sake of my curiosity:

  1.  Can possibly you explain what has happened to draft that proposed using BGP with TRILL?
  2.  Did anybody consider combining IPFRR techniques with TRILL?

Regards, and lots of thanks in advance,
Sasha

________________________________________
From: Donald Eastlake <[email-masked]>
Sent: Thursday, May 26, 2016 12:03 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares; [email-masked]; Jonathan Hardwick; [email-masked]
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Alexander,

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 26 May 2016 19:41:46 -0400

Hi Sasha,

On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Lots of thanks for very important information about the actual and
> expected scale of TRILL deployments as well as for presenting some of the
> factors (line active-active TRILL operation) that affect the consumption of
> the nickname space. It addresses my question about the reason to go for
> multi-level IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are
> very popular in IP/MPLS deployments due to LDP  (and, now, IP/LDP FRR
> techniques), so this information was important to me in order to understand
> that *the multi-level TRILL drafts solve a real problem*. I would suggest
> adding this information to the multi-level TRILL draft.
>

Sounds reasonable. Something like that can be added to
draft-ietf-trill-rbridge-multilevel.

> However, I am still not sure if* the Single Nickname draft* (one I have
> been reviewing)  represents an attempt *to solve a real problem*. My
> understanding so far has been that it follows the Aggregate Nicknames
> approach in the multi-level TRILL draft, but *eliminates the need to
> assign nicknames to L1 areas*. I do not see if, even with the scale you
> have mentioned) this could be a serious issue (e.g., contribute
> significantly to depletion of the nickname space). Do I  miss something
> here?
>

I'm not sure it matters. If you believe that there is a good reason for
aggregated nicknames, this draft is the only aggregated nickname draft that
is current active and the only such draft that has been adopted by the
TRILL WG. So unless there is some problem with its approach, it seems to me
that it should be progressed.

> The swapping vs. re-write issue I have discussed with Mingui is a pure
> case of terminology. AsI have said, I consider it as closed.
>
> As for the metadata issue  - I am perfectly ready to follow the guidance
> of ADs and WG chairs. especially since this policy has recently undergone
> serious changes.
>
> If you give me a pointer to the specific expired draft, I might remember
something about its history. By the way, there is currently a draft in IDR:
draft-idr-ietf-ls-trill.

>
>    1. Did anybody consider combining IPFRR techniques with TRILL
>
> While I don't recall any specific mention of it, I don't see that any
change would be required to existing TRILL standards. Fast ReRoute would
run off the existing link state databases.

Actually, the above applies only to unicast data. TRILL uses distribution
trees for multi-destination data and there is
draft-ietf-trill-resilient-trees which provides back-up distribution trees
sort of like FRR provides back-up paths.

Thanks,
Donald

> Cc: Mingui Zhang; Zhangxian (Xian); [email-masked];
> [email-masked]; Susan Hares;
> [email-masked]; Jonathan Hardwick; [email-masked]
>
> Subject: Re: [RTG-DIR] RTG-DIR QA review for
> > Cc: [email-masked]'; Zhangxian (Xian); [email-masked];
> [email-masked]; Susan Hares;
> [email-masked]; Jonathan Hardwick
> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
> > [[Sasha]] Do you (or the authors of the multi-level TRILL draft)
> consider deployment scenarios with more than 64K RBridges in a single TRILL
> campus? Is this a realistic scenario?
> > [Mingui] We can also doubt whether a domain with more that 2^32 IP
> routers is a realistic scenario. The fact is that a single campus is
> usually not allowed to use up the entire 64K namespace. Please consider the
> scenario that lots of TRILL campuses are to be interconnected.
> >
> >
> > [[Sasha]] In other words, your draft explicitly states that the area
> border RBridges modify the nicknames in the TRILL header of a packet that
> crosses the Level 2 domain. How is this different from swapping (save from
> the name of the operation)?
> > [Mingui] As I said, there is no "swap nickname field" conception in the
> draft.  Yes, the border RBridge needs to modify the nickname but it does
> not have to modify it through the "swapping" operation. Instead, the border
> RBridge "replaces" the nickname in the TRILL data packets with its own
> nickname (rather than a nickname in the "swap nickname field" provided by
> the originating RBridge). Why authors prefer the replacing operation than
> the swapping operation? Because the swapping operation requires a new TRILL
> header (two additional 16-bit fields) which has not been standardized yet.
> >
> > Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:
> [email-masked]>; [email-masked]
> <mailto:[email-masked]>; Susan
> Hares; [email-masked]<mailto:[email-masked]>; Jonathan
> Hardwick
> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
> > Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:
> [email-masked]>; [email-masked]
> <mailto:[email-masked]>; Susan
> Hares; [email-masked]<mailto:[email-masked]>; Jonathan
> Hardwick
> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
> > Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:
> [email-masked]>; [email-masked]
> <mailto:[email-masked]>; Susan
> Hares ([email-masked]<mailto:[email-masked]>); [email-masked]
> <mailto:[email-masked]>; Jonathan Hardwick (
> [email-masked]<mailto:[email-masked]>)
> > Subject: RE: [RTG-DIR] RTG-DIR QA review for
> > To: Alexander Vainshtein; Jonathan Hardwick (
> [email-masked]<mailto:[email-masked]>)
> > Cc: [email-masked]'; Zhangxian (Xian); [email-masked]<mailto:
> [email-masked]>; [email-masked]
> <mailto:[email-masked]>; Susan
> Hares ([email-masked]<mailto:[email-masked]>); [email-masked]
> <mailto:[email-masked]>
> > Subject: Re: [RTG-DIR] RTG-DIR QA review for
> > [[Sasha]] Do you refer to the multi-level IS-IS in general or
> multi-level TRILL specifically? I am asking because I believe am reasonably
> well aware of the multi-level architecture of IS-IS as used for IP routing.
> It is somewhat different from that of OSPF, but I would not call it
> "abstract and not easily understandable".  And there are quite a few
> excellent introductions to the subject (again in the context of IP
> routing). However, I am definitely not a TRILL expert, and have stated that
> in the review.
> >
> >
> >
> > [Mingui] Yes, multi-level arch of IS-IS has already been well
> understood. However, the extending TRILL to multi-levels brings new
> challenges. As stated in the informational draft, one issue is on
> processing the TRILL switch nicknames and the other issue is on handling
> multi-destination packet distribution trees. In order not to make the
> specifications "abstract", the draft carefully designed two walking-through
> examples in Section 3. If the examples were understood, it would be
> non-abstract as well. ;-)
> >
> >
> >
> > However, it was really interesting in designing such a solution.
> Appreciate the review and the time on relevant documents to figure out the
> whole scheme.
> >
> >
> >
> > [[Sasha]] I must admit that I do not understand the connection. By this
> logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for
> IPv4, but I have never seen such claims before. Could you please elaborate?
> Could somebody on the RTG-DIR list to comment on that?
> >
> >
> >
> > [Mingui] For a single-level IS-IS instance, the length of the address
> determines the name space. In the informational draft, Section 1.1 TRILL
> Scalability Issues, the following statement is relevant
> >
> > [[Sasha]] Do you (or the authors of the multi-level TRILL draft)
> consider deployment scenarios with more than 64K RBridges in a single TRILL
> campus? Is this a realistic scenario?
> >
> >
> >
> >
> >
> > I think this could be addressed in the updated version of the draft:
> https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1
> .
> >
> >
> >
> > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware
> of any discussions that have been hold there. I am only speaking about what
> I could find in the two drafts mentioned in my review.
> >
> >
> >
> > [Mingui] Actually, the informational draft had included the information
> of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname
> Field Aggregated Nicknames" and read the words about "pseudonode" of
> Section 2.5
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 27 May 2016 05:01:31 +0000

Donald,

Again, lots of thanks for a prompt response

regarding the NGP dratf: here is the link:

https://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05

This draft has expired 4 years ago, and to me it looks as addressing the same problem you and your colleagues try to address with multi-level IS-IS.

Regarding your statement that the Single Nickname draft "is the only aggregated nickname draft that is current active":

I think that the specific problematic point of this draft is volatility of the area names (that are just the collections of the nicknames of all border RBridges of a given area in this draft). -

This may be - or may be not - a serious technical issue with the proposed approach. In any case I'd say it requires careful analysis.

And, after re-reading your previous email, I think there is a common potential issue with the Aggregate Nicknames approach as such.

Please consider the following scenario (actually mentioned as a security issue in your email)

  1.  There is a L1 one area with multiple border RBridges.
  2.  Due to some failure this area is partitioned
  3.  Later still, a new RBridge comes up in one of the new areas and acquires a nickname that is unique in this area
  4.  Now the failure that has caused partitioning f the area has been repaired. The areas are merged, and some RBridges now have duplicate nicknames.

Again, this requires some analysis IMHO.

Regards,
Sasha

________________________________
From: Donald Eastlake <[email-masked]>
Sent: Friday, May 27, 2016 2:41 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); [email-masked]; [email-masked]; Susan Hares; [email-masked]; Jonathan Hardwick; [email-masked]
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Sasha,

On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Donald,
Lots of thanks for a very detailed response!

Sounds reasonable. Something like that can be added to draft-ietf-trill-rbridge-multilevel.

I'm not sure it matters. If you believe that there is a good reason for aggregated nicknames, this draft is the only aggregated nickname draft that is current active and the only such draft that has been adopted by the TRILL WG. So unless there is some problem with its approach, it seems to me that it should be progressed.

If you give me a pointer to the specific expired draft, I might remember something about its history. By the way, there is currently a draft in IDR: draft-idr-ietf-ls-trill.

While I don't recall any specific mention of it, I don't see that any change would be required to existing TRILL standards. Fast ReRoute would run off the existing link state databases.

Actually, the above applies only to unicast data. TRILL uses distribution trees for multi-destination data and there is draft-ietf-trill-resilient-trees which provides back-up distribution trees sort of like FRR provides back-up paths.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]<mailto:[email-masked]>

________________________________________
From: Donald Eastlake <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 26, 2016 12:03 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares; [email-masked]<mailto:[email-masked]>; Jonathan Hardwick; [email-masked]<mailto:[email-masked]>

Hi Alexander,

Thanks,
Donald
===============================
Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked]<mailto:[email-masked]>

> Regards,
> Sasha
>
> Office: +972-39266302<tel:%2B972-39266302>
> Cell:      +972-549266302<tel:%2B972-549266302>
> From: Mingui Zhang [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares; [email-masked]<mailto:[email-masked]>; Jonathan Hardwick
> From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Susan Hares; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick
> Office: +972-39266302<tel:%2B972-39266302>
> Cell:      +972-549266302<tel:%2B972-549266302>
> Email:   [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
> From: Mingui Zhang [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Susan Hares; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick
> From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Susan Hares ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>)
> Office: +972-39266302<tel:%2B972-39266302>
>
> Cell:      +972-549266302<tel:%2B972-549266302>
>
> Email:   [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
>
>
> From: rtg-dir [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mingui Zhang
> To: Alexander Vainshtein; Jonathan Hardwick ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>)
> Cc: [email-masked]<mailto:[email-masked]>'; Zhangxian (Xian); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Susan Hares ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>