Hi Ron, Thank you for reviewing the document and providing your feedback.
1) In Section 3.2, bullet 1, you say, "The underlay head-end node constructs an ICMP error message destined for the overlay endpoint." Can I assume that a) the source address is that of the head-end node, b) the ICMP message type is copied from the incoming ICMP message and c) the ICMP code is copied from the incoming ICMP message? [Authors] a) Source Address: Yes. As the originator of the new message, the head-end node uses its own IP address as the source. b) ICMP Message Type: No, it is not necessarily assumed that the ICMP message type is directly copied. The draft states that the underlay head-end node "constructs" a new ICMP error message and acts as an "intermediary, translating an underlay error into a new error message." This implies a selection process rather than a direct copy. The purpose of the outer ICMP message type (e.g., Time Exceeded, Destination Unreachable) is to convey the general nature of the error to the overlay endpoint from its perspective. Section 3 explicitly lists the specific ICMP error types (ICMPv4/v6 Time Exceeded, Destination Unreachable, Parameter Problem) that can carry a UIO. The head-end node would select the most appropriate type from this predefined set to signal the effective impact on the overlay traffic. The specific type of the original underlay error message would then be conveyed as part of the diagnostic information inside the UIO payload itself. c) ICMP Code: No. The head-end node sets the ICMP code to match the selected outer ICMP message type. For instance, an IPv6 underlay error might result in an ICMPv4 Time Exceeded (Code 0) message to an IPv4 overlay endpoint, with the original specific code carried in the UIO. 2) If the type is copied from the incoming ICMP message, what does the head-end do when it receives a non-extensible ICMP message from the underlay (e.g., packet too big)? [Authors] Our draft does not propose copying the ICMP type. If the head-end receives an "ICMP Packet Too Big" message (which is not an allowed type for UIO encapsulation per Section 3), it would: * Select one of the permitted ICMP error types (e.g., Destination Unreachable). * Encapsulate the detailed "Packet Too Big" information (type, code, MTU) within the UIO payload of this newly constructed message. 3) When the head-end receives an ICMP message, how does it determine whether the message is for its own consumption or for consumption by another node in the overlay. [Authors] The determination relies on two main factors: * Original Datagram Inspection: The head-end examines the "Part of Original Datagram" within the incoming ICMP error message to identify if it relates to traffic previously encapsulated for an overlay session. * Local Policy: Configuration (Sections 4.1 and 6.1) dictates whether UIO generation is authorized for that specific overlay context. 4) Do you think that you might need to update RFC 4443, Section 4.2, Rule e.1? [Authors] Yes, an update or an explicit exception to RFC 4443, Section 2.4, Rule (e.1) is warranted. The UIO mechanism, as described in the draft, involves the underlay head-end node originating a new ICMP error message in response to receiving an initial ICMP error message from the underlay. This behavior directly conflicts with the existing prohibition in RFC 4443 against originating an ICMP error message as a result of receiving another ICMP error message. We will address this in the next revision. Thanks, Madhan From: Ron Bonica <[email protected]> Date: Saturday, 18 October 2025 at 6:17 AM To: Madhan Sankaranarayanan (madsanka) <[email protected]>, [email protected] <[email protected]> Cc: Jaganbabu Rajamanickam (jrajaman) <[email protected]>, Darren Dukes (ddukes) <[email protected]> Subject: Re: [INTAREA] Call for Review: New Internet-Draft on ICMP extension for underlay info (-03) Folks, Thanks for writing this document. A few quick questions: 1. In Section 3.2, bullet 1, you say, "The underlay head-end node constructs an ICMP error message destined for the overlay endpoint." Can I assume that a) the source address is that of the head-end node, b) the ICMP message type is copied from the incoming ICMP message and c) the ICMP code is copied from the incoming ICMP message? 2. If the type is copied from the incoming ICMP message, what does the head-end do when it receives a non-extensible ICMP message from the underlay (e.g., packet too big)? 3. When the head-end receives an ICMP message, how does it determine whether the message is for its own consumption or for consumption by another node in the overlay. 4. Do you think that you might need to update RFC 4443, Section 4.2, Rule e.1? Ron ________________________________ From: Madhan Sankaranarayanan (madsanka) <[email protected]> Sent: Tuesday, October 14, 2025 3:30 PM To: [email protected] <[email protected]> Cc: Jaganbabu Rajamanickam (jrajaman) <[email protected]>; Darren Dukes (ddukes) <[email protected]> Subject: [Int-area] [INTAREA] Call for Review: New Internet-Draft on ICMP extension for underlay info (-03) [External Email. Be cautious of content] Dear Internet Area Working Group, We are pleased to announce the publication of a new version of our Internet-Draft and would appreciate your review and comments. Draft Name: draft-jags-intarea-icmp-ext-underlay-info-03 Title: ICMP extension to include underlay information Abstract: Network operators managing overlay networks require visibility into underlay network hops during traceroute operations from overlay endpoints. This document defines an ICMP extension object, the Underlay Information Object (UIO), which allows underlay head-end nodes to encapsulate underlay error information within ICMP error messages. This mechanism provides overlay operators with crucial visibility into underlay network paths for troubleshooting. You can find the draft here: https://datatracker.ietf.org/doc/draft-jags-intarea-icmp-ext-underlay-info/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-jags-intarea-icmp-ext-underlay-info/__;!!NEt6yMaO-gk!B8mYO_yOVgsyIjMavyTdZ6MfwJ-Pn9IraWhbJi24ZHspUa3mvDSXgD5IV1faj-i91UvVTihFdeV4BL7IW6wweOO2Le-uO6s$> We welcome all feedback and comments on this document. Thanks, Madhan Juniper Business Use Only
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
