Hi Michael, Thanks for the review. Pls see inline for replies. Juniper Business Use Only -----Original Message----- From: Michael Tüxen via Datatracker <noreply@xxxxxxxx> Sent: Saturday, May 18, 2024 2:37 PM To: tsv-art@xxxxxxxx Cc: draft-ietf-mpls-spring-inter-domain-oam.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx Subject: Tsvart last call review of draft-ietf-mpls-spring-inter-domain-oam-14 [External Email. Be cautious of content] Reviewer: Michael Tüxen Review result: Ready with Nits 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. If I understand things correctly, an LSP ping packet is a UDP/IPv4 or UDP/IPv6 packet and the processing described in this document can increase the size of such a packet. I am wondering how IP level fragmentation is avoided, in case the packet gets larger than the MTU. <SH> The echo-request packet that is created on the head-end will not increase in size during transit. The echo-reply packet is constructed on the transit node/egress node and sent back to the source and is not Possible to avoid fragmentation because its not possible to get the MTU of the entire path especially when dynamic return path building mechanism is used. Nit: Section 3: Reply Path (RP) TLv -> Reply Path (RP) TLV -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
