Transparent Interconnection of Lots of Links (TRILL): Fault Management
draft-ietf-trill-oam-fm-11

Donald helpfully points out that my Discuss has confused

> "TRILL Verison Sub-TLV" which is initially specified in
> [RFC7176], Section 2.3.1
and
> "the so-similar-as-to-be-confusingly named "Port TRILL
> Version Sub-TLV" in Section 2.2.4 of [RFC7176].

...so I am happy to clear my Discuss.

The following Comments remain and are being discussed with the authors.

===

A recent conversation with an ITU-T OAM expert wrt a different I-D 
yielded the following. I think this aplies to your document, too.

> Please note that the reference to Y.1731 is not correct.
> Since the approval in 2011 the recommendation number
> has changed to indicate that it is under responsibility of
> SG15. Also the most recent version is dated 11/2013.
>
> So I suggest that the current reference:
>    [ITU-T.Y.1731-2011]
>               ITU, "ITU-T Recommendation Y.1731: OAM functions and
>               mechanisms for Ethernet based networks", ITU-T
>               Recommendation Y.1731, 2011.
> Is changed into:
>    [ITU-T.Y.8013-2013]
>               ITU, "ITU-T Recommendation G.8013/Y.1731: OAM functions and
>               mechanisms for Ethernet based networks", ITU-T
>               Recommendation G.8013/Y.1731, 2013.

---

You might look for consistency between "Ethertype" [RFC7174], and 
"Ether Type" and "EtherType" as used in this document.

---

3.2.1

   Such frames MUST be discarded.

Do you advise this to be silent, counted, logged?

---

I think a short piece of text is needed (somewhere around 3.2.1 or
3.3?) to describe how a legacy implementation will react to receiving a
frame with the A flag set. In fact, 3.3 of 6325 tells us about this, so
most of this can be done by reference. But it is important in the 
context of OAM to consider what happens when the intended transit 
recipient of an OAM frame simply and legally forwards a packet.
Similarly, it is important to consider what happens at an end station
that does not recognise the A flag.

Probably you would be noting in 3.3 that a legacy implementation will 
not know about the O and B flags to say that it does not support OAM,
but that according to RFC 7176 those lags will be transmitted as zero
so the absence of OAM support will be inferred. Furthermore, I think
that the TRILL Version sub-TLV could be absent, so you need to state
that this must be taken to mean that OAM is not supported.

---

3.2.1

   Frames with the "A" flag set that do not contain CFM EtherType
   are not considered as OAM frames. Such frames MUST be discarded.

No objection if you have thought through the consequences. In the future
there is the posibility that a new use of the Alert flag will motivate
the use of a diferent EtherType. However, in that case, you will not be
able to get frames to pass through legacy nodes. That might be OK (all
nodes on the path are assumed to have been upgraded) or very annoying
(the new function is only needed at key RBridges on the path).

I don't need to dicuss this: just be sure you are doing what you want to
do.

---

Format of 4.3.1 is messed up by tabs.

---

I find it a little bit bothersome that this document and RFC 7174 uses
slightly different terminology from that set out in Y.1731. For example,
MEP is "MEP - Maintenance End Point" with a reference to [RFC7174] and
[8021Q], while Y.1731 (and correlated in RFC 6371 etc.) has "MEG end 
point".

Pretty sure this ship has sailed and that the authors will claim that
allignment with 8021Q is more important than allignment within the IETF,
but there you go... I'm bothered.

---

I tend to agree with you in 6.1 that
   Hence,
   explicit addressing of MIPs is not required for the purpose of
   fault isolation.
But I would like to raise the concern expressed by ITU-T OAM experts
wrt multiple MIPs within a single RBridge. We saw this discussion in
MPLS-TP (see RFC 7054) and it led to the need for some identification
of MIPs.

BTW, I think that, technically, you are talking about the addressing of
MIPs in OAM request messages. I think that when a MIP responds it does
need to identify itself, so you *do* need MIP identifiers.

---

Shouldn't 8.1 describe the OpCode field? Just a smmary and pointer to
8.2.

---

In 8.4.4 you have...

   Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
   nickname. All other values reserved.

   Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge
   nickname.

   Reply Address (variable): Address where the reply needed to be
   sent. Length depends on the address specification.

The description of the Repply Address accurately states that the length
of the field depends on the address specification, but that's not the
future-proof model you are aiming for when you include the Addr Length
field. I think you need...

   Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
   nickname. All other values reserved.

   Addr Length (1 Octet). Dependent on the Address Type. Currently 
   defined values are 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge nickname.
   Other lengths may be acceptable for future Address Types.

   Reply Address (variable): Address where the reply needed to be
   sent. The length of this field is defined by the value of the Addr
   Length field.

Also

   Length (2 octets) = Variable. Minimum length is 2.

Surely you have to have at least a TRILL nickname, so the minimum value
is 4 (Address Type, Addr Length, nickname).

---

8.4.5 needs to describe the Reserved field.

Maybe best to take the text in 8.4.3 and lift it to some common part of
the document where you can say "all fields in this document marked as 
reserved..."

---

8.4.7 and 8.4.9

   Length (2 octets) = variable. Minimum value is 2.

Surely 1.
That is nOfnicknames could be set to 0.

Also, please describe the nOfnicknames field and clarify how it relates
to the Length field.

---

8.4.8

   Length (2 octets) = 4.

Are you sure? it looks like 5 in the figure.

---

8.4.12

    Length (1 octet) =97.

8.4.13

   Length (1 octet) = variable length

I think it is a 2 octet field in both cases.

---

10.1.2 provides a list of TLVs for inclusion. The way this is presented
implies that the ordering is sensitive. The text should clarify this 
point.

Similar issues in other sections.

Thanks for writing this document. I've read through it (not claiming full understanding), and only had two small comment:

There are several statements of the form:

   The CPU of the RBridge validates the frame ...

While this represents the typical implementation, or perhaps even the only reasonable implementation at this point in time, I'd suggest that an IETF specification should not dictate what part of an implementation performs packet validation and other tasks. Just saying the RBridge validates the frame should be enough, in my opinion.

Also, the document has statements of the form:

   Registry: TRILL OAM Return Codes.
   Registration Procedure: Standards Action.

and I believe it would be useful to reference RC 5226 for understanding what is meant by the various procedure names.

Thanks for the additional information to clear my discuss.  The scope of the threat mentioned is limited and I'm okay with leaving out mention of it.

I stand baffled that you won't fix this, but I'm certainly not going to DISCUSS it any longer:

8.4.3:

OLD
   Reserved2: Set to zero on transmission and ignored on reception.
NEW
   Reserved2 (12 bits): Set to zero on transmission and ignored on reception.

Thanks  for handling my discuss points. 

The comments below are old, I didn't check them against 
the latest draft.

-----------------------

- 8.4.4 - is there a possible DoS issue here?

- 8.4.13 - why is an authentication TLV OAM specific?

- 8.4.13 - I don't (think I have) access to [IS-IS] so I've no
idea how this works in general - why not just say that rfc5310
is must-implement and [IS-IS] is a MAY?  And why not go further
and make HMAC-SHA256 the MTI auth type?

- Section 14 says: "Generally, a single operator manages each
TRILL campus, hence there is no risk of security exposure." I
think that's just bogus if you're trying to say that there are
no security issues in managing a campus network. But I guess
that's not it, so what are you trying to say?