Subject: [Lime] Fwd: WG Last Call

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 5 Jul 2016 15:21:26 +0000

draft-ietf-lime-yang-oam-model-06 authors,

I received the following review comments on the WG LC from David Ball. I wanted to share this with the WG. Please address these as well.

Thanks!

— Carlos.

Some specific comments:

  *   Please do not use "Y.1731" as the reference key for G.8013/Y.1731 - it was renamed 5 years ago.  "G.8013" or "G.8013/Y.1731" are the right ways to refer to that document.
  *   The introduction needs to say what is meant by "connection-oriented" - Ethernet is not a connection-oriented protocol for example, and even 802.1Q CFM is not connection-oriented.  This may not be the right term for what is meant.
  *   Performance monitoring is mentioned a couple of times in the introduction, but doesn't appear to be covered by this model.
  *   Inconsistent terminology is used - e.g. both "loop back" (and "loopback") and "connectivity verification" appear in different places, and similarly "traceroute" and "path discovery" are used.  It would be helpful to pick one set of terminology, make sure it is properly defined in Sn 2.1, and then use it consistently throughout the document.
  *   The last paragraph in Sn 2 (before Sn 2.1) is in the wrong place - I think it is supposed to appear immediately after the first paragraph (about the RFC2119 keywords), before the description of the yang tree representation.
  *   The description of how yang trees are represented does not cover the ":(case)" representation for the cases of a choice statement.  Also the inputs for RPCs have flags "-w" which is not described as a possibility here.
  *   Sn 2.1: The definitions of CC and CV here don't quite match RFC7276: in RFC 7276 the distinction is that CC checks that a destination is "reachable" whereas CV checks it is "connected".  RFC 7276 says that CV tools "often" perform path verification, but that isn't part of the definition.  TBH I don't think the RFC 7276 definitions are very helpful (esp when applied to connectionless data planes, which is most cases), but if you're going to refer to them then the definitions should match.
  *   Sn 4: Domain Level is not a generic concept, it is only needed in technologies (like Ethernet) where different reachability is not necessarily indicated by differences in the header.  In MPLS-TP for example, there is no need for a domain level since reachability is determined by the number of MPLS labels.
  *   Sn 4.4: continuity-check is typically proactive; so it should correspond with configuration, not with RPCs (or both, in cases where both proactive and on-demand versions are supported).  Connectivity Verification and Path Discovery are on-demand and so RPCs are appropriate.
  *   Sn 4.5: notification should also be sent when a defect is cleared.
  *   Sn 4.6: Why are statistics for pro-active CCs returned from on-demand RPCs?  This makes no sense.
  *   Sn 5: Please check for spelling and for correct indentation throughout (particularly for description strings).  A lot of indentation is awry which makes it very hard to read the model.
  *   Sn 5: identity "remote-rdi" - this is redundant, the "r" in "rdi" already means remote.  Also the description of this defect is extremely unclear.
  *   Sn 5: identity "invalue-oam-error": Should be "invalid"; also 3.5 is a technology-specific value.
  *   Sn 5: identify "cross-connect-error": Need to say what a "cross-connect oam message" is.
  *   Sn 5: These identities, and some of the later fields in the notification, use "error" in their names, and "defect" and "failure" are also variously used.  Please use consistent terminology (I don't think any of these actually refer to errors).  Note that RFC7276 defines "defect", "fault" and "failure".
  *   Sn 5: MEP direction: this only makes sense in technologies where MEPs are attached to interfaces, which might always be true for connection-oriented technologies.  If so, the reference to the interface needs to be added to the MEP configuration; if not, then the MEP direction should go.
  *   Sn 5: MD-name-string and MA-name-string are used as list keys so having a default of "" doesn't seem like a good idea.
  *   Sn 5: MEG ID: until now everything has used 802.1Q-based terminology not ITU-T-based terminology (i.e. "MA" instead of "MEG"); so be consistent here and use "MA ID" not "MEG ID".  Also the example in the description makes no sense (or at best, presupposes the reader is very familiar with MPLS-TP OAM).  In general, we cannot assume that the reader of this document is familiar with any particular OAM technology, so any examples need to be very clearly spelled out from scratch.
  *   Sn 5: grouping ttl - unclear why this needs to be a choice rather than a plain integer; clearly the appropriate TTL for the technology in use is what is meant.
  *   Sn 5: grouping MA-name: the MA name cannot be a MEG ID - the MEG ID was defined previously to be the concatenation of the domain name and MA name.  This is saying that the MA name is the concatenation of the domain name and itself!
  *   Sn 5: grouping MEP: a MEP is not associated individually with a connectivity context, this comes from the MA.  It makes no sense to have 2 MEPs in the same MA in different forwarding domains - in that case they are by definition not in the same MA.
  *   Sn 5: grouping monitor-stats: this doesn't seem useful; either define some generic stats (number of CC/CV/etc packets sent/received), or omit it and let each technology augment the model as appropriate.
  *   Sn 5: grouping MIP: an interface is not sufficient to identify a MIP; at least a domain is also needed.  Also if MIPs are tied to interfaces, then MEPs must be too.
  *   Sn 5: grouping cos: This is poorly named, the class of service is conceptual, I think this is really talking about how it is identified on the wire.  So cos-id or something would be better.  Also there is no such thing as the MPLS EXP field, it is called the TC field (since 2009, see RFC 5462).
  *   Sn 5: leaf transmit-interval: this should be called cc-transmit-interval if it only applies to CCs (as the description says).  Also what does a value of 0 mean?  And how are proactive CCs enabled?  Implicitly by setting this leaf?
  *   Sn 5: What does setting the TTL under the MA do?  This seems technology-specific in any case.
  *   Sn 5: Need to describe what a "session" means (probably in Sn 4) - 802.1Q-based OAM does not have a  concept of sessions or connections.  I think "session" may be the wrong word here - this is really configuring the expected peer MEPs, right?  So "peer-meps" would probably be  a better name.  It should be indexed by MEP name/ID (perhaps with a sub-list if there are multiple ECMP paths that need to be checked to the same peer MEP).  Also this list should be directly under the MA, not under each local MEP.
  *   Sn 5: no need for an "enable" leaf under the session, if you don't want it then just don't create that list entry.
  *   Sn 5: why does the source MEP need to be listed under the session?  If there are multiple local MEPs then the same parameters should apply to all of them.
  *   Sn 5: you cannot have different connectivity contexts for different sessions, this makes no sense.
  *   Sn 5: list MIP: need to explain this; in 802.1Q MIPs are created automatically according to a configured policy, they are not configured explicitly.  Allowing explicit MIP configuration may be technology-specific.  Perhaps this should be put under a technology-specific feature keyword?
  *   Sn 5: All of the domain names, MA names and MEP names/IDs in the notification and RPCs should be leaf-refs to the corresponding config leaves.
  *   Sn 5: notification: how is the generating MEP ID different to the MEP ID??  Is it supposed to be the peer MEP about which the defect has been detected?  This needs much better explanation.
  *   Sn 5: notification: need an indication of whether the defect is being set or cleared.
  *   Sn 5: this has "defect-type" and "error-message" leaves - please be consistent!  These are all about defects, so it should be "defect-message".
  *   Sn 5: Why is there a feature defined for CV, but not for any other operations (CC, path discovery, etc)?  The CV rpc refers to RFC 7276 Table 4, which makes it clear that CC is not supported by every protocol.
  *   Sn 5: It is unclear why RPCs for CC, CV and "traceroute" are needed - isn't CV either the same as CC or the same as traceroute?  What is the difference?
  *   Sn 5: rpc traceroute: some method is needed in the output of constructing the path; the response-index is arbitrary and the TTL is not sufficient if the protocol allows the possibility of multiple responses with the same TTL.  I think a "previous-mp" container is needed.
  *   Sn 6.1: the interface is not included in the model!  It needs to be added.
  *   Sn 6.2: "MEPID is a 2 octet field by default" - the only definition in the model is as an int32.
  *   Sn 6.2: "It is never used on the wire except when using CCM" - surely this is technology-specific.  In fact, it is unclear what all these references to "CCM" in this section mean.  Is this refering specifically to 802.1Q?  But then the references to IP address make no sense.
  *   Sn 6.4: All of this is specific to 802.1Q, it makes no sense for other technologies.
  *   Sn 6: I do not understand this "base mode" concept at all, it needs much better explanation.
  *   Sn 7: The model as defined contains some technology-specific constructs, but omits many others.  As mentioned right at the top, I am not convinced this work is really still useful, or that the applicability is as wide as claimed.  To make it as widely applicable as possible, all the technology-specifics need to be cut out; but then it becomes less easy to use.  Shoehorning different technologies into this model is possible, as this section shows, but it doesn't necessarily lead to the most easy-to-use or understandable model for those technologies.