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

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?

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.

--

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?

Seems like another bullet to be added to s5.3 is that the swithc needs to check for the Ehtertype?

Thank you for making the changes to the Ethernet assignment.