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.
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).
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.
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. 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.
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.
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.
Happy to discuss any of the above. Once a -25 addresses items 1–5, I'll move
this to IESG evaluation.
Thanks.
Mahesh Jethanandani
[email protected]
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
