Re: END SID Without SRH

[Mark Smith <[e-mail]>]

On Thu., 13 Jun. 2019, 07:52 Darren Dukes (ddukes), <[e-mail]>
wrote:

> Hello everyone.
>
> This document defines an SRH and a SID, and how that SID is processed.
>
> I expect anyone "surprised" by this fact should have read this draft at
> some point:
> a - within the past 2 years; since this document has defined a SID and its
> processing.
> b - within the past 13 months; since section 4.3.1 specifically described
> discarding the packet based on upper layer header being processed.
> c - within the past 8 months; since the current version of 4.3.1.2 was
> updated with the new ICMP error code, published, and the WG was notified
> via email.
>
> And recall section 3.1 defines a Source SR node as
>    "any node that originates an IPv6 packet with a
>    segment (i.e.  SRv6 SID) in the destination address of the IPv6
>    header.  The packet leaving the source SR Node may or may not contain
>    an SRH."
>
> In other words, there is no surprise.
>

So one of the contexts I consider is sitting in front of a packet capture
tool like Wireshark, and trying to troubleshoot a fault by looking at the
packet.

For the packet Ron described, with no SRH header, there is nothing to
distinguish it from a normal IPv6 packet. The fault would be that the
packet contains a TCP header, yet TCP processing is not occurring.

The DA address in the packet might actually be a SID, but if it is coming
from within the existing IPv6 unicast or multicast spaces, there is no
indication of that.

This SR processing is failing the principle of least surprise. That failure
can cause longer than necessary troubleshooting and longer customers'
services impacts. A network's MTTR is negatively impacted.

Mandating that all packets to be SR processed have an SRH would prevent
this problem. It would also be compliant with RFC 8200, because the
processing to occur on the packet when it arrives at the device with the DA
is explicitly encoded in the packet.

Without a formal SID address space, encoding functions to perform on a
packet in addresses is ambiguous, implicit and when troubleshooting,
non-obvious.

Regards,
Mark.


> Darren.
>
>
>