Re: END SID Without SRH

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Bob. See inline.

On Jun 13, 2019, at 1:04 AM, Bob Hinden <[e-mail]<mailto:[e-mail]>> wrote:

Darren,

On Jun 12, 2019, at 2:52 PM, Darren Dukes (ddukes) <[e-mail]<mailto:[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.

I am trying to sort out this discussion.

I think the text in the draft this discussion is about is:

4.3.1.2.  Upper-layer Header or No Next Header

  When processing the Upper-layer header of a packet matching a FIB
  entry locally instantiated as an SRv6 SID defined in this document.

  IF (Upper-layer Header is IPv4 or IPv6) and
      local configuration permits {
    Perform IPv6 decapsulation
    Resubmit the decapsulated packet to the IPv4 or IPv6 module
  }
  ELSE {
    Send an ICMP parameter problem message to the Source Address and
    discard the packet.  Error code (TBD by IANA) "SR Upper-layer
    Header Error", pointer set to the offset of the upper-layer
    header.
  }

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


If I understand it correctly, the case for the action described in this section  is:

  When processing the Upper-layer header of a packet matching a FIB
  entry locally instantiated as an SRv6 SID defined in this document.

A node receiving this packet that knows it is SRv6 SID (because it was locally instantiated), would follow this procedure.

Correct.

A node who does not know that it is an SRv6 SID, will process the packet normally as defined in RFC8200/etc/etc.


Yes. This case is covered by section by 4.3.3 specifically, where the destination lpm matches a non-local Route.



4.3.3<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-19#section-4.3.3>.  FIB Entry Is A Non-Local Route


Processing is not changed by this document.


Essentially, a node will only do this if it is in an SRv6 domain because it has had SRv6 SID information configured manually or via some protocol.

Am I correct?

Yes you are correct.

Thanks.
  Darren


Bob