Skip to main content

Early Review of draft-ietf-trill-multilevel-single-nickname-01
review-ietf-trill-multilevel-single-nickname-01-rtgdir-early-vainshtein-2016-05-20-00

Request Review of draft-ietf-trill-multilevel-single-nickname
Requested revision No specific revision (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-05-20
Requested 2016-05-05
Authors Mingui Zhang , Donald E. Eastlake 3rd , Radia Perlman , Margaret Cullen , Hongjun Zhai
Draft last updated 2016-05-20
Completed reviews Rtgdir Early review of -01 by Sasha Vainshtein (diff)
Rtgdir Last Call review of -11 by Sasha Vainshtein (diff)
Genart Last Call review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -09 by Samuel Weiler (diff)
Secdir Telechat review of -15 by Samuel Weiler (diff)
Genart Telechat review of -15 by Dan Romascanu (diff)
Assignment Reviewer Sasha Vainshtein
State Completed
Review review-ietf-trill-multilevel-single-nickname-01-rtgdir-early-vainshtein-2016-05-20
Reviewed revision 01 (document currently at 17)
Result Has Issues
Completed 2016-05-20
review-ietf-trill-multilevel-single-nickname-01-rtgdir-early-vainshtein-2016-05-20-00

Hi all,

I have been appointed as the QA reviewer for

draft-ietf-trill-multilevel-single-nickname

.

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

 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

:

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

 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:   Alexander.Vainshtein at ecitele.com