Hello Tianran,
Thank you for your review and feedback. Sorry for the late response. I am revising the draft based on this, gen-art, sec-dir feedback.
Regarding your concern on the Increment Tracing option, it has a RemainingLen field to restrict the length the option data can grow to.
This is elaborated in RFC 9197.
Will a new deployment consideration with the following text address your concern:
C7 The IOAM Incremental Trace Option-Type expands the
option length that may affect the processing of extension
headers and options that follow IOAM options.
Hence when IOAM Incremental Trace Option-Type is
used in the deployment the RemainingLen field of the option
must follow the guidance in RFC9197 and must
be computed and set appropriately.
option length that may affect the processing of extension
headers and options that follow IOAM options.
Hence when IOAM Incremental Trace Option-Type is
used in the deployment the RemainingLen field of the option
must follow the guidance in RFC9197 and must
be computed and set appropriately.
Thanks,
Shwetha
On Wed, Jul 13, 2022 at 12:39 PM Tianran Zhou via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Tianran Zhou
Review result: Has Issues
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
It is good to describe the deployment consideration in section 5. However, I
think there is an issue that the increamental tracing option will impact other
IPv6 extension header processing, e.g. SRH. This is similar to the
consideration about PMTU, which has many ways to detect. But it is different.
The increamental option is encapsulated in HbH which is the first EH. As the
option length expands, the intermedate node may not be able to process other
EHs. Typically, SRH is used for TE. This will break the network service.
Best,
Tianran
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call