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
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
