RE: END SID Without SRH

[Ron Bonica <[e-mail]>]

Hello Wang,

Before we start, it is not entirely clear that the unnamed SID described in draft-ietf-6man-segment-routing-header is the same as any of the SIDs described in the network programming draft. 

But even if the unnamed SID were the same as the END SID, we are not discussing the relative position of the END SID in the SRH. We are discussing whether a document whose title is " IPv6 Segment Routing Header (SRH)" should describe behavior changes that occur when the SRH is not present.

                                                                                           Ron




Juniper Internal

-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[e-mail]> 
Sent: Wednesday, June 12, 2019 1:25 AM
To: Ron Bonica <[e-mail]>; Tom Herbert <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: RE: END SID Without SRH

Hi:

But, I think the SRv6 SID function in draft SRH is same as that ENDPOINT defined within 4.1 section of draft "SRv6 networking programming", where the following sentences are from:
A local SID could be bound to a function which authorizes the
   decapsulation of an outer header (e.g.  IPinIP) or the punting of the
   packet to TCP, UDP or any other protocol.  This however needs to be
   explicitly defined in the function bound to the local SID.  By
   default, a local SID bound to the well-known function "End"neither
   allows the decapsulation of an outer header nor the cleanup of an
   SRH.  As a consequence, an End SID cannot be the last SID of an SRH
   and cannot be the DA of a packet without SRH.

According to above, Should the SR source node NOT put END SID as last SID in SRH segment list by default? If we want to implement the function decapsulation of outer IPv6 header, such as IPinIP scenario, DO we need define a new SID for that? Or the SRv6 source node should put normal ipv6@ pointing to tunnel termination router as last member in Segment list? In other words, Can normal IPv6 address (not from SID prefix block) be included as last member in Segment list?
--------------------------------------
Thank you !


WANG Weibin


-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Ron Bonica
Sent: 2019年6月12日 7:52
To: Tom Herbert <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: RE: END SID Without SRH

Tom,

Close, but not exactly.

I am surprised that a document whose title is " IPv6 Segment Routing Header (SRH)" describes behavior changes that occur when the SRH is not present.

Personally, I think that this is an indication that the draft does more than define the SRH, but I am willing to accept that I am in the minority on this point.

                                                    Ron



Juniper Internal

-----Original Message-----
From: Tom Herbert <[e-mail]> 
Sent: Tuesday, June 11, 2019 3:19 PM
To: Ron Bonica <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: Re: END SID Without SRH

On Fri, Jun 7, 2019 at 7:26 AM Ron Bonica <rbonica=[e-mail]> wrote:
>
> Darren,
>
>
>
> This isn’t a blocker. Just a surprising behavior that never struck me before.
>
>
>
> Assume that an SRv6 router receives a packet whose destination address is an END SID. The packet does not contain any extension headers at all.
>
>
>
> If the next header after the IPv6 header is IPv4 or IPv6, the router removes the outer header and forwards the payload.
>
>
>
> If the next header after the IPv6 header is TCP, the router discards the packet and sends an ICMP Parameter Problem message back to the source.

Ron,

Extrapolating as to why you think this is surprising behavior (please correct me if this is wrong), but as I read it, this would be true for any transport protocol and allows the possibility of hosts that don't even know what segment routing is to receive the parameter error. For instance, if someone were just innocently pinging the router's address, which happens also to be an END SID, the source of the ping would get the parameter error. In that case, the host might not even know what segment routing is and much less have any clue why its getting a parameter problem pointing to the nexthdr field for an otherwise simple IPv6 packet.

Tom

>
>
>
> Am I reading the spec correctly?
>
>
>
>                                             Ron
>
>
>
>
> Juniper Internal
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=9ASj40JkUp_IP94KYpx
> 2kuAwzMvXveo2lvlaY_frSJU&s=jsc2nf5cRibLHNNp9CDwxadf-QtMl8B1X0Vg-5uBBcc
> &e=
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=TZXeGAVoqh8RRFRx9DbZpp22APN6Ol6LFFZRa-yxBQ4&s=A2EzKSyTFVoYaLMcWD57X2VoDlpHGKCJNDrnqe5QMUY&e= 
--------------------------------------------------------------------