Subject: [trill] draft-tissa-trill-oam-fm-02

From: Tal Mizrahi <[email-masked]>
Date: Wed, 29 May 2013 12:00:57 +0300

Hi Tissa, Authors,

I reviewed draft 02 (actually, I was half-way through version 01 when I noticed version 02 was around...).

Very impressive work.
Please see my comments below.

1.        "The TRILL Header, as defined in [RFC6325], has two reserved bits that are currently unused. RBridges are currently required to ignore these fields."
I would avoid the word *currently*. I suggest: "The TRILL Header, as defined in [RFC6325], has two reserved bits. According to [RFC6325] RBridges are required to ignore these fields."

2.       s/Implementations are further required/Implementations are further REQUIRED/

3.       "Implementations are further required to validate such frames by comparing the value at the OAM Ether Type (Figure 1) location with the CFM EtherType "0x8902" [8021Q]. If the value matches, such frames are identified as TRILL OAM frames and SHOULD be processed"
-- this section must specify what it means when there is no match with the Ethertype value. Bad packet? Future usage of the "A" bit?

4.       "Backward*s* compatibility" vs. "Backward compatibility" - need to be consistent throughout the document.

5.       "Implementations that support the extension of using the "A" flag to identify frames MUST use that flag"
-- This phrasing is not completely clear. I suggest: "An RBridge that sends an OAM frame MUST set the A flag, and an RBridge that receives an OAM frame MAY check the A flag"

6.       Figure 3:

a.       Please clarify that "Inner MAC SA" and "OAM Ethertype" is part of the flow entropy, while "Egress nickname" is in the TRILL header (or correct me if I am wrong).

b.      Please explain why "unicast IP" matches the inner MAC SA, while "unicast no IP" does not match the inner MAC SA.

7.       Section 3.4: my understanding from this section is:
Receiving: "OAM Capable" RBridges use the A bit to identify OAM packets, whereas "Backward Compatible" Rbridges use the methods described in the table in Figure3 (MAC SA, Ethertype, Nickname).
Sending: *Both* "OAM capable" and "backward compatible" RBridges *send* OAM packets with A bit+Figure 3 indications (MAC SA, Ethertype, Nickname).
-- please clarify this in Section 3.4.

8.       Section 9.2:

a.       This section currently ignores loopback.

b.      I strongly suggest to use different opcodes for loopback and for path trace, since we expect different functionality from the responder.

c.       802.1ag/Y.1731 always use the following opcode numbering for message/response: response opcode = even opcode; message opcode = response opcode+1 (odd)
-- I suggest to use the same numbering methodology.

9.       Loopback message:
In draft-mizrahi-trill-loss-delay we defined a "Reflector Entropy TLV", which allows the sender to determine the flow entropy of the response message. I think this is probably relevant to LBM/LBR as well, since you may want the sender to determine the path of the response message.

10.   I would merge section 8 with section 13.

11.   The context of "Backward Compatibility" in Section 7 is entirely different than the context of "Backward Compatibility" in Section 3. It is very confusing to use the same term in both contexts, and I suggest to use different terminology.

Thanks,
Tal.