IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)
draft-ietf-ippm-ioam-ipv6-options-12
Yes
(Martin Duke)
No Objection
Erik Kline
Murray Kucherawy
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Erik Kline
(was Discuss)
No Objection
John Scudder
(was Discuss)
No Objection
Comment
(2023-05-05 for -11)
Sent
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-11 CC @jgscudder ## COMMENT Thanks for taking care of my previous DISCUSSes and many of my earlier comments. There remain a few comments that weren't addressed in versions 10 or 11 nor responded to in email, please forgive me if I've missed a response. I repeat the comments below, with section numbers updated to match the numbering in versions 10 and 11. ### Section 3, reference for IOAM Type, nomenclature ``` IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197]. ``` Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA Considerations section. I wouldn't say an IANA registry "defines" anything, it lists code points. I think a better reference would be Section 4 of 9197, which does indeed define IOAM-Option-Types (in Section 4.1). Also, it would be better to be consistent with your naming, in RFC 9197 you don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34 occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4 occurrences in 9197). I see why you don't want to use the full string from RFC 9197 in your packet diagram (too many characters) but "IOAM-Opt-Type" would fit in the character budget. ### Section 4.2, encapsulation? ``` For deployments where the IOAM domain is bounded by hosts, hosts will perform the operation of IOAM data field encapsulation and decapsulation. ``` Do you intend to imply that the hosts at the edge of the domain are sending IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the hosts are the source/sink of the packets, the problem described in C6 doesn't apply, and the host can directly place the IOAM data in the header. (What would be the "inner header" in an overlay solution.) I suppose it's technically accurate to describe this as an "encapsulation and decapsulation" operation, insofar as any data placed in any header might be said to be encapsulated in that header -- but it's misleading. I think this section needs to be rewritten to make the meaning plain. For example, something like "... hosts will place the IOAM data field directly in the IPv6 header." (You could say "outer IPv6 header" since there's nothing precluding a host from sending tunneled packets for some purpose.) (I notice Éric Vyncke raises a similar concern about the nontraditional use of the term "encapsulation" in his comments.) ### Section 4.3, encapsulation again This one is less misleading, but by analogy to 4.2 I suspect more clarity is required here too. ``` For deployments where the IOAM domain is bounded by network devices, network devices such as routers form the edge of an IOAM domain. Network devices will perform the operation of IOAM data field encapsulation and decapsulation. ``` For example, a more straightforwardly understandable version of the last sentence might be "Network devices will encapsulate in-flight packets in an outer IPv6 header which carries the IOAM data field." ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
Murray Kucherawy
No Objection
Paul Wouters
No Objection
Comment
(2022-11-24 for -09)
Sent
I support Roman's DISCUSS points. NITS: It is non-standard to list contributors at the start of the document. Usually this is done in an acknowledgement section at the end of the document. Any reason why not to move the Contributors section just before or within the Acknowledgement section ? are encapsulated in the IPv6 -> are encapsulated in IPv6
Roman Danyliw
(was Discuss)
No Objection
Comment
(2023-03-01 for -10)
Sent for earlier
Thank you for addressing my DISCUSS and COMMENT feedback.
Éric Vyncke
(was Discuss)
No Objection
Comment
(2023-03-06 for -10)
Sent
Thanks for addressing my previous blocking DISCUSS issue. For archive: https://mailarchive.ietf.org/arch/msg/ippm/iFh9vrAOZ-79nVqR3QF5kOEKUcM/ -éric
Warren Kumari
Abstain
Comment
(2022-11-29 for -09)
Sent
I spent a while oscillating between DISCUSS and NoObjection when balloting on this document, before finally settling on Abstain (a non-blocking position).
Like others, I have concerns about what happens when IOAM EH packets invariably leak outside the IOAM domain. My views align very strongly with John Scudder's, but seeing as he is already carrying the DISCUSS, I'm going to cowardly abstain and hide behind him.
The document feels like it is creating something very similar to a "limited domain"; the reason that I'm not balloting DISCUSS is that the document "feels" like it is trying to minimize the damage when IOAM packets do leak. This includes "failing closed" ('IOAM MUST be explicitly enabled per interface on every node within the IOAM domain'). I am, however, quite troubled by the "As additional security, IOAM domains MUST provide a mechanism to prevent unauthorized injections at ingress or leaks at egress." without actually stating how this would be performed.
The fact that the IOAM data is information (it doesn't obfuscate the source of the traffic, nor (hopefully!) change routing / forwarding) also helps push this from DISCUSS to Abstain for me - when a domain *does* leak packets with IOAM info, they will either exceed the MTU and so be dropped, or will "just" be leaking traffic stats from that domain, and should otherwise be forwarded OK.
There are some Considerations in Sec 5 which I think are unrealistic, but not harmful - for example:
* I suspect that in some cases adding IOAM will change ECMP hashing (C1);
* they *will* leak (C3), but this shouldn't break things;
* they *will* leak (C4), but I suspect that external devices will simply ignore the EH header;
I have a horrible feeling that I'm being inconsistent with my balloting: normally I would ballot DISCUSS on documents which either add information to an in-flight packet, or which create any sort of closed domain, but in this case I feel that the document has sufficiently attempted to mitigate the (external) consequences of leaks that I'm choosing Abstain instead.
Martin Duke Former IESG member
Yes
Yes
(for -09)
Unknown
Andrew Alston Former IESG member
(was Discuss)
No Objection
No Objection
(2023-03-20 for -10)
Sent
Hi, Firstly thanks for the modifications to the text. While I still support the discuss points raised by John, I'm going to clear my discuss based on the fact that I think that the new next in C2 seems to address my destination option query, since I'm going to presume that if the destination address is a SID - it stands to reason that where a SID is not bound to a specific interface, it cannot be IOAM enabled and therefore the packets should be ignored.
Lars Eggert Former IESG member
No Objection
No Objection
(2022-12-07 for -09)
Sent
# GEN AD review of draft-ietf-ippm-ioam-ipv6-options-09 CC @larseggert Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/N0aMpTOtDieVf0vT6Tu2reLFewI). ## Comments I find myself agreeing with the numerous DISCUSS positions, but I trust the ADs that raised them to resolve them with the authors. ### Section 4, paragraph 28 ``` All the in-situ OAM IPv6 options defined here have alignment requirements. Specifically, they all require 4n alignment. This ``` I haven't come across the term "4n alignment" before. Suggest to rephrase (by using the text in the following sentence.) ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 5.1, paragraph 4 ``` - C3 Packets with IOAM data or associated ICMP errors, should not - - ``` ### Outdated references Document references `draft-ietf-ippm-ioam-direct-export`, but that has been published as `RFC9326`. ### URLs These URLs point to tools.ietf.org, which has been taken out of service: * https://tools.ietf.org/id/draft-kitamura-ipv6-record-route-00.txt These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 ### Grammar/style #### Section 5.1, paragraph 3 ``` IOAM. For example, if IOAM is used in in transit devices, misleading ICMP er ^^^^^ ``` Possible typo: you repeated a word. #### Section 5.1, paragraph 3 ``` ommunicate the errors to devices outside of the IOAM domain MUST remove any ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". #### Section 5.1, paragraph 5 ``` options that follow IOAM options. Hence when the IOAM Incremental Trace Opt ^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Hence". #### Section 5.4.1, paragraph 1 ``` LA destination address is invalid outside of the IOAM domain. There is no ext ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Robert Wilton Former IESG member
No Objection
No Objection
(2022-12-01 for -09)
Sent
Hi,
Thanks for this doc.
Minor level comments:
(1) p 5, sec 4. In-situ OAM Metadata Transport in IPv6
IPv6 options can have a maximum length of 255 octets. Consequently,
the total length of IOAM Option-Types including all data fields is
also limited to 255 octets when encapsulated into IPv6.
Given the alignment requirements, wouldn't the max length be slightly smaller, e.g. 252 bytes?
(2) p 6, sec 5.2. IOAM domains bounded by hosts
For deployments where the IOAM domain is bounded by hosts, hosts will
perform the operation of IOAM data field encapsulation and
decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or
Destination options as specified in this document.
For clarity, does this mean that in this case that there is presumably no need to encapsulate the host packet within a separate IPv6 packet, and the OAM extension header could be embedded directly when the v6 header of the host packet is being constructed?
(3) p 7, sec 5.4.1. IP-in-IPv6 encapsulation with ULA
An
IPv6 header including IOAM data fields in an extension header is
added in front of it, to forward traffic within and across the IOAM
domain.
Rather than saying add an IPv6 in front of it, wouldn't be more accurate to say that it is being encapsulated with an IPv6 header including the IOAM data fields?
(4) p 7, sec 5.4.1. IP-in-IPv6 encapsulation with ULA
IPv6 addresses for the IOAM Overlay Network, i.e. the outer
IPv6 addresses are assigned from the ULA space. Addressing and
routing in the IOAM Overlay Network are to be configured so that the
IP-in-IPv6 encapsulated packets follow the same path as the original,
non-encapsulated packet would have taken. This would create an
internal IPv6 forwarding topology using the IOAM domain's interior
ULA address space which is parallel with the forwarding topology that
exists with the non-IOAM address space (the topology and address
space that would be followed by packets that do not have supplemental
IOAM information). Establishment and maintenance of the parallel
IOAM ULA forwarding topology could be automated, e.g., similar to how
LDP [RFC5036] is used in MPLS to establish and maintain an LSP
forwarding topology that is parallel to the network's IGP forwarding
topology.
Maintaining a separate ULA forwarding topology seems to introduce a certain level of additional complexity. Is there any risk of the parallel forwarding plane programming lagging behind the non-IOAM topology such that different paths through the network would be taken?
(5) p 8, sec 6. Security Considerations
As this document describes new options for IPv6, these are similar to
the security considerations of [RFC8200] and the weakness documented
in [RFC8250].
Are there any security considerations relative to using ULA addressing for encapsulating the traffic that should be documented here?
Regards,
Rob