Re: END SID Without SRH

On Thu, Jun 13, 2019 at 9:34 AM Darren Dukes (ddukes) <ddukes@cisco.com> wrote:
>
> Read the last paragraph of 4.3.1.2.
>
Darren,

That's:

"A unique error code allows an SR Source node to recognize an error in
SID processing at an endpoint."

You can call nodes that send a plain IP packets to a SID address "SR
Source nodes" if you wish, but you cannot assume that they know
anything about segment routing or participate in the protocol based on
the destination address. To a source host that doesn't understand
segment routing, getting a segment routing specific ICMP error is
nonsensical (as it would be to network monitoring of ICMP errors).
"Unrecognized next header" code makes sense to everyone, and for those
nodes that do understanding segment routing they can do additional
investigation on the destination address in the ICMP error data to see
if they had mistakingly sent to a SID.

Tom

> Darren
>
> > On Jun 13, 2019, at 4:03 PM, Tom Herbert <tom@herbertland.com> wrote:
> >
> >> On Thu, Jun 13, 2019 at 12:25 AM Darren Dukes (ddukes) <ddukes@cisco.com> 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.
> >>
> >> You notice the destination sending an ICMP parameter problem error with a code that says “SR Upper-layer Header Error”.
> >>
> >> This is how you tell the source is trying to talk to a destination address that doesn’t speak TCP.
> >>
> > How is that any different than sending an ICMPv6 parameter problem
> > error with code 1 that says “Unrecognized Next Header type
> > encountered”?
> >
> >> Darren
> >>
> >> On Jun 13, 2019, at 6:28 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> >>
> >>
> >>
> >>> On Thu., 13 Jun. 2019, 07:52 Darren Dukes (ddukes), <ddukes@cisco.com> 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.
> >>>
> >>>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------