Hi David, Thanks for this very thorough review. See my responses below: On Sat, Mar 29, 2014 at 10:23 PM, Black, David <david.black@xxxxxxx> wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-trill-esadi-06.txt > Reviewer: David L. Black > Review Date: March 29, 2014 > IETF LC End Date: April 1, 2014 > > Summary: This draft is on the right track, but has open issues > described in the review. > > This draft revises the ESADI specification for TRILL from its > original form in RFC 6325. > > Major issues: > > The draft changes ESADI in a non-backwards-compatible fashion from > its original specification in RFC 6325, but does not explain why this > is ok. That explanation needs to be provided, and if implementations > of ESADI as originally specified in RFC 6325 exist, that explanation > needs to encompass coexistence and interoperability (or lack thereof) > with such implementations. That explanation probably belongs in > Section 1.1, and could be expanded upon in Appendix A. This was a considered decision of the TRILL WG. At least since the -02 version in February 2013, the ESADI WG draft has had ESADI-LSP provisions that were incompatible with RFC 6325 ESADI for the purpose of accomodating orders of magnitude more LSP fragments. This text in the draft, which originally used a somewhat ad hoc change from IS-IS LSPs to accomodate additional fragments, was posted to the list without objection before being incorporated. Since a standard IS-IS way of doing this was later in process in the ISIS WG, the ESADI draft was changed to follow this more standard way of providing for more LSP fragments and a new WG Last Call done in the TRILL WG specifically on this issue. See http://www.ietf.org/mail-archive/web/trill/current/msg06037.html http://www.ietf.org/mail-archive/web/trill/current/msg06009.html In Appendix A (Changes to [RFC6325]), how about replacing items 2 and 3 in the list as follows (includes fixing a typo in item 3): OLD 2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is changed from the base IS-IS format to the Extended Level 1 Circuit Scoped format in [FS-LSP]. NEW 2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is changed from the base IS-IS format to the Extended Level 1 Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This change is not backwards compatible with [RFC6325]. It is made in light of (a) the very limited, if any, deployment of [RFC6325] ESADI, and (b) the 256 times greater information carrying capacity of the E-L1CS format compared with the base IS-IS format. It is anticipated that this greater carrying capacity will be needed, under some circumstances, to carry end station addressing information or other information that is added to ESADI in the future. OLD 3. Unicasting of ESADI PDUs is supported including replacing Section 4.6.2.2 of [RFC6325] with the next text give in Section 4.1 of this document. NEW 3. Unicasting of ESADI PDUs is optionally supported including replacing Section 4.6.2.2 of [RFC6325] with the new text give in Section 4.1 of this document. This unicast support is backwards compatible because it is only used when the recipient RBridge signals its support. See possible replacement below for the first paragraph of Section 1.1 that includes a condensed version of this additional material concerning backwards non-compatibility. > Overall, this draft is not self-contained - to a significant extent, > it is written as if it were effectively a long collection of errata > to the ESADI specification in RFC 6325. That makes it difficult to > understand - it would be better if this draft completely obsoleted > and replaced the ESADI specification in RFC 6325, describing its > changes, instead of providing specific text changes to portions of > the RFC 6325 text. All of the changes to ESADI are described in Appendix A. If the ESADI related material in RFC 6325 was entirely contained in one contiguous area of RFC 6325, it would have been easy to write this draft as simply obsoleting and replacing that area of RFC 6325. The largest such monolithic block on ESADI in RFC 6325 is Section 4.2.5 (The TRILL ESADI Protocol), including its two subsections ("4.2.5.1 TRILL ESADI Participation" and "4.2.5.2 TRILL ESADI Information"). All of that is obsoleted and replaced by this draft. However, there are other non-contiguous parts of RFC 6325 necessarily affected. For example, Section 4.6 of RFC 6325 describes how to handle every possible type of frame that might be received; since an ESADI PDU is one such type of frame, it is necessary to change Section 4.6.2.2 ("TRILL ESADI Frames") of RFC 6325. There is really no substitute for having a general familiarity with RFC 6325 in understanding this document. Although I have seen IESG members criticize statements such as "Familiarity with X is assumed." when X is a normative reference, on the grounds that familiarity with all normative references is automatically assumed, perhaps some such statement is warranted in this case. In addressing both of your issues here, the first paragraph of Section 1.1 could be changed as follows: OLD This document updates [RFC6325], the TRILL base specification, replacing the description of the ESADI protocol in Section 4.2.5 of [RFC6325], providing more detail, and prevailing over [RFC6325] where they conflict. The changes are summarized in Appendix A. These changes are not backwards compatible because, among other things, they change the format of ESADI-LSPs. NEW This document updates [RFC6325], the TRILL base protocol specification, obsoleting and replacing the description of the ESADI protocol (Section 4.2.5 of [RFC6325] including all subsections), providing more detail on ESADI, updating other ESADI related sections of [RFC6325], and prevailing over [RFC6325] in any case where they conflict. For this reason, familiarity with [RFC6325] is particularly assumed. These changes are not backwards compatible because they change the format of ESADI-LSPs to substantially increase the amount of information that can be carried. These changes are further discussed in Appendix A. > Minor issues: > > I don't understand the discussion in section 2 of it being "an > implementation decision how independent the multiple ESADI instances > at an RBridge are" in light of the clear statement that "the ESADI > update process operates separately for each ESADI instance." The > example given involves database structure considerations that are > specific to the node implementation and do not affect the independent > updates for each ESADI instance. There may not be an actual > technical problem here, but at least the first chunk of text quoted > in this paragraph of the review needs to be rewritten. Two things motivated the text you cite in Section 2: (1) ESADI uses multiple instances of the flooding process for the purpose of limiting the flooding to the TRILL switches that have expressed interest in a particular Data Label. RFC 6822 specifies a different type of IS-IS "instance" and there is some implication in 6822 of fault and performance isolation between RFC 6822 instances. Although this document says its instances are not the same as RFC 6822 instances, someone might still have the impression that ESADI instances are necessarily to be implemented inside a TRILL switch is a highly isolated manner. This text is to emphasize that the extent to which the execution of different ESADI instances are isolated within a TRILL switch is an implementation decision. (2) Perhaps a symptom of item 1: in early discussions of ESADI, there were multiple complaints that maintaining 'so many different link state databases' in a TRILL switch would be an undue burden. So the text here specifically mentions that the databases for all ESADI instances at a TRILL switch can be merged (with an appropriate marker in each record saying which instance it belongs to). While the IETF generally standardizes bits on the wire and not internal implementation details, the above concerns lead to these few sentences to dispel any false impression. I do not really see how there can be much confusion since the draft also says, as your point out, "But the ESADI update process operates separately for each ESADI instance and independently from the TRILL IS-IS update process.". I suggest the following change: OLD It is an implementation decision how independent the multiple ESADI instances at an RBridge are. NEW This specification does not constrain how coupled or independent the multiple ESADI instances are in their implementation internal to an RBridge. > Also in Section 2: > > ESADI does no routing so there is no reason for pseudo-nodes in ESADI > and none are created. > > Need to explain what a pseudo-node is before this sentence. I do not think this document is the right place for a detailed explanation of pseudo-nodes. How about changing to the following: ESADI does no routing calculations so there is no reason for pseudo-nodes in ESADI and none are created (Pseudo-nodes [IS-IS] are a construct for optimizing routing calculations.) > p.9, Figure 2 - explain how the receiver determines whether the inner > Ethernet header contains a VLAN tag or FGL. This also applies to Figure > 3 on p.10. I'm not sure this draft is the place for a detailed explanation but I have no problem adding the already existing reference "[RFCfgl]" to both figures right after where they say "VLAN or FGL Data Label (4 or 8 bytes)". That referenced document [RFCfgl], which is in the RFC Editor's queue, explains this. > p.10, Section 2.1: > > All transit RBridges forward ESADI packets as if they were ordinary > TRILL Data packets. > > Need to explain what a "transit" RBridge is. Between this and the > above pseudo-node comment, I suggest adding an overview of the > TRILL protocol to the start of Section 2. How about just eliminating the word "transit", which I don't think is necessary, and changing the sentence in question to All RBridges forward ESADI packets as if they were ordinary TRILL Data packets [RFC6325]. > p.11, Section 2.1: > > No "routing" computation or routing decisions ever have to be > performed by ESADI. > > What is a ' "routing" computation' ?? This should be rephrased to > contrast to what the non-ESADI TRILL usage of IS-IS does. How about the following change: OLD No "routing" computation or routing decisions ever have to be performed by ESADI. NEW No "routing" calculation (least cost path or distribution tree construction) ever has to be performed by ESADI. > p.12, Section 2.2: > > If a VLAN or FGL ID > field within an ESADI-LSP PDU does include a value, that field's > contents is ignored. > > This looks like it's an important requirement, so: > "is ignored" -> "MUST be ignored" OK. > p.13, Section 3 > > "SNPA/MAC address" > is not considered in this tie breaking and there is no "Port ID". > > This is contrasting ESADI tie-breaking to a tie-breaking procedure > that I'd guess is specified in another document; that needs to be > explained, along with a reference to that document, preferably with > the section number where the other tie-breaking procedure is > specified. The other document is [rfc6327bis] which is referenced. However, this reference can be made clearer. How about OLD Generally speaking, the DRB election on the ESADI virtual link (see Section 2.1) operates similarly to a TRILL IS-IS broadcast link [rfc6327bis] with the following exceptions: NEW Generally speaking, the DRB election on the ESADI virtual link (see Section 2.1) operates similarly to the DRB election on a TRILL IS-IS broadcast link, as described in Section 4.2.1 ("DRB Election Details") of [rfc6327bis], with the following exceptions: > Section 6 - explain where the 1470 byte number in the third > paragraph comes from. How about adding the following at the end of the relevant paragraph, just before the Section 6.1 header: (As stated in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to make it extremely unlikely that a TRILL control packet, even with reasonable additional headers, tags, and/or encapsulation, would encounter MTU problems on an inter-RBridge link.) > Section 8 - more should be said on whether/when the Authentication > TLV should be used when ESADI conveys information from an > authenticated registration. In particular, if this recommendation > for usage of the Authentication TLV with information from an > authenticated registration usage is not a "SHOULD" or "MUST", an > explanation is in order. Consider the following: we have a network with secure trunk links between trusted TRILL switches but in some cases those switches are connected to end stations via 802.11 Wi-Fi links. It seems entirely reasonable to use 802.11 authentication in allowing end stations to connect due to the inherent accessiblity of radio links, but might not be necessary to use authentication on ESADI PDUs between TRILL switches. In any case, if there is a concern about forged packets, the IS-IS LSPs in the TRILL campus should be authenticated and, in that case, the ESADI PDUs will be authenticated by default as provided in Section 6.3 of this draft. How about adding a new paragraph to Section 8, between the current first and second paragraphs, incorporating the above, such as: However, there may be cases where it is not necessary to authenticate ESADI PDUs despite using authenticated registration for end stations. For example a TRILL campus with secure RBridges and inter-RBridge links configured as trunks but some end stations connected via 802.11 wireless access links might use 802.11 authentication for the connection of such end staions but not necessarily authenticate ESDAI PDUs. Note that if the IS-IS LSPs in a TRILL campus are authenticated, perhaps due to a concern about forged packets, the ESADI PDUs will be authenticated by default as provided in Section 6.3. > Nits/editorial comments: > > There are lots of acronyms that are not expanded on first use, > defined in the terminology section, or otherwise explained, e.g., > DRB, Sz, CSNP, PSNP. It may be ok to point to terminology/acronym > definitions in RFC 6325. I believe these are all defined/expanded in RFC 6325 but it would still be a good idea to expand them on first use in this document. > Last sentence on p.8: > > OLD > The outer VLAN tag will not be present if it was stripped by > an Ethernet port out of which the packet was sent. > NEW > The outer VLAN tag will not be present for a packet on an > an Ethernet link that does not use VLAN tags. Well, whether or not any particular Ethernet frame carrying a TRILL Data packet is VLAN tagged or not depends on whether the port sending that frame is configured to send it tagged or untagged. There is no requirement or enforcement mechanism that all the ports on that Ethernet link be identically configured in this regard. So I do not consider it to be a property of the link. Also, Appendix A item 1: replces -> replaces Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx > idnits 2.13.01 got confused by the Section 4.6.2.2 reference to > RFC 6325 in Section 4.1, and thought 4.6.2.2 was an IPv4 address - > this is not a problem. > > idnits also warned about possible pre-RFC5378 (2008) content. This > is probably not a problem, but please check with your AD. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ----------------------------------------------------