Re: [trill] TRILL OAM Requirements -

Comments on this doc:
4.3 Continuity check:
This seems to be defined too broadly in the doc. I look at this as a 
keepalive mechanism which gets set  by configuration, and stays on for a 
longer period of time (as opposed to connectivity verification, which is 
user-initiated and short-lived). In Ethernet OAM, this is used to keep 
track of connectivity between adjacent switches and between switches that 
lie at the edges of a "level". 
The value of continuity check as defined in this doc seems less certain to 
me. What does it mean to have continuity checks for each flow? Each time a 
flow gets initiated, is an operator expected to setup keepalives for that 
flow? Or is this expected to get started automatically every time a new 
flow is detected? Either way, this doesn't scale for effort or state. The 
same goes for continuity checks which check if each link of a multipath is 
alive. I would recommend that the scope of the continuity check messages 
get narrowed to measure the connectivity liveliness for rbridges either on 
a per-hop basis or an end-to-end basis.

4.5. General Requirements

"OAM MUST NOT require extensions to or modifications of the TRILL
   header."
Is the rbridge channel as defined in  
http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 
considered an extension or modification of the TRILL header?

"OAM, as practical as possible, SHOULD provide a single framework
   between TRILL and other similar standards."
I'm not sure what this means. Can someone clarify?

"OAM MUST maintain related error and operational counters."
Again, what does this mean? Is the requirement that the OAM framework 
defined for trill must be able to query all counters? 

"OAM MUST provide a single OAM framework for all TRILL OAM functions"
Can you provide an example of what would be a violation of this?

4.7. Packet Loss
This is another section which is very broadly defined. Most switches I 
know of don't have the ability to maintain packet loss counters per flow, 
or even per source rbridge (leave aside packet loss for one link of an 
ecmp between rbridges). The best you can get here is packet losses for a 
given link, and this is already part of the TRILL MIB and can be queried 
by SNMP.

4.8. Packet Delay

As defined here, measurement of packet delay seems to require hardware 
support. Is that the intent? Or is this supposed to measure delay between 
OAM software processes on the relevant switches?

5. General Format of TRILL OAM Messages
The inner ethernet header should be called out explicitly, instead of 
being subsumed in the "Flow entropy" section, since using anything other 
than ethernet after the trill header would break every single trill 
compliant piece of silicon I know of. 

--
Sunny Rajagopalan

From:   "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To:     <trill@ietf.org>
Date:   04/19/2012 02:04 PM
Subject:        [trill] TRILL OAM Requriements -
Sent by:        trill-bounces@ietf.org

Dear All

As agreed during the 83rd IETF meeting we have published TRILL OAM 
Requirements. Below is the link to the ID. Please review and share your 
thoughts.

http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt

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