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

[Ballot comment]
[*** 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.

[Ballot discuss]
[Updated on 20 June]

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

[20 June] Haven't heard further...

[Ballot comment]

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

[Ballot discuss]
Could you provide use-cases for this extension mechanism? What extensions do you intend to define? How do these extensions fit into your current charter?

[Ballot discuss]


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.

[Ballot comment]

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

[Ballot discuss]
-- 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)?

IANA has reviewed draft-ietf-trill-rbridge-extension-04 and has the following comments:

IANA understands that, upon approval of this document, there is a single IANA action which much be completed.

In the Transparent Interconnection of Lots of Links (TRILL)
Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

a new subregistry will be created. The new subregistry will be
called the "TRILL Extended Header Flags" subregistry. Maintenance
of this registry will be done through Standards Action as defined
by RFC 5226. There are initial registration in the registry as follows:

Bits Purpose Reference
--------------------------------------------------------------------
0-2 Critical Summary Bits [ RFC-to-be ]
3-6 available critical hop-by-hop flags [ RFC-to-be ]
7 Critical Channel Alert Flag [ RFC-to-be ]
8 Non-critical Channel Alert Flag [ RFC-to-be ]
9-13 available non-critical hop-by-hop flags [ RFC-to-be ]
14-16 available critical reserved flags [ RFC-to-be ]
17-20 available non-critical reserved flags [ RFC-to-be ]
21-26 available critical ingress-to-egress flags [ RFC-to-be ]
27-31 available non-critical ingress-to-egress flags [ RFC-to-be ]

IANA understands that this is the only action required upon approval of the document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot comment]
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?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TRILL: Header Extension) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: Header Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF TRILL (Transparent Interconnection of Lots of Links) base
  protocol specifies minimal hooks to safely support TRILL Header
  extensions. This document specifies an initial extension providing
  additional flag bits and specifies two of those bits.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-extension/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-extension/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard as indicated in the title page header. This
document specifies some additional flags for the extension part of the
TRILL header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The IETF TRILL (Transparent Interconnection of Lots of Links) base
protocol specifies minimal hooks to safely support TRILL Header
extensions. This document specifies an initial extension providing
additional flag bits and specifies two of those bits, plus the
Critical Channel Alert Flag used by the channel draft.

Working Group Summary

There was rough consensus in the working group in favor of the document,
with one relatively strong dissenter. The main point of the dissenter
was that the material in this draft is not needed to provide an
RBridge channel that can be used for BFD and error reporting, hence
the extensions are speculative on future standardization that would make
use of them. The WG neverless wants to proceed with this document.

Document Quality

The document has been carefully reviewed in the WG and by the document
shepherd. There are no known implementations of the additional
Critical Channel Alert Flag specified in this document.

Personnel

Who is the Document Shepherd?

Erik Nordmark

Who is the Responsible Area Director?

Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Careful review of the whole document, including looking at its
dependencies to and from rbridge-channel and rbridge-bfd.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures on this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The consensus is reasonably broad.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria apply.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No,

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA Considerations section refers to section 3 in the body of
the document for the initial content of the new subregistry, and
section 3
is consistent with the description in section 2.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

A new subregistry is created by this document called
"TRILL Extended Header Flags", but allocations are subject
to Standards Action and not Expert Review.
Hence no experts are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None. No part of this draft is in a formal language.