Re: END SID Without SRH

[Mark Smith <[e-mail]>]

On Thu, 13 Jun 2019 at 17:25, Darren Dukes (ddukes) <[e-mail]> wrote:
>
> Mark.
>
> You remember your SIDs in your SR domain come from a SID block you created, S/s (see section 5.1) and this destination address falls within that space.
>

Humans really aren't all that good at remembering numbers. We even
make errors when

If IPv6 addresses are going to have special meaning and unconventional
RFC 8200 processing, they should come from a special purpose address
space - not one that is from within any of the the existing unicast
address spaces.

That would make it possible for if tools like Wireshark could have
know of a well known SID prefix so that they can identify and mark SR
packets. It reduces the operator's mental load while troubleshooting.
(Having

There are a lot of defined reserved IPv6 and IPv4 prefixes, for uses
that are more obscure than I'd think SR is intended to be e.g.
198.18.0.0/15 for Benchmarking, or 2001::/32 TEREDO.


I still think mandating the SRH in all to be SR processed packets is
better, even with a common well-known IANA assigned SID specific IPv6
prefix. It is explicit, rather than implicit in the packet's IPv6
addresses, and leverages existing mechanisms to deal with received
packet errors (i.e., ICMPv6 Parameter Problem,


> You notice the destination sending an ICMP parameter problem error with a code that says “SR Upper-layer Header Error”.
>

What if the device receiving the packet isn't SR capable or aware? It
will try to pass the packet to up to the TCP stack and process it. If
it generates a TCP RESET, it'll send the TCP RESET back to the SR
aware node than sent the packet in the first place.

Would that receiving SR node know what to do with a TCP RESET (or a
UDP triggered ICMPv6 Destination Unreachable Port Unreachable?) from
what is supposed to be an SR node?

I don't see any advice to only use ULA address space for SIDs
(assuming an IANA reserved prefix isn't chose), so with SIDs that fall
from within the GUA unicast address space, the likelihood of packets
leaking to non-SR aware nodes increases.

Regards,
Mark.



> This is how you tell the source is trying to talk to a destination address that doesn’t speak TCP.
>
> Darren
>
> On Jun 13, 2019, at 6:28 AM, Mark Smith <[e-mail]> wrote:
>
>
>
> 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.
>>
>>