[rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to* another data frame. We also need a header format table for self-initiating oam message like echo request. Table entry for "Inner.MacDA" says "Inner.MacDA MAY be other values as specified in subsequent sections". But there is no other value specified indeed.  I believe it was prepared for ping request as inner.MacDa should be a unicast mac address of destination  RB?

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests, incrementing the hop-count by one each time until... Looks a bit ambiguitous to me. Shouldn't echo request be sent with hop-count incremented by 1 only after hop-count error notification for previous echo request being received?

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the values specified in Table 1. RBridges SHOULD be configurable to change these values to assign the TRILL data frame to a flow. " For unicast tracert with specified two RBridges, if we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA and Ingress Nickname are all fixed values. Inner.vlan may take different value (table 1 indeed says it should be 1) but does not make much sense. Priority may have different value but very restricted. Therefore it lacks a lot of details on how to vary those values to get different flow? I suggest to remove this and leave it for future tool such as ecmp oam. Or say details could be find in future draft? If we want to keep it,  better to give some explaination, e.g. explicitly say virtual internal end station inside RB possily allows to be configured for different MACs?

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its 16-bit port ID from the port on which.." ->"include its 16-bit port ID from the port on which...in Outgoing Port ID TLV in reply..." , "If the request is a multi-destination frame, this field..." better moves to "4.1.1.1. Multi-Destination Targets".

5. pg9, para5, lack of description on timeout and re-transmission of echo request

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error notification"

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop Count Zero error notification", "hop count" for error is "N/A", what is the value for "N/A"? is it maximun 0x3F?

8. pg12, para4, lack of description on srcMac, destMac and hop count. It refers to table 1, but original table 1 is only for responding oam message.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field MUST be set to all zeros.... However pg9 para3 says if it is for multi-destination traceroute, next hop nickname should be "previous hop nickname"? Should have some clarification. Here it talks about normal data frame but not oam echo request frame.

10. pg18, 6.2, SPID is never used in error notification. Error notification uses channel protocol number 5 while echo use 4. Can we make SPID field here to be used for error type and make the subcode to be 16-bit long instead?

11. pg18, last line, typo, dup. requests

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop Count Zero error"

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there are 4 error type as described in previous section bullet.  It is unclear between permanent error and transient error.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a multicast address and the M bit is one? Remember there are some discussion regarding some corner cases of this. Not too sure. Moreover, can we call this error M bit mismatch or something like it to make it more descriptive?

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one with lowest value or list one with highest value? Duplicate description on multi-destination traceroute and multi-destination hop-count errors.

Another general comment is we want to make sure traceroute tool sends out echo request with same header contents each time until it reaches the final destination though RB allows the different configurations for testing flow-based path. It gurantees it follows the same path for incremental trace in tracert.

Yizhou