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

[Tom Herbert <[e-mail]>]

On Thu, Dec 19, 2019 at 7:12 PM Mark Smith <[e-mail]> wrote:
>
> 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.
>

Mark,

That's an awfully big assumption/requirement to make. I'm doubtful
that would be feasible for deployment in a large network. Note that
RFC2460 also required all nodes in the path to support HBH options and
look what happened!

> 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.
>
All good points, but I'm not sure that punting problems because their
hard to L2 is the answer. I could just as easily ask if MPLS was so
good, then why was segment routing even invented? Clearly there's
incentive to standardize on IP protocols for carrying end-to-end
information. Besides that, things are pretty far down the path for
sending IOAM over IPv6 and in fact there might even be consensus that
HBH options are the correct way to do that as opposed to a lot of
other hacks that have been suggested.

Tom

> 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
> > --------------------------------------------------------------------