Re: What is necessity for SRH, and other EH, insertion/removal?

[Mark Smith <[e-mail]>]

On Thu, 19 Dec 2019 at 09:08, Tom Herbert <[e-mail]> wrote:
>
> On Sat, Dec 7, 2019 at 9:17 AM Tom Herbert <[e-mail]> wrote:
> >
> > Pulling this out into a separate thread. Pertinent questions are:
> >
> > Why is extension header insertion and removal at necessary?
> >
> > Why isn't the proposed alternative of IPIP encapsulation sufficient?
> > (where the encapsulating headers contain the extension headers that
> > would otherwise be inserted)
> >
> I believe that inband network telemetry (INT and IOAM ) might provide
> the best motivation for extension header insertion. One of the goals
> is to allow network operators to perform telemetry on packets as they
> traverse their network. A telemetry header, INT or IOAM, is put into
> packets on ingress to the domain and removed at egress, and
> intermediate nodes modify the packet with measurement data.
>

So I assume that within an IOAM domain, the design would be that all
IP routers the packet passes through, from domain ingress to domain
egress, are IOAM capable.

Therefore, IOAM could be implemented as a layer 2 shim between the
link-layer header and the IPv6 original packet. The additional
overhead would only be the IOAM shim itself.

This is of course how MPLS works to add the label stack to existing IP packets.

Similar to MPLS, a FEC at ingress could be used to select which
packets have IOAM added or not.


> Key requirements are that not all packets for a flow need to be
> measured, and measured packets need to follow the same path as those
> not measured  in order for the measurements to reflect what is
> happening for the flow. IPIP encapsulation would change the hash that
> ECMP uses so encapsulated packets might traverse a different path--
> therefore it's not sufficient in this case. Extension header insertion
> would maintain the routing in ECMP (although the fact that extension
> headers aren't supported in IPv4 creates another problem).
>
> Some of the inband telemetry implementations are already addressing
> this by inserting the inband telemetry headers directly into the UDP
> or TCP payload of existing packets and removing the inserted payload
> bytes at the egress point. Since only transport payload is being
> modified, the packets will be routed the same way as other modified
> packets for a flow. The obvious problem with this approach is that
> payload is being changed by intermediate nodes such that if the end
> host were to ever receive the modified packet this could result in
> silent data corruption of users' data. So this protocol mechanism is
> fundamentally not robust and probably dangerous. I think this actually
> makes extension header insertion, where the worst case scenario is
> probably unexplained packet loss, look palatable!
>

The reason I have such strong opinions on this is that I first thought
about insertion verses encapsulation starting about 20 years ago.

I deployed Cisco's pre-standard version of "VLAN tagging",
Inter-Switch Link (ISL)*, which used Ethernet-in-Ethernet
encapsulation to add information to existing PDUs, back in the late
1990s. Then came along the IEEE 802.1Q spec in 1998, which specified
VLAN tagging using insertion into the frame, after the Ethernet header
and before the payload.

Thinking about the pros-and-cons at the time, I realised the Cisco
method was better, despite the E-in-E overhead, because the original
frame was preserved without modification. Although probably not by
design, the protection of the inner frame frame is strengthened while
being "VLAN trunked", because there is now the outer Eth FCS covering
the whole of the inner frame as well as the inner frame's own FCS
protecting its payload.

VLAN tagging via insertion corrupts the purpose and integrity of the
tagged frame's checksum / FCS, because it is recalculated and replaced
each time the VLAN tag is inserted and removed. It is now not a
reliable check that the frame received by the SA is the same frame
that was sent by the DA. VLAN tagging reduces the strength and purpose
of the FCS.

The only thing the checksum/FCS validates, in the presence of VLAN tag
insertion, is the last hop between the last switch/brige that removed
the VLAN tag and the device with the DA. The checksum/FCS is not
end-to-end anymore, and is failing to achieve its original purpose.
Frame corruption can occur within any of the VLAN tagging devices and
it won't be possible to detect, because the FCS is being recalculated
on the way out of the device after the VLAN tag has been added.

People might say this corruption hasn't ever happened because they
haven't heard of it happening. The trouble is that absence of evidence
is not evidence of absence.

So why insertion was used for VLAN tagging?

Radia Perlman explained it in her "Interconnections" book (2nd
edition). It was to accommodate existing Ethernet hardware at the time
that couldn't support frames large enough to use encapsulation. It's a
work around, not an ideal. Cisco could use Eth-in-Eth tunnelling
because they knew all of their hardware could support frames big
enough for that.

Regards,
Mark.


* "Inter-Switch Link and IEEE 802.1Q Frame Format",
https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html

> Tom
>
> > Please note, I'm asking for the technical justification of the
> > protocol design, saying that it's necessary because it's already being
> > deployed isn't useful in this regard.
> >
> > Tom
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------