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

[Giuseppe Fioccola <[e-mail]>]

Hi Igor, All,
The main scope of draft-ietf-6man-ipv6-alt-mark is to add performance measurement capabilities to IPv6 independently from high-level protocols, indeed an OAM tool for a specific layer (in this case IPv6) should be independent from other layers.
Just two clarifications on your two points:

1)      draft-ietf-6man-ipv6-alt-mark can eventually be used beyond an administrative domain. The controlled domain is for security reason.

2)      Alternate Marking (RFC8321 and draft-ietf-ippm-multipoint-alt-mark) allows by definition upstream, downstream and round trip measurements. There are no limitations (please read RFC 8321). It is a point-to-point or multipoint measurement that can be applied to one-way flows both upstream and downstream.

Regarding the cross-layer information it could be useful only in case we want to monitor a single protocol. Anyway this Option Header includes Reserved bits and we may pick up one of this for the scope in the future.
Anyway, before doing so, I would wait till the discussion about the higher-level methodologies are defined in TSVWG, QUIC and IPPM in particular regarding draft-ferrieuxhamchaoui-tsvwg-lossbits and the other proposal in draft-cfb-ippm-spinbit-measurements.
Now I think it is too early to include this optional bit in an IPv6 Option Header, considering that the methodologies described in draft-ferrieuxhamchaoui-tsvwg-lossbits and draft-cfb-ippm-spinbit-measurements still need to be clearly defined for the corresponding transport protocol (QUIC or TCP).

Regards,

Giuseppe


From: Lubashev, Igor [mailto:[e-mail]]
Sent: Wednesday, July 29, 2020 12:00 AM
To: Giuseppe Fioccola <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; HAMCHAOUI Isabelle IMT/OLN <[e-mail]>; RONTEIX JACQUET Flavien TGI/OLN <[e-mail]>; TUFFIN Stephane RD-CORE-LAN <[e-mail]>
Subject: RE: comment on draft-ietf-6man-ipv6-alt-mark

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]<mailto:[e-mail]>>
Sent: Tuesday, July 28, 2020 9:39 AM
To: Lubashev, Igor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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