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 <giuseppe.fioccola@xxxxxxxxxx> 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 <noreply@xxxxxxxx>
Sent: Wednesday, June 16, 2021 10:49 AM
To: tsv-art@xxxxxxxx
Cc: draft-ietf-6man-ipv6-alt-mark.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
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 tsv-art@xxxxxxxx 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
