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

["Rajiv Asati (rajiva)" <[e-mail]>]

I also think that there is a value in dividing this draft in 2 separate drafts – one generic, and another focused on IOAM specifics.

Also, it might be useful to distinguish the deployment considerations that relate to Inter-AS and/or Inter-Provider IOAM usage. For ex, C3, C4. An IOAM domain An AS can have more than one IOAM domains after all. In such usages, IOAM information would need to be exchanged outside the domain & AS.

BTW, wrt C6, which section of rfc8200 prescribes using encapsulation? IMO, using encap breaks C1. Of course, using option insertion into the original packets breaks C6. In light of that, it would be useful to add the 5.1.4 that lists non-encapsulation option as well.


--
Cheers,
Rajiv

From: ipv6 <[e-mail]> on behalf of Mark Smith <[e-mail]>
Date: Saturday, March 23, 2019 at 10:01 PM
To: "Frank Brockners (fbrockne)" <[e-mail]>
Cc: "C. M. Heard" <[e-mail]>, 6man WG <[e-mail]>, "[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]<mailto:[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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------