Re: [trill] 802.1ag based messaging for TRILL OAM

Hi Tissa & all
The proposed 802.1ag-based frame format seems to be at odds with some of 
the stated objectives in the OAM requirements doc. 
The requirements doc says that the solution needs to be able to discover 
the various components of an ecmp for traceroute, loopback/ping etc. 
However, 802.1ag was developed for an environment that wasn't ecmp 
capable, so the frame format doesn't lend itself naturally for performing 
ecmp discovery. In particular, consider this:

a) The proposed method for OAM packet identification, which for IP is by 
matching on a src IP (plus rbridge in the case of unicast IP), will make 
the OAM packet take a different route than that taken by the flow you're 
trying to debug. Note that this was not an issue for an 802.1ag based CE 
environment because as long as you get the vlan right, data packets and 
OAM packets will follow the same (only available) path.

b) Further in the doc, (section 5:Loopback Message) seems to imply that 
the selection of the ecmp path would be signalled from the ingress 
somehow. Let's say that your network looks like this:
A-B-C-D, where B is connected to C by 3 paths and C is connected to D, 
also by 3 paths. Let's say you want to send a loopback message from A to 
D. How does A signal that B needs to pick the "first link in the ecmp" and 
C needs to pick the "third link"? The writeup seems to imply this 
information is somehow embedded in the loopback OAM TLVs. If it is, are 
the authors proposing that existing TRILL hardware change to be able to 
parse these TLVs?

Or is the intent is for the TLVs to be parsed and acted upon by software 
on intermediate switches? If yes, it would limit the usefulness of these 
OAM tools. These OAM tools (traceroute/ping etc) need to allow us to 
verify the state of programmed hardware, not the software state in 
intermediate switches. 

Essentially, we need to either drop the ECMP discovery requirement in the 
requirements doc or come up with a messaging format that satisfies it 
using the normal hardware forwarding path. A framework that relies on 
software forwarding only verifies that the network can deal with OAM 
packets correctly. It says nothing about the fate of non-OAM packets which 
go through hardware without getting trapped to the software stack.

--
Sunny Rajagopalan

From:   "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To:     "trill@ietf.org" <trill@ietf.org>
Date:   06/25/2012 08:53 PM
Subject:        [trill] 802.1ag based messaging for TRILL OAM
Sent by:        trill-bounces@ietf.org

Dear All

We have published draft-tissa-trill-8021ag, which presents use of 802.1ag 
messaging as a common framework between different technologies. We also 
have discussed the related TRILL OAM model.

This is the -00 version and would like to welcome your comments

http://datatracker.ietf.org/doc/draft-tissa-trill-8021ag

Thanks
Tissa_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill