[trill] AD review of draft-ietf-trill-rbridge-multilevel-04

[Alia Atlas <[e-mail]>]

As is customary, I have done my AD review
of draft-ietf-trill-rbridge-multilevel-04.  First, I would
like to thank the authors - Radia, Donald, Mingui, Anoop, and Hongjun - for
their work on this document.

>From my review, I do have a few high level concerns.  In particular, this
document has the job of guiding future WG work and setting out some
high-level decisions for the architecture of multi-level TRILL.
Unfortunately, there are several areas where the draft isn't willing to
commit to specific guidance or pick one alternative.   If there had been
vigorous discussion and debate on this, I might have more confidence that
there are strong reasons that truly justify the multiplication of
complexity represented in this document.   I don't see any of that on the
list.

I will require an updated draft and discussion before progressing this
document.


Major:

a) Sec 2.2.2.2:  Unless I'm missing something - this is proposing changing
the format of the basic TRILL header to accommodate multi-level IS-IS,
which would impact all hardware implementations of TRILL deployed
everywhere.   The idea of allowing both options just makes for yet more
complexity, options, and challenges in interoperability & troubleshooting!
  Please don't invent complexity.  I don't see any discussion on the
mailing list around this point and the document doesn't emphasize that this
is an extremely bad option - done to trade-off  complexity & storage at the
border switches.   This is definitely an area where operators and vendors
need to weigh in and silence can not imply consensus.

b) Sec 7:  I would strongly prefer to see a clear trade-off described in
terms of hardware impact as well as how flag-days for software could be
avoided.   I'm not seeing any considerations given to upgrading.  I also am
not excited that the WG isn't willing to pick one approach to go forward
with.  Multiple approaches mean at least twice the pain for implementing,
testing, troubleshooting, learning the technology, and so on.

c) I expect some section of management/operational considerations for how
different choices impact the ability to transition from a single area to a
multi-area solution.

Minor:

1) Sec 1.1 item 5: Is the concern about the 16-bit nickname limit for trill
switches based on the likelihood of collision from picking nicknames?   I
have a hard time picturing a network with over 65,500 trill switches and
distribution trees that doesn't run into many other issues.   Please clarify
the details of this concern in the document.

2) Sec 6:  The simple option of having topology constraints to avoid having
multiple trill switches in different areas connected to the same link
doesn't seem to have been considered.  Please add and clarify why a
topology constraint is or isn't acceptable operationally.  As you well
know, simplification and ease of interoperability are critical criteria for
evaluating the options.

Regards,
Alia