Subject: Re: [Lime] Progress on LIME Connectionless documents

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Sun, 20 Aug 2017 17:53:49 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 19 July 2017 at 6:27 PM
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Cc: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 20 Aug 2017 21:06:20 +0000

Thank you, Srihari, for the responses. There are a number of "will fix" items. Can you please submit a new rev address in them?

Thanks!

Sent from my iPad

On Aug 20, 2017, at 1:53 PM, Srihari Raghavan (srihari) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Greg

Thanks
Authors

Major:

  *   Introduction:

  *   Section 3:

  *

  *   Section 3.3

  *   Section 4

  *
     *

  *
     *
        *

  *
     *
        *

  *
     *
        *

Regards,

Greg

Thanks,

Carlos & Ron.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Aug 2017 16:42:22 -0700

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) <
[email-masked]> 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 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> To: "Carlos Pignataro (cpignata)" <[email-masked]>
> Cc: "Benoit Claise (bclaise)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
>    - 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.
>
>    -
>       -
>          -
>
>    -
>       -
>          -
>    -
>       -
>          -
>    - 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;
>
> [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 ...?

> On Wed, Jun 28, 2017 at 10:27 PM, Carlos Pignataro (cpignata) <
> [email-masked]> wrote:
>
>> Dear WG,
>>
>> [email-masked]