Hi Mahesh,
Thank you for your thorough review, we have submitted a new version (-25) based
on your comments, please see my feedback inline[Chongfeng],
From: Mahesh Jethanandani
Date: 2026-07-09 06:39
To: draft-ietf-v6ops-framework-md-ipv6only-underlay.all
CC: list; jinmei; gen-art; Brian Trammell; secdir
Subject: [v6ops] AD Followup: draft-ietf-v6ops-framework-md-ipv6only-underlay-24
Authors,
Thanks for the work on -24 — it cleaned up essentially everything from my
earlier review (RFC 6052 Table 1, the PE/RFC 4026 definition, the Operational
Considerations section, and several other items). I've now also read the five
directorate reviews from Last Call (INTDIR/Jinmei, GENART/Bryant,
TSVART/Trammell, OPSDIR/Chown, SECDIR/Lonvick), thank you to all of them.
Before I can send this to the IESG, I'd like the following addressed. None of
these rise to a blocking technical issue for an Informational document, but I
want them closed out in a -25.
1. Mapping rule exchange mechanism (INTDIR, major)
Section 5.2 explicitly leaves the address-mapping-rule exchange mechanism open
("other protocols," "non-routing mechanisms... outside the scope of this
document") while the rest of the framework's interoperability depends on it.
I'm not asking you to mandate MP-BGP normatively, but please add a short
paragraph stating the properties any exchange mechanism needs to satisfy —
e.g., that it must convey the Forwarding Type field from Section 4.1, and that
it must scale across multiple independently-administered operators. Right now,
a reader can't tell what "done right" looks like for anything other than the
IDR draft.
[Chongfeng]: Based on your suggestion, a short paragraph is added in section
5.2,
“Address mapping rules generated on a PE device need to be distributed to
PE devices in other domains. During the transmission of these rules,
the key information elements, including the Forwarding Type field defined
in Section 4.1, must not be modified by any intermediate node.
Furthermore, the transmission procedure must support scalability
across multiple independently administered network providers (NPs)”
2. Likely typo in Section 4.2
"[I-D.ietf-idr-mpbgp-extension-4map6] can be implemented in PE1 and PE2..." —
the worked example throughout is PE1 (ingress) to PE3 (egress), and the very
next sentence correctly says "from PE3 to PE1." Please confirm and fix (PE2
doesn't appear elsewhere in this scenario).
[Chongfeng]: Yes, it is a typo, it has been changed to PE3.
3. ECN / Traffic Class handling (TSVART, major)
Section 7 cites RFC 7915 Section 1.4 and Section 4.2/5.2 for MTU and ICMP
handling, but doesn't mention Traffic Class/ECN, which RFC 7915 Section 4.1/5.1
covers separately. Those sections give translators a SHOULD-level option to
zero the TOS/Traffic Class octet entirely on translation ("administrative
bleaching"), which silently kills ECN if an operator enables it for DSCP
hygiene. Please add a sentence alongside the existing MTU guidance pointing to
Section 4.1/5.1 and noting this interaction.
[Chongfeng] Based on your suggestion, the following sentence has been added
in section 7.
“It should be noted section 4.1 and section 5.1 of RFC7915 give translators
a SHOULD-level
option to zero the TOS/Traffic Class octet entirely on translation
("administrative bleaching"),
which silently kills ECN if an operator enables it for DSCP hygiene.”
4. Cross-domain MTU framing (TSVART, major)
Worth two things here: first, per Section 4.2, only the ingress/egress PEs
convert packets — intermediate P routers just forward, so the 20/40-byte
overhead is incurred once, not per-AS-hop. It would help to state that
explicitly, since it directly addresses Brian's "each hop adds a penalty"
framing.
[Chongfeng]: Based on your suggestion, the following change has been made
in section 4.2,
OLD:
In this case, the IPv6 data path is between PE1 and PE3, there are
only two IPv4-IPv6 conversion actions, which occur in PE1 and
PE3 respectively.
NEW:
In this case, only the ingress/egress PEs, i.e. PE1 and PE3, convert
packets - intermediate P routers just forward, so the overhead
caused by IPv4/IPv6 packet header transformation is incurred
once, not per-AS-hop.
Second, the real multi-domain-specific risk is Path MTU Discovery reliability —
an ICMPv6 Packet Too Big from a P router in one operator's AS has to reach the
originating IPv4 host across administrative boundaries with independent
ICMP-filtering policies. That's a materially different risk than single-domain
PMTUD and is exactly what this framework's multi-operator scope introduces. A
couple of sentences on cross-domain PMTUD/ICMP reachability would close this
out.
[Chongfeng]: Based on your suggestion, the following sentence is added in
section 7,
“One multi-domain-specific potential risk is Path MTU Discovery reliability —
an ICMPv6 Type 2
(Packet Too Big) message from a P router in one IPv6 carrier's AS has to reach
the originating IPv4
host across administrative boundaries with independent ICMP-filtering policies.
In this case, IPv4 hosts
may not receive "Packet Too Big" notifications, and will keep trying to send
large packets. These
packets will then be repeatedly dropped along the path, ultimately leading to
connection interruptions
or severe performance degradation—forming a "PMTUD black hole." To address
this situation, it is
recommended to coordinate cross-domain ICMP policies. The two carriers need to
negotiate and
establish management‑level Service Level Agreements (SLAs) or security policy
exceptions to ensure
that critical ICMPv6 Type 2 (Packet Too Big) messages are allowed to traverse
the administrative boundary
in both directions. For example, ICMP traffic originating from the trusted AS
of the peer can be rate‑limited
and deeply inspected before being permitted, rather than being completely
blocked.”
Nothing further needed:
GENART's UDP zero-checksum comment is already covered by reference — RFC 7915
Section 4.5 has SHOULD-level guidance for this, and Section 5.3 already says
translation complies with RFC 7915. You can note this in your response to
Stewart without touching the document.
[Chongfeng]: OK.
Everything else from the five directorate reviews (Section 3's AS/NP wording,
the CAPEX acronym, the default-rule forward reference, the OPTIONAL/MUST split
in 8.3, the Section 8.2 boilerplate for SECDIR) is already fixed in -24 and
needs no further action.
A handful of NITs (subject-verb agreement in Section 3, a comma splice and a
contraction in Section 4.1, and "one default address mapping rule" wording in
5.2) are in the attached review file — pick these up whenever convenient, no
need to report back on them.
[Chongfeng]: Some NITs found have been fixed.
Happy to discuss any of the above. Once a -25 addresses items 1–5, I'll move
this to IESG evaluation.
[Chongfeng]: Thank you.
Best regards
Chongfeng
On behalf of all the co-authors
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
