Madhan,
Inline RB>
Ron
________________________________
From: Madhan Sankaranarayanan (madsanka) <[email protected]>
Sent: Thursday, October 23, 2025 12:17 PM
To: Ron Bonica <[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)
[External Email. Be cautious of content]
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.
RB> In order to produce interoperable implementations, you will have to add
more detail to Section 3.2. Maybe rules that say,
"If the head end receives an ICMP message that looks like this, it sends an
ICMP message that looks like that".
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.
RB> Again, more details are required. What does the head-end look for in the
original datagram to make the determination. Are there any corner cases that
would cause the head end to make the wrong determination?
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
Juniper Business Use Only
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
