Transparent Interconnection of Lots of Links (TRILL): Header Extension
Note: This ballot was opened for revision 04 and is now closed.
(Ralph Droms) Yes
(Ron Bonica) (was Discuss) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
(Wesley Eddy) No Objection
Comment (2012-06-04 for -04)
I had questions that overlapped a subset of Adrian's COMMENT, so would encourage the authors and AD to pay attention to his ballot.
(Adrian Farrel) No Objection
Comment (2012-06-04 for -04)
I have no objection to the publication of this document. I have a number of questions and issues you might want to look at before the document is published as an RFC. --- Does this document update 6325? --- Abstract say... This document specifies an initial extension providing additional flag bits and specifies two of those bits. The Introduction says... This document specifies an initial extension providing additional flag bits and specifies one of those bits. Anyway, it appears you define the meaning of three bits (if you include CRSVS). And, through the definition of the structure, you sort of define the meaning of the others. --- If there is an indication that at least one CHbH option present, does each hop have to scan all options to check whether they are relevant? This seems to be a compounding factor for the note in Section 2. The note is good, but I wonder what the consequences is of an increased likelihood of dropping a packet with a hop-by-hop critical option. --- In section 2 o flag affecting an as yet unspecified class of RBridges, for example border RBridges in a TRILL campus extended to support multi-level IS-IS It seems odd that if the class of RBridges is unspecified, you can give an example like this. I suggest that you rebrand this flag as reserved for future extensions, or go to the trouble of defining its real use. The same ambiguity arises in the text describing CRSVS in 2.3.1 BTW s/flag/flags/ ? --- Section 2 if it is a known unicast frame Are there unicast frames where it is impossible to know that they are unicast? --- Section 2.3 (The first two critical summary bits are as specified in [RFC6325]. In this document an "S", for Summary, has been added at the end of their acronyms.) Bit(s) Description --------------------- 0-3 Crit.: Critical summary bits. 0 CHbHS: Critical Hop-by-Hop extension(s) are present. 1 CItES: Critical Ingress-to-Egress extension(s) are present. 2 CRSVS: Critical reserved extension(s) are present. The bracketed text is a little confusing. There are indeed only two summary bits defined in 6325. There is a third bit defined here. All three bits have been given an "S" suffix. --- Is section 2.4 simply egg sucking, or is there something else that needs to be explained?
Stephen Farrell (was Discuss) No Objection
Comment (2012-06-07 for -04)
This used to be a discuss but since I'm told that the folks in the WG who care already know I'm making it a comment. "I don't understand the security model for the ingress-to-egress extensions. Given that hop-by-hop extensions can be modified/dropped, there can be no ingress-to-egress cryptographic security, however this is not stated. Were it stated, it would appear to make all extensions hop-by-hop, at least in terms of (non)end-to-end security. Either that or you need a quite complex set of security mechanisms, which I assume you don't want. Or, perhaps the WG were happy that introducing extensions like this, means never being able to use cryptographic security and extensions between ingress and egress? (Or some highly complex in-between state.) I'm not looking for any specific change for now, but rather just to understand what's the expectation here for e2e-like cryptographic security." - Pure opinion from a TRILL-ignoramus: this seems over complex to me. - I don't get how the TLVs are encoded, and associated with the various flag fields, e.g. CItE etc. That may be "obvious" but I didn't get it at all sorry. - I don't get how extended flag thing is supposed to work. How is someone supposed to know when to allow addition of the bicycle extension? - This: "Any extended flag indicating a significant change in the structure or interpretation of later parts of the frame which, if the extended flag were ignored, could cause a failure of service or violation of security policy MUST be a critical extension. If such an extended flag affects any fields that transit RBridges will examine, it MUST be a hop-by-hop critical extended flag" seems like it'd be a fine source for useless rathole arguments. - What does: "A transit or egress RBridge may assume that the critical summary bits are correct." mean? - This seems very odd: "Conflicting extensions SHOULD NOT be defined, but if they are,..."
Brian Haberman No Objection
(Russ Housley) No Objection
Barry Leiba (was Discuss) No Objection
[*** This was addressed in the -05 version; thanks. ***] -- 5 -- Please explain (briefly -- a sentence or two will surely do) the reason for selecting Standards Action for this registry. I'd prefer it if that sentence or two were in the IANA Considerations, unless there's a reason not to put it there. I understand that there is a limited number of bits to be given out, so freely allocating them for the asking would be harmful. Still, Standards Action is very heavyweight: did you consider IETF Review (which could allow Informational or Experimental documents to do allocations, with community consensus and IESG approval), or even Specification Required (where you could give instructions that the designated expert exert tight control over the allocations)? [5 June, Don responds] > On consideration, I think you are correct that Standards Action is too > heavyweight. However, I also think that Specification Required would > be too lightweight considering the small number of bits available and > the fact that a few of them are already proposed for allocation in > existing various drafts... > > I will check with the co-authors & WG to see if there is any objection > to changing to IETF Review.