Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

[Greg Mirsky <[e-mail]>]

Dear Authors, LIME WG Chairs, et.al,
please consider my comments as part of WG LC discussion.

   -

   3.1 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.1>.
TP Address

   - I think that this topic requires more discussion. In what case, which
      network technology developed at IETF MAC may identify test point?
      - FEC is the most common case among listed. In fact, FEC unlikely
      fits into this list if we understand it as group of IP packets which are
      forwarded in the same manner over the same path, and with the same
      forwarding treatment. In other words, we have the same destination, same
      next hop, egress interface and CoS marking (note that some of these
      parameters may be as wild card).
      - IP Address, whether v4 or v6, does not sufficiently define the Test
      Point and must be associated with the parameter that defines forwarding
      treatment of a test packet addressed to the Test Point, e.g.
DSCP for IP or
      TC for MPLS. True, often CoS parameter is set by default but that doesn't
      exclude it from the list of parameters that define the Test Point
      - I don't know of a case when this is true "a pair of source,
      destination addresses, and interface (Useful for BFD)". Could you please
      elaborate, give an example?
      - "System-id to represent the device or node" Like in Segment
      Routing? Example, reference would be helpful.
   -

   3.2 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.2>.
Tools

   - "performance measurement" As I understand, model of performance
      measurement OAM is outside the scope of this document.
      - I think this section would be the proper place do discuss proactive
      and on-demand OAM tools, give examples of each and how they being used in
      network operations.
   -

   3.3 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.3>.
OAM-layers

   - "each layer has its own OAM protocols"
         - s/protocols/protocol/
         - I think that that is not necessarily the case, e.g. BFD may be
         used in IP/MPLS underlay and L3VPN overlay.
      - "OAM-layers is referred to a list of upper layer, lower layer that
      are related to current test point. This allow users to easily navigate up
      and down to efficiently troubleshoot a connectivity issue at different
      layer."
         - Something is missing in the first sentence.
         - s/this allow/this allows/
         - Connectionless network does not include connection as element of
         its architecture and thus there's no mis-connection defect.
Perhaps you
         were referring to loss of continuity defect here.
      - I don't agree with the proposed use of OAM level. If we consider
      OAM of a service that traverses multiple administrative domains, then
      Service OAM must be at the same level regardless of domain. Service OAM
      would be the outmost top level. Each operator may enable OAM
test points in
      its respective segment so that each of segment would be at the same OAM
      level, e.g. Link OAM at the very bottom with Segment OAM between Service
      and Link OAM levels.
   -

   3.5 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>.
Test Point Locations

   - The last sentence is hard to parse and it leaves impression of
      circular reference with the definition of Test Point Location Information
      definition in the previous section.
   - "... data model is made generic enough to allow active, passive and
   hybrid OAMs to do the retrieval"
      - This being mentioned in reference to Path Discovery Data and
      Continuity Check Data. I'd imagine that an OAM mechanism, would it be
      active, passive or hybrid, produces the data but the retrieval
of data done
      using non-OAM protocol, e.g. RPC, gRPC or else.
   -

   3.8 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.8>.
OAM data hierarchy

   - I think that "oper" as name for the container that holds operational
      information is confusing. Could it be extended, more self-explanatory?
      - I there are more than two types of TP (IPv4 or IPv6), e.g.
      System-id, why container *oper* for continuity-check statistics holds
      only for IPv4 and IPv6 types of TP?
      - as-number-location may be part of tp-address, but as identifier of
      a Test Point? Could you please give an example.
      - I believe that connection-oriented-location as part of tp-address
      grouping is not correct.
      - As connectionless network does not use notion of connection, OAM in
      connectioless network does not include tools to conduct connectivity
      verification and to detect mis-connection defect. Hence there's no
      definition of in and out of mis-connection defect for connectionless
      networks.
      - I don't agree with the list of values the 'tp-address-type-value'
      leaf may take. As noted earlier, MAC unlikely to be used as address of a
      test point in connectionless network and so FEC identifier


Nits:

   - cc - is missing from Terminology section
   -  FEC is missing from Terminology section
   - [lime retrieval methods] appears as reference but has no real document
   it points to

I don't support publication of this version.

Regards,
Greg

   -


On Thu, Jan 19, 2017 at 8:12 AM, Ron Bonica <[e-mail]> wrote:

> Folks,
>
> This message begins a Working Group Last Call on draft-ietf-lime-yang-connectionless-oam-03.
> Please submit comments by February 3, 2017.
>
>
>   Ron
>
> _______________________________________________
> Lime mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime
>