Re: [Lime] Progress on LIME Connectionless documents

[Greg Mirsky <[e-mail]>]

Hi Srihari, et. al,
I'd appreciate your response to my comments. I think that we have not yet
converged on too many of my comments.

Regards,
Greg

On Tue, Aug 22, 2017 at 4:42 PM, Greg Mirsky <[e-mail]> wrote:

> Hi Srihari and Authors,
> thank you for your consideration of the comments. I'm glad that we're
> converging and some will be reflected in the next version. But some, in my
> view, still remain open and require more discussion. Please find my
> follow-up notes in-line and tagged GIM>>.
>
> Regards,
> Greg
>
> On Sun, Aug 20, 2017 at 10:53 AM, Srihari Raghavan (srihari) <
> [e-mail]> wrote:
>
>> 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]> on behalf of Greg Mirsky <
>> [e-mail]>
>> Date: Wednesday, 19 July 2017 at 6:27 PM
>> To: "Carlos Pignataro (cpignata)" <[e-mail]>
>> Cc: "Benoit Claise (bclaise)" <[e-mail]>, "[e-mail]" <
>> [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.
>>
> GIM>>  I don't find any definition of connectionless, in our case
> connectionless packet switching, network in RFC 7276. The quote is an
> observation not a definition. Compare it with G.800 that does provide clear
> definition of connectionless network in section 6.3.1 by comparing
> destination forwarding with channel forwarding. I've attached copy of G.800
> in case.
>
>>
>>    - 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.
>>
> GIM>> I don't think that adding elements to OAM data model  "just in case"
> is right approach. If and when new mechanism, e.g. VRF-based ping, will be
> defined, then it can augment the model accordingly. Perhaps you can help
> understand what is role of tp-address-vrf in:
>
>>
>>    - container dest-test-point of grouping path-discovery-data
>>    - container dest-test-point of grouping continuity-check-data
>>
>>
>>    -
>>       - 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.
>>
> GIM>> The description states:
>
>          "List of related oam layers.
>                  0 means they are in same level, especially
>                  interworking scenarios of stiching multiple
>                  technology at same layer. -1 means server layer,
>                  for eg:- in case of Overlay and Underlay,
>                  Underlay is server layer for Overlay Test Point.
>                  +1 means client layer, for eg:- in case of
>                  Service OAM and Transport OAM, Service OAM is client
>                  layer to Transport OAM.";
>
> What you describe is peer-to-peer relationship, while the description uses
> client/server terminology. I think that it needs re-work or may be removed
> altogether.
> And as example of OAM mechanism that traverses overlay and underlay I
> point to draft-nordmark-nvo3-transcending-traceroute.
>
>>
>>    - 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.
>>
> GIM>> Sorry, but I don't see relevance between my comment and your answer.
> Please re-read my original comment and let me know if you have any
> questions, need clarification and I'll be glad to help you.
>
>>
>>    - 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.
>>
> GIM>> Avoiding re-definition is good practice but I've asked about
> different aspect, about why the model differentiates between unicast and
> multicast IP addresses even though I don't see difference if, for example,
> MAC being used. CCM and Linktrace, AFAIK, does use multicast group address
> 01-80-C2-00-00-3y with 0-7 used by CCM and 8-F - by Linktrace. And how in
> the regard you've mentioned behavior of multicast address is different from
> one with broadcast address?
>
>>
>>    -
>>       -
>>          - 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.
>>
> GIM>> Not sure how uint64 is useful here.
>
>>
>>    - 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.
>>
> GIM>> Such as ...?
>
>
>> 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-connec
>>> tionless-oam/shepherdwriteup/
>>> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connec
>>> tionless-oam-methods/shepherdwriteup/
>>>
>>> Thanks,
>>>
>>> Carlos & Ron.
>>>
>>> _______________________________________________
>>> Lime mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lime
>>>
>>>
>>
>