Re: [Time] draft-tissa-netmod-oam

[Gregory Mirsky <[e-mail]>]

Hi Tissa,
thank you for detailed and informative response. Information about OAM work at TRILL WG is very interesting as I haven't been following it in much details. I'd note that applicability of the model developed at TRILL WG to MPLS OAM is not clear to me. I think that it would be helpful to discuss relevance of the TRILL's OAM model at MPLS and MPLS technology related WGs before presenting it as the model that encompasses MPLS. Similarly, I think, for the IP. Perhaps, for the time, we can refer to the model as TRILL OAM. More notes in-lined and tagged GIM>>.

                Regards,
                                Greg

From: Tissa Senevirathne (tsenevir) [mailto:[e-mail]]
Sent: Thursday, August 28, 2014 8:24 AM
To: Gregory Mirsky; '[e-mail]'
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; '[e-mail]'; [e-mail]; [e-mail]
Subject: RE: draft-tissa-netmod-oam

Greg

Before answering the specific questions below,  would like explain few aspects related to the extended CFM model used here. CFM  originally was designed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressing independent. That is the CFM model that is referred here.

CFM defines a complete fault model that include fault domains, Test point, Layering etc. Strict definition of such is needed to develop a complete OAM solution regardless of the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We are leveraging that model.

The word generic OAM is utilized here to indicate that the model can be applied regardless of the underlying technology.

YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is defined with address independent and extensibility in mind.

With the above in mind, specific answers in-line:

From: L2vpn [mailto:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: '[e-mail]'
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; '[e-mail]'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: draft-tissa-netmod-oam

Dear Authors, et.al,
please kindly consider my comments and questions to this document:

*         Introduction

o    "... it is a reasonable choice to develop the unified OAM framework based on those (CFM) concepts." I agree that for packet switching connection-oriented networks that are based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless packet switching networks. Thus extending CFM model onto arbitrary networks without consideration whether these are connection-oriented or connectionless is very questionable approach, IMO;


[Answer] As stated above it is the OAM Model that is leveraged here. Regardless of connection oriented or not the model on Fault domains, Test points etc is valid.

In theory connection oriented can be broken in to connection establishment and data forwarding. With that in mind, one can define Fault domain and test points. Followed by definition of the Fault identifications tools accordingly.

Do you have a preferred OAM tool  for fault verification/isolation and loss and performance monitoring for connection oriented connectuons ?. If so would like to review and map to the model.

GIM>> I don't have "favorite tool" but would point that in connectionless network one cannot define Mis-connection defect and thus OAM models for  connectionless and connection-oriented networks would be different.


o   "...CFM, it is a reasonable choice to develop the unified OAM framework based on those concepts" IP OAM is not based on Ethernet Service OAM model or principles but, IMO, OAM of overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

[Answer]  Please see the answer above and extended CFM model. It is the model that is presented here, regardless of the connectioness,  OAM tools need fault domains and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addressing is decoupled.


o   "The YANG model presented in this document is the base model and supports IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scope of the document, then, I believe, the title may say something like "YANG model of on-demand OAM tool to detect and localize Loss of Continuity defect". Referring to ping/traceroute as "generic OAM" comes as stretch too far;

[Answer] I think there is a miss understanding this model is not limited to Ping and Trace route. Ping and traceroute are only examples to get the work stared and discussion going. As we go along other tools will be mapped to the model.

GIM>> LSP Ping does more that ICMP or CFM's Loopback and Linktrace as it verifies correlation between control and data planes. Had that functionality been removed by TRILL OAM from "extended CFM model"?


o    "...initiate a performance monitoring session can do so in the same manner regardless of the underlying protocol or technology" I'd point to work of LMAP WG on informational model of performance measurements in large-scale access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stopped after "... or a Traceroute".
[Answer] I did not fully understand your point.


o   "In this document we define the YANG model for Generic OAM" Can you provide definition or reference to the definition of the "Generic OAM"? It is challenging to validate informational model of something that not been sufficiently defined.

[Answer]  As explained earlier terminology generic OAM is used to indicate that the presented OAM model can be applied independent of the underlying technology. In section 1, we have stated the following: "..In this document, we take the [8021Q] CFM model and extend it to a technology independent framework and build the corresponding YANG model accordingly. The YANG model presented in this document is the base model and supports IP Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various technologies. Technology dependent nodes and RPC commands are defined in technology specific YANG models, which use and extend the base model defined here. .... "

GIM>> Had other WGs agreed that the proposed by TRILL WG OAM model is representative of their technologies? If not, then what "Generic" is there?


*         Section 3

o   "This allows users to traverse between OAM of different technologies at ease through a uniform API set." Usually relationships between OAM layers referred and viewed as OAM interworking. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only scenarios of nested OAM layers but peering layers and thus is broader than introduced in the document "nested OAM".
[Answer]  Can you please provide some example here, I am not quite clear.

Guessing from the word peering, if we are referring to cascaded sections of different technologies such as IP Cloud, MPLS cloud and another IP cloud. Then the model presented here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can have separate OAM at a lower MD-Level. These can be utilized for fault isolation.


o   Figure 1 depicts OAM of both connection-oriented and connectionless networks. What you see common, generic in respective OAM of these networks?

[Answer] Please see the answers above.


*         Section 4

o   "In IP, the MA can be per IP Subnet ..." As there's no definition of MA in IP, is this the definition or one of examples. Can MA in IP network be other than per IP Subnet?
[Answer] It is ".. can be", so it meant to be an example and other possibilities are not ruled out and model does not assume any such limitation.


o   "Under each MA, there can be two or more MEPs (Maintenance End Points)" Firstly, since you adopt MA-centric terminology, MEP stands for Maintenance Association End Point. Secondly, in some OAM models Down and Up MEP being distinguished. Would your model consider that? As there's no definition of MEP for several networks you've listed, e.g. IP, how the YANG model will abstract something that is not defined? And thirdly, how and where MIPs are located in IP OAM?

[Answer] Yes model accept both UP/Down.

One cannot say for IP there is no MEP. MEP is a functional abstraction of a test point that generate and respond to OAM messages. In that regard IP devices today have an implicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per interface or other scope, hence providing more granularity in fault isolation/verification and monitoring.

GIM>> Is IP MEP being defined as being in control plane/CPU? What if it is in NPU, i.e. data plane? If on CPU, then what differentiates Up MEP from Down MEP from POV of packets it transmits and receives? And how MIP functions in IP based on TRILL OAM model? Is it, as in Ethernet OAM, constructed of two MHFs?

Thank you for your consideration of my notes and looking forward to the interesting discussion.

Thank you for spending time to review and comment. We are updating the next version with comments received so far and specifically during IETF in Canada. We are more than happy enhance where applicable or need more clarity.

Regards,
        Greg