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

[Alia Atlas <[e-mail]>]

I have done another AD review of the updated version,
draft-ietf-trill-rbridge-multilevel-04.

In general, it is much better.  I would have preferred to see more
operational considerations around
transitioning from a single area to a multi-level domain, but at least some
concerns are sprinkled in.

I'm going to request IETF Last Call on this and target it for the telechat
on July 6.

Nits:

a) Sec 6:"The problem is not avoiding adjacency of avoiding TRILL Data
packet transfer between RB1 and RB2."   s/of/or

b) Sec 6: "The problem stems from end stations being TRILL ignorant so
   care must be taken that multiple RBridges on a link do not ingress
   the same frame originated by an end station and so that an RBridge
   does not ingress a native frame egressed by a different RBridge
   because it mistakes if for a frame originated by an end station."
   s/it/the RBridge    s/if/the frame

c) Sec 6: "if a TRILL switch seems Hellos from lower numbered areas"
  s/seems/sees

Regards,
Alia

On Mon, Dec 26, 2016 at 5:04 PM, Donald Eastlake <[e-mail]> wrote:

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