Re: [trill] TRILL OAM Requirements -

[Sam Aldrin <[e-mail]>]

Santosh,

Please find my comments inline with %SAM.

On Apr 25, 2012, at 3:36 PM, Santosh Rajagopalan wrote:

> 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.
%SAM - What would make is certain in a requirements document in your opinion?
> 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?
%SAM - This is requirements document. There should be ability to verify any given individual path/flow.
> Either way, this doesn't scale for effort or state.
%SAM - Just because a vendor device cannot scale, it doesn't mean cannot be done. May be if you can justify with a quantification what scale metrics you are talking, would help to discuss further.
> 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. 
%SAM - Again, I am not sure, based on what quantification you are arriving at the conclusion. This is fundamental requirement in other network types as well. So,  would like you to provide more data points to your argument on why it cannot be done in TRILL, whilst the same is done in other networks.
> 
> 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? 
%SAM - Please ask the author for clarification.
> 
> "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? 
%SAM - We could add more clarifying text here. My take on this is, we should not define individual framework for different OAM components. For example, to quickly achieve ping and trace, we define a packet format. Later, when we want to test multipath/ECMP, oops..cannot be done, so let us define a new format. So, the requirement emphasize on avoiding that. Can it be 100% achievable, simple answer is NO. But we need to try our best. Others could chime in, if they want to add.
> 
> "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?
%SAM - What part is not clear? Requirement is specifying the error counters should be maintained on an RBridge. Whether you provide access to query or only display via CLI is implementation specific.
> 
> 
> "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? 
%SAM - see earlier reasoning.
> 
> 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. 
%SAM - When you say 'most', does that mean there are switches which could do that, correct? That is why the word 'SHOULD' is used. If any vendor cannot support, that is their choice. In regds to MIB or SNMP, they are part of OAM umbrella. Not sure why this OAM requirement implemented via SNMP is an issue to you?
> 
> 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? 
%SAM - I think it is both. If you can timestamp at each level, one could provide more granular levels. How you do it? could be proprietary or part of solution documents.
> 
> 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. 
%SAM - We have merchant silicon vendors on the author list. I have my opinion but will leave it for them to comment. :D

HTH,
-sam
> 
> -- 
> Sunny Rajagopalan 
> 
> 
> 
> 
> 
> 
> From:        "Tissa Senevirathne (tsenevir)" <[e-mail]> 
> To:        <[e-mail]> 
> Date:        04/19/2012 02:04 PM 
> Subject:        [trill] TRILL OAM Requriements - 
> Sent by:        [e-mail] 
> 
> 
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
> 
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill