Hi Ines, Thanks a lot for your review. Please see inline > -----Original Message----- > From: Ines Robles via Datatracker <noreply@xxxxxxxx> > Sent: Thursday, 17 November 2022 00:47 > To: gen-art@xxxxxxxx > Cc: draft-ietf-ippm-ioam-deployment.all@xxxxxxxx; ippm@xxxxxxxx; last- > call@xxxxxxxx > Subject: Genart last call review of draft-ietf-ippm-ioam-deployment-02 > > Reviewer: Ines Robles > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please treat these comments just like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ippm-ioam-deployment-02 > Reviewer: Ines Robles > Review Date: 2022-11-16 > IETF LC End Date: 2022-11-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > The document provides a framework for "In-situ" Operations, Administration, > and Maintenance (IOAM) deployment and discusses IOAM Deployment, Types of > IOAM, IOAM Encapsulations, IOAM Data Export, Deployment Considerations > and IOAM Manageability The document is well written, and has a good set of > references. > > I have some minor questions that I set as nits. > > Major issues: None > > Minor issues: None > > Nits/editorial comments/Questions: > > 1- Page 19: "... defining performance limits on IOAM encapsulation and IOAM > exporting" -> how are defined the performance limits? ...FB: The sentence that follows the sentence in question tries to explain what is supposed to happen: " By limiting the rate and/or percentage of packets that are subject to IOAM encpasulation and the rate of exported traffic, it is possible to confine the impact of such attacks." How about we make sure that the sentences link a bit better: OLD: Such DoS attacks can be mitigated by deploying IOAM in confined administrative domains, and by defining performance limits on IOAM encapsulation and IOAM exporting. By limiting the rate and/or percentage of packets that are subject to IOAM encpasulation and the rate of exported traffic, it is possible to cofine the impact of such attacks. NEW: Such DoS attacks can be mitigated by deploying IOAM in confined administrative domains, and by limiting the rate and/or percentage of packets that an IOAM encapsulating node adds IOAM information to, as well as limiting rate and/or percentage of packets that an IOAM transit or IOAM decapsulating node creates to export IOAM information extracted from the data packets that carry IOAM information. > 2- What about the IOAM > Data overhead? if it is possible to have it, how to handle it? ...FB: I'm not 100% sure what you are referring to when you say "data overhead". Could you detail your question a bit further? IOAM adds information to user data traffic. This grows the size of the packet. Section 3. (IOAM deployment) discusses that requirements and prerequisites, e.g., that the MTU of all links within an IOAM domain is sufficiently large to support the increased packet size due to IOAM. > 3- The IOAM data is > inserted in the packet, even if the data payload is zero? or this scenario is not > possible? ...FB: Yes. IOAM could be added to a packet with zero payload. IOAM does not make any assumptions about the payload of the packet. > 4- In [https://datatracker.ietf.org/meeting/104/materials/slides-104- > 6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in- > situ-oam-with-ipv6-options-00.pdf] > states: "Packet forwarding behaviour or decisions should not change due to > presence of IOAM". Does this apply to this document as well, right? ...FB: Yes. draft-ietf-ippm-ioam-ipv6-options-09 states in section 5 this desired behavior: "It is desirable that the addition of IOAM data fields neither changes the way routers forward packets nor the forwarding decisions the routers take." So far we limited the draft-ietf-ippm-ioam-deployment to deployment considerations - rather than discussing desired behavior. Do you think that it would be worth replicating section 5.1 ("Considerations for IOAM deployment and implementation in IPv6 networks") into draft-ietf-ippm-ioam-deployment? We'd obviously make the text generic and not specific to IPv6. Thanks again for your review. Cheers, Frank > > Thanks for this document, > Ines. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
