Transparent Interconnection of Lots of Links (TRILL): Header Extension
draft-ietf-trill-rbridge-extension-05

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?

[*** 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.

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,..."

I had questions that overlapped a subset of Adrian's COMMENT, so would encourage the authors and AD to pay attention to his ballot.