[ippm] Robert Wilton's No Objection on draft-ietf-ippm-ioam-ipv6-options-09: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-ioam-ipv6-options-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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