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

[Donald Eastlake <[e-mail]>]

Hi Alia,

Thanks for your comments.

On Tue, Dec 20, 2016 at 7:06 PM, Alia Atlas <[e-mail]> wrote:
> 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.

(The initial author of the draft was Radia and I think the first
version was roughly contemporaneous with the following presentation:
https://www.ietf.org/proceedings/80/slides/trill-4.pdf)

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

Well, I can imagine a range of Informational documents which, at one
extreme were an abstract exploration of possibilities with pros and
cons for each and having no directive content. At the other extreme
would perhaps be a "framework" document that tightly bounded
subsequent protocol specifications deciding most significant design
issues.  This draft started out closer to the abstract end and has
varied some in different version as to how directive it is. The draft
is called "Alternatives..." and does not have "Architecture" or
"Framework" in its title.

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

By listing a number of alternatives, the document is not meant to
imply that any significant number of them are to be further specified.
One advantage of documenting a variety of alternatives is to provide
prior art in case of subsequent IPR problems.  As far as I can tell,
the WG is only interested in defining one very specific way to do
unique nicknames and one very specific way to do aggregated
nicknames. The current state of these are documented in
draft-ietf-trill-multilevel-unique-nickname and
draft-ietf-trill-multilevel-single-nickname.  The "single-nickname"
draft specified an aggregated nickname scheme.

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

OK.

> 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 cannot imply consensus.

The only path the WG is pursuing for aggregated nicknames does not use
the "swap nickname" method discussed in 2.2.2.2, which is just being
listed as an "alternative". I don't see any problem including your
negative points of this alternative in the draft.

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

Many upgrading and backward compatibility considerations are
considered throughout the much. I think Section 7 could be improved
along the lines you suggest.

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

OK.

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

The list in Section 1.1 is meant to be a exhaustive list of potential
scaling problems.  While I wouldn't think that a single level IS-IS
routed area would be particularly practical with several tens of
thousands of routers, whether they are TRILL switches or some other
kind, it seems to me that with multi-level you might some day have 200
areas with 500 routers per area, which would required 100,000
nicknames if they must all be unique. That would be problematic with
16-bit nicknames and people may be reluctant to adopt technology if
they can foresee limits, even if those limits are pretty far away.

Furthermore, nicknames are consumed when pseudo-nicknames are used for
the active-active connection of end stations.  Using RFC 7781 could,
for example, double the nicknames consumption if there are extensive
active-active edge groups connected to different sets of edge TRILL
switch ports.

In addition, there might be problems, as suggested in the draft, with
TRILL switches inside a possibly very large number of level 1 areas
all contending campus wide for nicknames -- so you would likely use
some sort of hierarchical method, for example level 1 areas contending
in level 2 for blocks of nicknames and then TRILL switches inside a
level 1 area contending within that area for nicknames within the
block(s) obtained by that area. Of course such hierarchical allocation
leads to further effective loss of nicknames. (RFC 3194)

So, my opinion is that, overall, it is reasonable to keep the 16-bit
nickname limit in mind and have a solution available that effectively
eliminates that limit.

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

This section can be clarified.

This section is about end station's logical connectivity to edge TRILL
switches.  Multiple topologies could possibly be used to constrain the
logical connectivity between such edge TRILL switches that are
physically connected via a link (TRILL considers a bridged LAN to be a
single link). But end stations don't know anything about TRILL or
IS-IS Areas or multiple topologies. So I don't see how to use
topologies (or areas) to stop an end station from having connectivity
to all edge TRILL switches on the link.

The problem being discussed in Section 6 is that a frame (particularly
a multi-destination frame, say a broadcast frame) sent by an end
station could be seen by multiple TRILL edge switches even if those
edge switches are in different IS-IS areas and thus multiple copies
could be ingressed by the TRILL campus. A similar problem, causing
looping, might occur if a native frame is egressed by an edge TRILL
switch. On egress the TRILL Header is stripped and the resulting
native frame is appropriate for receipt by an end station.  Such a
frame might, if no precautions are taken, be ingressed by one or more
TRILL edge switches in different IS-IS areas.  (Existing TRILL takes
care of the case of multiple edge TRILL switch ports on a link with
end stations when those edge TRILL switches can all see each other, as
they would automatically if they are in the same Area/topology, by the
Appointed Forwarder mechanism.)

I suppose you could tell network managers that if a link has one or
more end stations on it, then all TRILL switch ports on the link must
be in the same IS-IS area, but that seems pretty brittle. TRILL's
design philosophy is to try to protect against accidental
misconfigurations.  I also do not think it is desireable to say that
if you want to use multi-level safely, you have to use and configure
multi-topology.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Regards,
> Alia