Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling
draft-ietf-trill-fine-labeling-07

[Ballot comment]
I balloted Yes because I like it. The document seems well-written and complete, gives thought to operational aspects and security aspects, and provides good background for readers who might not have been the implementers for TRILL VL, but are now implementing FGL on the next release. I do have some comments, but they're not blocking.

Is this draft about coexistence or migration? I'm seeing both words used in the text. We spent some time talking about this recently ("if you're migrating for decades, you're coexisting").

In this text:

2.2 Base Protocol TRILL Data Labeling

  This section provides a brief review of the [RFC6325] TRILL Data
  packet VL Labeling and changes the description of the TRILL Header by
  moving its end point. This descriptive change does not involve any
  change in the bits on the wire or in the behavior of VL TRILL
  switches.

I found "this descriptive change" confusing on first read. Perhaps "this change in description" might be clearer.

Thanks to the WG for describing the things that could happen when you send FGL frames to a switch that's not FGL-safe.

In Appendix A, I found a "unicat" - guessing that's a typo.

[Ballot comment]
Throughout: I assume that "campus" is a well-understood term of art in this area? This was not a familiar use to me.

4.1:

  It MUST be possible to configure the ports of an FGL-edge TRILL
  switch to ingress native frames as FGL.

I don't understand this requirement. Are you simply saying, "An FGL-edge TRILL switch MUST ingress native frames. It MAY ingress them or FGL or MAY ingress them as VL, depending on local configuration."? If so, say that. Otherwise, it sounds like you're saying, "The purchase order for buying an FGL switch MUST say that it is configurable to...", which is silly.

  FGL-edge TRILL switches MUST support configurable per port mapping
  from the C-VLAN of a native frame, as reported by the ingress port,
  to an FGL.

See above. What is the protocol requirement you are trying to express?

[Ballot comment]
I am entering these notes as Comments because I am actually not too
bothered whether you address them or not. I do not believe that
failure to address my points will result in a less stable or useful
internet.


I think that you might make your document more easily used and
clearer for people trying to understand the technology if you find
ways to answer the points in your text.

---

I found that the Abstract and Introduction are not clear on the
motivation for this work.

The number of IDs supported is not a direct statement of the granularity
of labeleing.

Thus, the motivation needs to be clarified. Is the requirement to
increase the number of labels available? Or is the requirement to
enable subdivision of existing labels to increase granularity?

---

I am trying to understand why it is necessary to include the Ethertype
twice in order to stack the label. Surely the first 893b provides
sufficient information that what follows will be two label values.

I shouldn't be surprised to find that the answer is in bullet 2 of
section 2.1, or maybe it is to do with 32 bit alignment, but this sort
of design choice probably needs to be called out if you don't want
future generations to become confused or even break Trill.

But the way things are constructed means that you should also handle the
case where the second Ethertype has a different value.

---

Like Stewart, I am surprised that you have chosen to limit the label
stack to exactly two components: a high part and a low part. This seems
remarkably un-forward-looking given the experience we have of the value
of deeper label stacks in other technologies.

---

The description of the fields in the two parts of the label in Section
2.3 seems to be incomplete. I find:


  The two bytes following each 0x893B have, in their low order 12 bits,
  fine-grained label information. The upper 4 bits of those two bytes
  are used for a 3-bit priority field and one drop eligibility
  indicator (DEI) bit.

  The priority field of the Inner.Label High Part is the priority used
  for frame transport across the TRILL campus from ingress to egress.
  The label bits in the Inner.Label High Part are the high order part
  of the FGL and those bits in the Inner.Label Low Part are the low
  order part of the FGL.

This omits:
- In what order are the priority field and DEI arranged?
- What is the meaning of the priority field in the low part?
- What is the meaning of the DEI in the low part?
- What is the link between the label format here and that in 6325 where
  the 3-bit priority field is accompanied by a "C" bit?

I know that some of the answers appear later in the document, but it
seems odd that you describe some fields, but not all of them, and it
looks like not all questions do actually get answered.

---

Section 3 has:

  It is the responsibility of the network manager to properly configure
  the TRILL switches in the campus to obtain the desired mappings.

This seems to leave quite an opening for fat fingers. What mechanisms
are provided to assist the operate in detecting her mistakes? Do you
have defaults you can recommend for "out of the box" behavior?

[Ballot comment]
I am sympathetic to stuart's discussion point.

