Re: Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06

[Yoshifumi Nishida <[e-mail]>]

Hi Giuseppe,

Sounds good to me. Thank you so much.
While you're updating documents, I think it would be better to elaborate on
the relationships
between this draft and RFC8312 a bit more as the doc seems to depend on the
doc to some extent.
The draft would be a supplemental doc for the RFC or does it update some
parts?
If it updates, I think the header should contain the info.
Also, I am thinking that you might want to add it to normative references.

Thanks,
--
Yoshi

On Wed, Jun 16, 2021 at 7:05 AM Giuseppe Fioccola <
[e-mail]> wrote:

> Dear Yoshi,
> Thanks a lot for your review.
> Please find my answers inline tagged as [GF].
>
> Regards,
>
> Giuseppe
>
>
> -----Original Message-----
> From: Yoshifumi Nishida via Datatracker <[e-mail]>
> Sent: Wednesday, June 16, 2021 10:49 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06
>
> Reviewer: Yoshifumi Nishida
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments were
> written primarily for the transport area directors, but are copied to the
> document's authors and WG to allow them to address any issues raised and
> also to the IETF discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> Summary: I think this document is on the right track, but it needs to
> address
>                    the following points to be published as a PS document.
>
>
> 1: I think the doc should provide a high-level view of the usage of this
>    method. For example, it is not clear to me how measurement nodes
> interact
>    each other, exchange and compare information, etc. If it is provided in
>    other documents, it should be referred.
>
> [GF]: Sure, this is the base document on the data plane. We are already
> working on some documents for the control plane mechanisms, e.g.
> draft-ietf-idr-sr-policy-ifit, draft-chen-pce-pcep-ifit. They will be
> referred in the next version.
>
> 2: Section 5.1: "By counting the number of packets in each batch and
>    comparing the values measured by different network nodes along the path,
>    it is possible to measure the packet loss occurred in any single batch
>    between any two nodes."
>
>     -> It is not clear to me how two nodes exchanges the measured counts.
>        This point should be clarified even if if it's out-of-scope of the
>        document.
>
> [GF]: In the implementation the counters can be sent out to the
> controllers that is responsible of the calculation. Anyway it is also
> possible to exchange this information by using other on-path techniques. We
> will add more details in the next version but the detailed description will
> be done in a separate document.
>
> 3: Section 5.1: "In a few words this implies that the length of the batches
>    MUST be chosen large enough so that the method is not affected by those
>    factors."
>
>     -> It would be better to have recommended length values here.
>        At least, it would be better to provide some guidances to decide
>        the value.
>
> [GF]: Agree. I will add a pointer to section 3.2 of RFC 8321, where it is
> possible to find the guidance to and in particular the mathematical
> formulation to decide the value.
>
> 4: Section 5.1:
>    Can we change the length of batch in the middle of data transfer?
>    Also, is there any concerns to use different length for each flow?
>    I think it would be better to specify on these points.
>
> [GF]: In theory it is possible. It is up to the implementation. The length
> of batches can be changed over time and among different flows. It could
> complicate the correlation of the information but it can be done to allow a
> flexible monitoring. We can specify these aspects.
>
> 5: Section 5.2:
>    I am wondering if this approach requires time sync between nodes or not.
>    This point should be clarified.
>
> [GF]: As explained in section 4.1 of RFC 8321, the Alternate Marking
> technique does not require a strong synchronization. In section 3.2 of RFC
> 8321 it is reported the condition that must be satisfied on the
> synchronization accuracy. I'm thinking to add a pointer or summarize the
> concept in this document as well.
>
> 6: Section 5.2:
>    "Whenever the L bit changes and a new batch starts, a network node
>    can store the timestamp of the first packet of the new batch, that
>    timestamp can be compared with the timestamp of the first packet of the
>    same batch on a second node to compute packet delay."
>
>      -> It is not clear to me how two nodes compare the stored timestamps.
>         This point should be clarified.
>
> [GF]: It is similar to the case of packet loss. In the implementation the
> timestamps can be sent out to the controllers that is responsible of the
> calculation or could also be exchanged using other on-path techniques. We
> will add more details here too.
>
> 7: Section 5.2:
>    What's the benefits for using the approach described in 1.?
>    The use cases for it should be described.
>
> [GF]: The approach with double marking is better but we also mention the
> single marking for the sake of completeness. I can explain this and we can
> also highlight that the two approaches can also be combined to have more
> information.
>
> --
> Yoshi
>
>
>