RE: comment on draft-ietf-6man-ipv6-alt-mark

["Lubashev, Igor" <[e-mail]>]

Dear Giuseppe,

Thank you for working on this draft, your offline discussion, and this summary.

Yes, I was referring to the https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-03 draft (this is a newer version than -02, but if you are familiar with -02, you are familiar with -03).

I understand that the original motivation for adding this new IPv6 Option was to narrowly provide home for the bits for the RFC8321 OAM technique and to be applicable only to a single administrative domain.

However, we all agree that:

  1.  The problem of loss monitoring and troubleshooting extends beyond an administrative domain, yet the techniques are similar.


  1.  A richer signal, a signal that provides information about the downstream loss in addition to the upstream loss, would be helpful to a passive observe in any administrative domain (when that signal is available).

You are correct that the signal about IP-layer's downstream loss can only be obtained with the assistance of the higher-level protocol.  This may seem like a layer violation, but it is not, and it is not new.  There are many features of IP layer that get an assist from the higher-level protocol details, including ECP and ECMP.  Cross-layer assists are common.  In this case, the goal is a rich signal for the identification of packet loss in the IP layer - very much an IP-layer's concern.

The proposal I was voicing is to extend the new Option to include an optional bit for reporting end-to-end loss, which, in combination with the upstream-loss signal (alternative marking) will allow an observer to deduce upstream and downstream losses (as described in draft-ferrieuxhamchaoui-tsvwg-lossbits-03<https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-03>).

There are environments where the sender will not have information about the end-to-end loss, and hence the end-to-end bit will not be used.  However, when the information is present, it should be transmitted in the same Option as the Upstream loss bit (alternate marking), and that will enhance the loss signal for the observer.

Respectfully,


  *   Igor Lubashev

From: Giuseppe Fioccola <[e-mail]>
Sent: Tuesday, July 28, 2020 9:39 AM
To: Lubashev, Igor <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: comment on draft-ietf-6man-ipv6-alt-mark

Dear Igor, All,
Thanks for your comment during the 6MAN session of today.
This is just to share with 6MAN WG my reply and our offline discussion after the presentation.
I know your draft: https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dferrieuxhamchaoui-2Dtsvwg-2Dlossbits-2D02&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=kzH92BGFT1UgFK0BUQLRU4vDIGZQIK4rYEhHQa1_khg&s=3QDD20MdRyMeR4Rb73CzsKZts61QUbI5IlqFTWYtuo0&e=>

Firstly, it is worth highlighting that the scope of draft-ietf-6man-ipv6-alt-mark is very simple: it applies RFC8321 (and draft-ietf-ippm-multipoint-alt-mark) to IPv6 data plane in order to provide an OAM performance measurement tool to enable network level monitoring (like RFC6374 for MPLS or Y.1731 for Ethernet and so on). This is to cover an OAM requirement since IPv6 lacks of a passive/hybrid performance measurement method.

The proposal in your draft (draft-ferrieuxhamchaoui-tsvwg-lossbits-02) is interesting but it aims to cover a different scenario since it is applicable to an encrypted client-server protocol such as QUIC or TCP. I'm also working on a similar problem (draft-cfb-ippm-spinbit-measurements). Anyway these methodologies are applicable to Client-Server protocol at transport level on top of the network level and the flow under monitoring is managed by the higher-level protocol.
So the main difference is that draft-ferrieuxhamchaoui-tsvwg-lossbits is applicable to QUIC/TCP while draft-ietf-6man-ipv6-alt-mark is dedicated to IPv6.

In summary, the two methodologies are used separately since each layer needs its own OAM tools but they can also be used in combination to get richer information related to the lower/higher-layer protocol.

I think we may evaluate to add some considerations on that in a future version of our draft.

Regards,

Giuseppe