as I noted there is historical precedent for setting the registration of an ieee registerd resource to IANA (rather than to a working group or individual.

--

[Ballot discuss]
My discuss originally said:

"I see that Ethertype 893B is owned by IETF TRILL Working Group, 155 Beaver Street, Milford MA 01757, UNITED STATES. It is unusual for an IETF WG to own codepoints in other SDOs, and in any case I do not recognize that address as a normal IETF address. Who owns change control and IPR for Ethertype  893B? Why is this not clearly an IETF assignment  at IETF main office."

From the ensuing discussion I think that the policy of the IETF should be that the Etherypes of its protocols point to a formal IETF contact address. What we do about historic Ethertypes is a different matter to what we do going forward. I will clear this when the IESG has agreed the best way to move forward on this and that policy is enacted.

[Ballot comment]
I think a more precise definition of Ethertype 893B is required that is provided by this draft. Specifically it looks like the structure 893B/lower/893B/upper is the only structure allowed and the draft should be more emphatic on this.

[Ballot discuss]
This is a Discuss-Discuss and needs to be addressed by the responsible AD. As far as I can see this extension to the TRILL protocol that is not covered by the current TRILL charter. I would like to discuss with IESG whether my interpretation of the charter is correct, and if so what actions are appropriate.

I see that Ethertype 893B is owned by IETF TRILL Working Group, 155 Beaver Street, Milford MA 01757, UNITED STATES. It is unusual for an IETF WG to own codepoints in other SDOs, and in any case I do not recognize that address as a normal IETF address. Who owns change control and IPR for Ethertype  893B? Why is this not clearly an IETF assignment  at IETF main office.

In any case I think a more precise definition of Ethertype 893B is required that is provided by this draft. There is text that implies that a double nesting of 893B is required, is this the only nesting that is allowed?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-trill-fine-labeling-06.txt.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA notes that one of the IANA actions requested in this document is dependent on actions requested in another yet-to-be-approved Internet-Draft.

IANA understands that upon approval of this document, there are two actions which IANA needs to complete.

First, IANA understands that the request to register Ethertype 0x893B for use as the TRILL FGL Ethertype has been completed by the IEEE registration authority and that IANA need take no further action.

Second, IANA understands that the authors regues a capability bit [value TBD] in the TRILL-VER sub-TLV capability sub-registry that will be created by the approval of draft-ietf-isis-rfc6326bis.

IANA understands that these are the only actions required upon approval of this 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling) 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 (Transparent Interconnection of Lots of Links): Fine-Grained
  Labeling'
  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 2013-05-08. 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 has standardized TRILL (Transparent Interconnection of Lots
  of Links), a protocol for least cost transparent frame routing in
  multi-hop networks with arbitrary topologies and link technologies,
  using link-state routing and a hop count. The TRILL base protocol
  standard supports labeling of TRILL data with up to 4K IDs. However,
  there are applications that require more fine-grained labeling of
  data. This document updates RFC 6325 by specifying optional
  extensions to the TRILL base protocol to safely accomplish this.





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

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1688/

(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 is requested and noted in the title page header.
  This document specifies an optional extension to the IETF TRILL
  protocol, updating RFCs 6325 which is a Proposed Standard.

(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 TRILL base protocol supports labeling of TRILL Data packets
  with up to 4K IDs. However, there are applications that require
  more fine-grained labeling of data for configurable isolation based
  on different tenants, service instances, or the like. This document
  updates TRILL by specifying an optional extension that supports an
  additional 2**24 labels, called fine-grained labels (FGLs).
  Provisions for mixed networks of TRILL switches that do and do not
  support FGLs are provided.

Working Group Summary:

  The two primary points of discussion in the WG were how to encode
  fine grained labels and how to handled mixed networks.

  Early versions of FGL, for maximum backwards compatibility with the
  TRILL base protocol, made a non-standard use of an Ethertype
  assigned to another group as part of FGL encoding, but this ws not
  allowed by the asignee of that Ethertype. So the encoding was
  changed to use a new Ethertype allocated for TRILL FGL. After
  discussion, the consensus of the working group was to use
  an encoding structure optimized for support by existing fast path
  silicon, although this is not the most compact encoding.

  For handling mixed networks, the problem to be solved was how to
  avoid giving an FGL TRILL Data packet to a TRILL switch not
  supporting FGL that might mishandle it. The WG decision was to
  avoid methods that would require silicon changes or additional
  shortest path calculation, yet have the protocol be robust against
  mixtures of old and new TRILL switches.

Document Quality:

  The document has been reviewed by participants from the TRILL
  vendors that appear to plan to implement this specification.
  The document shepherd has reviewed the document in its most recent
  form.

Personnel:

  Erik Nordmark is the Document Shepherd.
  Ted Lemon is the Responsible Area Director.

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

  Looked at the document for editorial clarity, especially in the area
  of how old TRIL switches and FGL TRILL switches interact.
  This resulted in some editorial restructuring of the document.

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

  There is no such need.

(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? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No special concerns.

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

  Yes - https://datatracker.ietf.org/ipr/1688/
  The WG was made aware of that first by the secretariat's IPR Disclosure on 2/24/12.
  On 11/8/12 the document shepheard reminded the WG of this IPR, and included a
  reference to rfc3979.
  There has been no discussion of that IPR on the mailing list or at the WG meetings.

(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?

  There is a solid consensus for the document.
  One individual raised concerns at the Atlanta IETF meeting that the
  FGL encoding could be simplified to have a single 24 bit field instead
  of 2x12 bit fields. There did not seem to be any uptake on that idea
  in any subsequent discussions.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  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.

  idnits is clean. There is a note regarding pre-RFC5378 work which we will
  address and the expected warning about possible downref for ISO/IEC 10589
  (the IS-IS ISO standard).

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

  This document requires no such formal review.

(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. The above notes IS-IS warning is due to idnits not knowing about
  the standards status for ISO specifications.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  Verified that the IANA considerations section is consistent with the
  document text (merely a request for a capability bit).

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

  This document creates no new IANA registries.

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

  No sections of the document are written in a formal language
  requiring such validation.