Re: [Lime] Progress on LIME Connectionless documents

["Srihari Raghavan (srihari)" <[e-mail]>]

Hi Greg

Thank you very much for your time and comments.  Pl. find collective responses from authors below inline for the base draft below.

Thanks
Authors

From: Lime <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 19 July 2017 at 6:27 PM
To: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>
Cc: "Benoit Claise (bclaise)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lime] Progress on LIME Connectionless documents

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.
[Carlos] It’s true that, from FCAPS (from the OSI Management functional areas [X.700 (09/92)]), OAM generally covers F and P *on the dataplalne only*. However, the IETF refers for example to BFD as an OAM protocol (not as an “F-only data-plane-only OAM protocol”.  There are a number of timestamps, delays, etc., in this specification for example in the path-trace-info, jitter statistics, etc. Those are “P”.  To me, the title seems adequately scoped.

[Authors] Echoing Carlos comments, the authors feel that the title adequately covers the scope under FCAPS and also covers it in a broad and generic way to allow extensions to be added later on as needed.

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.

[Authors]  Authors feel that the text is adequate as we have specifically referenced RFC 7276, which defines connectionless OAM as “data is typically sent between end points without prior arrangement” and we would like to point out that the word “typically” covers a broad range of connectionless OAM and allows for exceptions as you point out.  The text captures the dominant aspects.

  *   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;
[Authors] Respectfully disagree.  To clarify, VRF-based pings are surely possible and the document is not suggesting that VRF be carried in the packets.  The field exists to convey the VRF information for the RPC.

  *
     *   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.
[Authors]:The level parameter is used to stitching two adjacent test point and is not used for indicating how to exchange OAM message between any two test points. Level is not carried in the OAM protocol.  Source and destination TPs should not be at different layer, but two adjacent TPs can be at different layers.
If there are two adjacent TPs are at different layers, we should not allow traceroute or ping to be exchanged between them, since we don’t see any cross-layer OAM mechanism to be standardized in the IETF.  In overlay/underlay cases, two overlay nodes should be located at the same layer. But we don’t support sending one OAM message from one underlay node to overlay node.

  *   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.

[Authors] Respectfully disagree.  We just can’t take the example of service provider deployment, which has multiple vendors deploying the solution, but take an example of MSDC deployment in which one company manages the end to end network with multiple PODs, connected via spine or border leaf using multiple L2/L3 technologies.  In this scenario, there is an relationship between the transport, host and also the overlay.  Even in the case of SP, deploying L2 overlay technology to test a host from the network leaf is a reality.  In this scenario, OAM packets does not leak out the overlay network, but OAM is done on the basis of host VRF and host MAC or IP address.  This is required because network operator does not even know where the host is attached and that he has to do host-based dest TP OAM.  In this scenario, if we do a trace route, it can fail in underlay which is in a different VRF (default e.g..,) compared to that of the host.

  *   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.
[Authors]: I think multicast/group IP address is targeted to a set of host while unicast IP address is targeted to a single host.
Instead of defining ip-multicast-group-address in CL OAM model draft, we can refer to ip-multicast-group-address defined in draft-ietf-rtgwg-routing-types-06.  Let us know.

  *
     *
        *   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?

[Authors] The use-case behind the inclusion is as follows.  Trace route MAC on VLAN x from leaf node which are starting overlay tunnels.  In this scenario, OAM automatically finds the right overlay peer [in MSDC environment – needs multiple RIB commands] and send OAM packets towards overlay carrying the host information in the payload.

  *
     *
        *

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

[Authors] Added here for future use, but can be removed at present.

  *
     *
        *

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

[Authors] Added here for future use, but can be removed at present.

  *
     *
        *

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

[Authors] Thank you. Will fix.

Route Distinguisher is an 8 octets identifier

used to distinguish information about variousL2VPN advertised by a node.

[Authors] Thank you. Will fix.

        *   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;

[Authors] Thank you. Will fix.

        *   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;

[Authors] Will fix description.  It essentially means the length of the queue of the interface from where the packet is forwarded out.  The queue depth could be the current number of memory buffers used by the queue where a packet can consume one or more memory buffers depending on size.  Essentially device-level troubleshooting information.

        *   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?

[Authors] Residence time as explained in your draft (Link<https://tools.ietf.org/html/draft-ietf-mpls-residence-time-15>) and carried via G-Ach RTM message, specifies the cumulative end-to-end time spent transiting the nodes from ingress to egress, while transit-delay reflects the per-device delay seen in the path.  This transit-delay could be accumulated and collated to provide the residence time as well.
[Authors] App-meta-data is meant for application specific data that is a placeholder for extensions that can include application defined data.

        *   what is the reason to differentiate between IPv4 and IPv6 continuity check session statistics if both cases end up using cc-session-statistics.

[Authors] To provide granularity in reporting statistics differentiated on an address-family basis.  This can be made coarse-grained, but could be useful in the present way to deployments.

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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lime