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 <[email protected]> wrote: > Hi Alia, > > Thanks for your comments. > > On Tue, Dec 20, 2016 at 7:06 PM, Alia Atlas <[email protected]> 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 +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > > Regards, > > Alia >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
