Hi Donald, I think we're basically done here. For [4], I would like to see stronger requirements in the security text, but I can accept what's proposed below as an improvement. Please ensure that a good security reviewer (e.g., a sec-dir reviewer) takes a look at that new text as well as the rest of the security considerations. Everything else below is fine with me. Thanks, --David > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] > Sent: Wednesday, April 09, 2014 10:12 AM > To: Black, David > Cc: zhai.hongjun@xxxxxxxxxx; hu.fangwei@xxxxxxxxxx; Radia@xxxxxxxxxxxx; > ostokes@xxxxxxxxxxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx); > trill@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt > > Hi David, > > On Tue, Apr 8, 2014 at 4:58 PM, Black, David <david.black@xxxxxxx> wrote: > > Donald, > > > > Thank you for the extensive comments on the review. I'll summarize here > > rather than add more text inline. I'm fine with the proposed course of > > action for anything not mentioned here: > > OK. It is good sign when the amount of text being written with each > exchange starts to shrink rather than grow :-) > > > [1] Absence of backwards compatibility: > > - The Appendix A changes look good. > > - The "limited deployment" (and presumably also "limited > > implementation") rationale for no backwards compatibility > > should be included in Section 1.1. This merits additional > > text in Section 1.1 > > OK. We could add a few more words to the proposed new version of the > first paragraph in Section 1.1 as follows: > > NEWER > 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 include a change > to the format of ESADI-LSPs that is not backwards compatible; this > change is justified by the substantially increased amount of > information that can be carried in light of the very limited, if > any, deployment of [RFC6325] ESADI. These changes are further > discussed in Appendix A. > > > [2] Structure of draft wrt RFC 6325: > > I think the rest of the proposed changes to Section 1.1 are > reasonable: > > > > - Appendix A does explain what's changed. I would have liked to see > > more formality/precision in Section 1.1, but that's a matter > of > > editorial taste that I'll leave to the authors. The > proposed > > addition of a forward reference to Appendix A will > definitely > > help. > > - The proposed addition of an explicit statement about expecting > > familiarity with RFC 6325 in Section 1.1 will also help. > > > > [3] Independence of ESADI instances: What bothered me was the absence of > > a strong mention of implementation structure - I have some new text to > > suggest to strengthen that point: > > > > OLD > > It is an implementation decision how independent the multiple ESADI > > instances at an RBridge are. > > NEW > > Multiple ESADI instances may share implementation components within > > an RBridge as long as that sharing preserves the independent operation > > of each instance of the ESADI protocol. > > > > Then the link state database example that follows makes more sense, > > at least to me. > > I'm OK with the wording you suggest. > > > [4] Section 8 Authentication TLV usage discussion. > > > >> 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 stations but not > >> necessarily authenticate ESADI 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. > > > > These seems a bit descriptive, with most of the text describing a > > specific example. I'm looking for some more prescriptive guidance > > about what SHOULD (or perhaps should?) be the case when the Authentication > > TLV is not used with authenticated registration. > > Well, a more general statement of the criteria for such cases could be > added such as below: > > However, there may be cases where it is not necessary to > authenticate ESADI PDUs despite using authenticated registration > for end stations because of a significant threat of forged packets > on end station links when that threat is not present for > inter-RBridge trunks. 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 stations but > not necessarily authenticate ESADI 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. > > > [5] VLAN tag presence (nit) > > > >> > 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. > > > > I don't think the word "stripped" is right, as it would not apply if > > the tag wasn't present in the first place, although I also agree with > > your comment that my suggested use of "link" isn't right, either. > > > > Here's another suggestion: > > > > The outer VLAN tag will not be present if it was not included > > by the Ethernet port that sent the packet. > > I agree that "stripped" is not a very good word to use. I'm OK with > your suggested wording. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@xxxxxxxxx > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] > >> Sent: Saturday, April 05, 2014 11:23 AM > >> To: Black, David > >> Cc: zhai.hongjun@xxxxxxxxxx; hu.fangwei@xxxxxxxxxx; Radia@xxxxxxxxxxxx; > >> ostokes@xxxxxxxxxxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx); > >> trill@xxxxxxxx; ietf@xxxxxxxx > >> Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt > >> > >> 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 > >> > ---------------------------------------------------- > >