[rbridge] merging draft-tissa-trill-oam and draft-ietf-trill-rbridge-oam

Hi,
We currently have two competing approaches to TRILL OAM, draft-ietf-trill-rbridge-oam and draft-tissa-trill-oam. Both have their merits, which calls for a revised draft with the best ideas from both.

draft-tissa-trill-oam has a dependancy on IP/ICMP/ARP etc.  The major reason for this dependency seems to be for multipath path discovery, and I have some suggestions as to how to fix this in draft-ietf-trill-rbridge-oam without using IP. draft-tissa-trill-oam also has several features which should be rightly queried from a MIB.

I think the OAM draft should concentrate on facilitating actions that would be difficult or impossible to perform in its absence. So querying counters has no place here, because you could easily figure them out by doing an SNMP query or by logging into the switch. I also think it's worthwhile to look at the features traditionally supported in ethernet OAM and to see if they have a place here.

Using draft-ietf-trill-rbridge-oam as a basis:

1) Ping/loopback: draft-ietf-trill-rbridge-oam handles this well enough (it does need a multicast addition). The purpose of ping is to verify connectivity between two rbridges, not to discover the various ways of connecting the two.  One suggestion I have here is to be able to include a cookie in the echo request message which gets reflected back by the receiver. This cookie could be used to include the sender's timestamp in the ping message. The response could then be used to measure round-trip path latency and jitter. If the sender and receiver's clocks are synchronized using some external mechanism then this can also be used to measure one-way delay and jitter. This is a feature borrowed from ethernet OAM.

2) Traceroute: IP traceroute doesn't rely on icmp for the outgoing packet (you could use ICMP, but that's a different matter). In fact, UNIX implementations usually just send UDP packets with port numbers in the 33K range, with appropriate TTL values. Note that traceroute in the IP world gives you "a" path to a destination, not "all possible paths". However, being able to enumerate all possible paths, as well as to pinpoint the particular path a flow would take are good to have features. 
Here're the modifications needed in draft-ietf-trill-rbridge-oam to achieve this:
Multicast unpruned tree discovery: you can discover all existing unpruned multicast trees by setting the erbridge value of an rbridge channel message to the respective roots, M=1 and the dmac to "all-egress-rbridges". Just like regular ping, you can send this as an echo request message with incrementing ttl values, and the ttl expiry messages you get will tell you what the unpruned tree looks like. Changing the egress_rbridge will paint you a picture of the different trees.
Multicast pruned tree discovery: just do a), but replace the "all-egress-rbridges" multicast address in the inner dmac with the mac address of the multicast group. As you vary the egress_rbridge field, this will enumerate all possible pruned trees for that group. Note that draft-ietf-trill-rbridge-oam uses draft-ietf-trill-rbridge-channel, which requires the inner dmac to be all-egress-rbridges. However, the ethertype field can be used by itself to classify an OAM packet, and I am advocating that the inner dmac requirement in draft-ietf-trill-rbridge-channel be relaxed to allow for alternative inner dmacs where needed.
Multicast pruned tree discovery for a particular flow: I recommend building a packet with an empty payload which looks like the actual flow (with the header fields from the flow being tested instead of the rbridge channel header). The IP address, mac address, L4 headers etc all match with that of the flow you're trying to debug. However, to ensure that any leaked packets get dropped, set the IP checksum to be invalid (the IP checksum is never used for the ecmp hash). Now send out successive packets with the ttl field in incrementing values. Note that you're sending a "pseudo-real" packet into the network and relying on received ttl expiry messages to figure out the path.
Unicast path discovery: the erbridge ID is that of the switch you're trying to ping. Let's send this echo request message with a fake inner DMAC. Construct the dmac so that the U/L bit is 1 and the I/G bit is 0 (basically, its a local scope unicast mac). Set the last 32 bits to a random value. This is a fake mac address, but that's ok because the network routes only on the erbridge anyway. The M bit in the TRILL header is 0. Send this as an echo request message with incrementing ttl values. This gives you "a" path from the source to the destination rbridge. Increment the dmac used earlier, and repeat. All rbridges hash at least on the inner dmac, so this will allow you to enumerate all possible paths from source to destination.
Unicast path discovery for a particular flow: Similar to what we did for multicast, construct a real packet of length 0. The IP address, mac address, L4 headers etc all match with that of the flow you're trying to debug. However, to ensure that any leaked packets get dropped, set the IP checksum to be invalid. Now set the ttl field in incrementing values. Note that you're sending a "pseudo-real" packet into the network and relying on received ttl expiry messages to figure out the path.
Note that doing this eliminates the reliance on IP/ICMP, while preserving the objectives of draft-tissa-trill-oam. The fake packets generated are technically not OAM packets, just suggestions on how to achieve a certain objective.

3) Fault notification: although neither draft talks about this, this is a part of the ethernet OAM feature set. I think draft-ietf-trill-rbridge-oam needs to mention that the expectation is that BFD will work over the rbridge channel to achieve this.

4) draft-tissa-trill-oam  has a big section on TTM. The equivalent in Ethernet OAM is performance management by checking counters and send/receive delays, etc. We can cover send/receive delay/jitter measurements using ping (as described earlier). I frankly don't see the benefit to including remote discovery of counters in this OAM proposal. The administrator can always just login to the rbridge of interest and get a read-out of the counters directly, or use snmp remotely. We shouldnt be replicating functionality which is better done elsewhere, and I think this entire section on TTM in draft-tissa-trill-oam should be taken out.

5) I don't see any benefits to DRB/AF discovery OAM messages. This is probably done most easily by logging into the rbridge in question and doing a "show l2 isis", or extending the SNMP MIB. 

6) draft-tissa-trill-oam has a section on MAC discovery (basically, being able to query all rbridges to see what their rbridge<->mac binding is). This is again something that should be best queried using SNMP - this is a classic MIB walk case.

7) Address binding verification should be out of scope for a TRILL OAM draft, and besides, should just be queried at the rbridge with the CLI.

8) End-Station Attachment Point Discovery: should be out of scope of this draft, and is too vendor specific (it uses VN-tags).

best,
Sunny Rajagopalan