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:[email protected]]
Sent: Thursday, August 28, 2014 8:24 AM
To: Gregory Mirsky; '[email protected]'
Cc: [email protected]; [email protected]; [email protected]; [email protected];
'[email protected]'; [email protected]; [email protected]
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:[email protected]] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: '[email protected]'
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
'[email protected]'; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
