Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Mark,

Thanks much and now it is me to say sorry for the delay in responding. We'll add the additional paragraphs you suggest to the next revision.
Based on the outcome of the WG discussion on Friday we can decide whether folks are interested in broadening the scope of the doc to become more generic.

Thanks again, Frank

-----Original Message-----
From: Mark Smith <[e-mail]> 
Sent: Sonntag, 24. März 2019 03:00
To: Frank Brockners (fbrockne) <[e-mail]>
Cc: C. M. Heard <[e-mail]>; 6man WG <[e-mail]>; [e-mail]
Subject: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)

Hi Frank,

Apologies not to get back to you sooner, I missed this email (and now have a filter to highlight emails directly sent to me). Also apologies for sending feedback so close to IETF104.

On Thu, 14 Mar 2019 at 03:23, Frank Brockners (fbrockne) <[e-mail]> wrote:
>
> With the upcoming meeting in Prague, I wanted to come back to this discussion:
>
> We've just recently posted a new draft (draft-ioametal-ippm-6man-ioam-ipv6-deployment-00) - which summarizes a set of deployment considerations for IOAM with IPv6, i.e. complementing 6man draft-ioametal-ippm-6man-ioam-ipv6-options-01. draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 also includes the deployment scenario that Mark detailed below.
>
> Appreciate your thoughts - especially from 6man to provide for proper guidance to IPPM.
>

<snip>

Thanks very much to you and the other authors for writing up that this Internet Draft.

Regarding

"3.  Considerations for IOAM deployment in IPv6 networks"

that's an excellent list and set of descriptions of what I think are the requirements for when information is added to an existing IPv6 packet as it transits a network domain that wishes to add and then remove local domain supplementary information.

I think those requirements also apply to the addition of Segment Routing information to existing packets as they transit an SR domain, so one thought could be to extract them out and publish them as a more general Internet Draft, titled something like "Considerations For Adding Supplemental Information to IPv6 Packets Transiting a Network Sub-Domain". (Actually, reading more, I think most of the ID is not really that specific to IOAM, so most of the ID could probably be published as a more generic document on considerations for adding supplemental information to transit IP packets).


Regarding,

"5.1.1.  IPv6-in-IPv6 encapsulation"

where the outer encapsulation header destination IPv6 address is set to the same as the inner, original IPv6 destination address, for packets transiting the IOAM domain, I think that method would be quite vulnerable to C3:

"C3 Packets with IOAM data or associated ICMP errors, should not
      arrive at destinations which have no knowledge of IOAM.  Consider
      using IOAM in transit devices; misleading ICMP errors due to
      addition and/or presence of OAM data in the packet can confuse a
      source of the packet that did not insert the OAM information."


As the outer header IPv6 address is exterior to the IOAM domain as it is also the inner packet's DA, it means that standard and default IPv6 destination address based forwarding would forward the packet as is (i.e. encapsulated with IOAM information) external to the domain, without removing the outer IPv6 encapsulation and the IOAM information. In other words, IOAM information would leak if standard
IPv6 forwarding was used, which of course is enabled by default for
IPv6 routers.

To prevent that, the egress IOAM device would have to use non-standard, non-default IPv6 forwarding, which means deeper inspection of each and every egress packet regardless of its destination address, to see if it is an encapsulated IOAM packet, and to then remove the outer IPv6 header and IOAM information if it exists, before then standard IPv6 forwarding the original inner packet.

The advantage of using a separate and IOAM domain local and interior address space as in "5.1.2.  IP-in-IPv6 encapsulation with ULA", is that the outer packet ULA destination address is distinguishing which packets need IOAM encapsulation processing from those that don't (and of course, as the ULA address space is local to and unique to the IOAM domain, if they do leak externally, they have no valid destination to reach).

As those encapsulated IOAM packets are distinguished using the (outer) Destination Address, the selector for standard IPv6 forwarding, there is now no need for any special, new and more complex packet handling by the IOAM domain egress device. Using standard IPv6 forwarding avoids the complexity and implementation that would then be imposed on every router implementation that could be used as an egress IOAM domain device.

"2. To simplify debugging in case of leaked IOAM data fields in

       packets, consider a new IOAM E2E destination option to identify
       the Source IOAM domain (AS, v6 prefix).  Insert this option into
       the IOAM destination options EH attached to the outer IPv6
       header.  This additional information would allow for easy
       identification of an AS operator that is the source of packets
       with leaked IOAM information."

is suggesting a solution to the leaked IOAM issue. However I think it is always better to avoid a problem using an alternative method if possible, rather than to continue to let it the problem exist and then mitigate or eliminate its effects with even further mechanisms. It's more complexity to mitigate or eliminate, and that's more things that can break.


Regarding,

"5.1.2.  IP-in-IPv6 encapsulation with ULA"

Some suggested text -

"Addressing and routing in the ION 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."

add something like

"This would create an internal IPv6 forwarding topology using the IOAM domain's interior ULA address space that 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 in the future, 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."


"Assuming that the operational guidelines specified in Section 4 of
   [RFC4193] are properly followed, the probability of leaks in this
   approach will be almost close to zero."

add something like

"If the packets do leak through IOAM egress device misconfiguration or partial IOAM egress device failure, the packets' ULA destination address is invalid outside of the IOAM domain. There is no exterior destination to be reached, and the packets will be dropped when they encounter either a router external to the IOAM domain that has a packet filter that drops packets with ULA destinations, or a router that does not have a default route."


Regards,
Mark.