Re: [Lime] Progress on LIME Connectionless documents

[Greg Mirsky <[e-mail]>]

rentiate Dear WG Chairs, WG Responsible AD and members if LIME WG expert
community,
please find my comments to both documents below.

Major:

   - OAM protocols address 'F' and 'P' of the FCAPS, i.e. Fault Management
   and Performance Monitoring. The defined models address only Fault
   Management part leaving the performance measurement protocols, e.g. RFC
   6374, RFC 6375 out side their scope. I suggest to clarify and update titles
   by including "Fault Management OAM" in.

draft-ietf-lime-yang-connectionless-oam:

   - Introduction:
      - I cannot agree with the explanation of what differentiates
      connection-oriented network domain from connectionless, as difference of
      arranging network vs. without the prior arrangement. I'll point that
      signalling IP/MPLS LSP is the prerequisite of availability of
the path even
      though IP/MPLS LSP is, in general, an example of connectionless domain.
   - Section 3:
      - the section is the first reference to the grouping tp-address-vrf.
      Though local test point (TP) may be associated with the particular vrf
      identity, none of OAM protocols, e.g. IP ping, LSP ping or BFD carry VRF
      identity. Thus using vrf as part of tp-address-vrf grouping in container
      dest-test-point of path-discovery-data grouping and of
      continuity-check-data, or path-trace-info-list is problematic at the very
      minimum;
      - the connectionless-oam-layers grouping does present serious
      problem, in my opinion. Obviously, there may be more than three layers in
      the network and lower layer(s) well could be not connectionless but
      connection-oriented OAM domain. Additionally, source and destination TPs
      will always be on the same network layer, so that use of the
      connectionless-oam-layers in test-point-location-info is not warranted in
      my view.
   - Section 3.3
      - the section attempts to give extended example of how the
      connectionless-oam-layers may have value other than the default
0. I think
      that it is more confusing than without it. Administrative domains on the
      same layer interact as peers and thus cannot and should not be
referring to
      each other as server-client. If the network tunneled through the
particular
      domain, then the tunnel, on that layer, is presented as single hop. True,
      the tunnel in that domain may have transport OAM with notification to the
      edge TPs of the network OAM. But that transport OAM would not be part of
      the network OAM and access to it, in my view, could be only through state
      of multi-layer OAM where each layer is indexed and relationships between
      TPs identified by these indexes.
   - Section 4
      - I have many questions to the choice of TP types:
         - what is the difference, from OAM point, between unicast IP
         address and multicast/group IP address, whether IPv4 or IPv6.
         - I think that inclusion of MAC as MP address type in
         connectionless OAM would benefit from more explanation, use
case. TRILL?
         AFAIK, in TRILL ping is used to ping RBridge, not MAC. What is/are use
         case(s) for MAC as MP address in connectionless OAM model?
         -

         ip-prefix-address-type referenced only once as identity and
doesn't appear anywhere as use case. Is it stale type of MP address?

         -

         tunnel-address-type, as above, referenced only once as
identity  and does look as stale MP address type;

         -

         I think that there's disconnect between type definition of
leaf route-distinguisher as unit32 and the description that states:


Route Distinguisher is an 8 octets identifier

used to distinguish information about variousL2VPN advertised by a node.


   - type definition of sender-ve-id and receiver-ve-id may be changed
from uint32 to uint16 since both parameters are, as noted in
respective descriptions, two octets long;
         - what is the source of queue-depth, Length of the egress
interface queue of the interface", as explained in the description.
Firstly, not sure what "egress interface" of the interface is.
Secondly, is this static or dynamic information? If the former, then
there's no need to include it in path-trace-info;
         - the transit-delay, as explained in the description,
reflects residence time. What OAM protocols, e.g. traceroute, LSP
Ping, provide residence time?
         - what is the purpose of app-meta-data in path-trace-info container?
         - what is the reason to differentiate between IPv4 and IPv6
continuity check session statistics if both cases end up using
cc-session-statistics.

Summarizing, I believe that draft-ietf-lime-yang-connectionless-oam is
not ready for publication.

I'll work on reviewing draft-ietf-lime-yang-connectionless-oam-methods
and will share my comments with you all.


Regards,

Greg


On Wed, Jun 28, 2017 at 10:27 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Dear WG,
>
> We will be progressing the LIME Connectionless documents, submitting them
> to our AD.
>
> Please see the respective write-ups at:
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/
> shepherdwriteup/
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-
> connectionless-oam-methods/shepherdwriteup/
>
> Thanks,
>
> Carlos & Ron.
>
> _______________________________________________
> Lime mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime
>
>