Re: SRH insertion vs encapsulation (Re: Next steps on Extension Header Insertion)

[Mark Smith <[e-mail]>]

On 5 Nov. 2016 05:52, "Brian E Carpenter" <[e-mail]>
wrote:
>
> On 05/11/2016 06:41, Tom Herbert wrote:
> > On Fri, Nov 4, 2016 at 10:01 AM, Stefano Previdi (sprevidi)
> > <[e-mail]> wrote:
> >>
> >>> On Nov 4, 2016, at 5:03 PM, 神明達哉 <[e-mail]> wrote:
> >>>
> >>> At Fri, 4 Nov 2016 11:16:34 +0000,
> >>> Tim Chown <[e-mail]> wrote:
> >>>
> >>>>> Huh? The segment routing header is far from imaginary.
> >>>>
> >>>> But what do you deduce is really being specified in the SRH drafts?
> >>>>
> >>>> In draft-ietf-6man-segment-routing-header-02 it says in section 2.2:
> >>>> [...]
> >>>> which implies the SRH uses encapsulation, and doesn’t insert an EH
> >>>> in the existing header chain.
> >>>
> >>> My understanding is that actual implementations don't follow what's
> >>> written in the draft and do insert an SRH:
> >>> https://www.ietf.org/mail-archive/web/ipv6/current/msg24236.html
> >>
> >>
> >> In fact, there are implementations that do what’s written in the draft
and also do header insertion for some use cases. The use cases applies to
controlled environments where, typically, a EH is inserted at ingress and
removed at egress. This is the reality of v6 segment routing
implementations used over v6 infrastructure of some operators.
> >>
> > FWIW, the SR patches currently under review for Linux also do this. I
> > did point out the discussions about EH insertion happening on this
> > list, but I doubt that we would disallow patches based on that. My
> > recommendation was to put a big disclaimer in the documentation and
> > allow user to configure it with the assumption they know what they're
> > doing.
>
> Which IMNSHO is exactly why we should *not* leave this ambiguous in
2460bis.
> (I don't care what people do in the privacy of their own domains.

I also have that view, except that based on experience, if those domains
are connected to the Internet, they leak due to improper configuration or
bugs in devices (EH insertion is likely to be more complicated code than
encapsulation, so there is likely to be more possibility for bugs.)

That imposes costs and consequences on parties that had and have no say in
the local domain decision. If they can't impose some sort of penalty or
cost on the originator, the receiver has no choice but to wear the cost.

In the least it should be possible to identify who is creating the problem.
EH insertion does not contain any attribution, unless the inserted EH
recorded an insertion device source IP address or ASN. Without that, the
inserted EH could have been inserted by the AS where the packet originated,
or at any of the other ASes the packet traversed before it arrived and
caused problems. It is impossible to tell.

I suspect there would be objection to saying that inserted EHs MUST record
insertion IP address or ASN, due to the overhead of carrying that
information. I also suspect per packet overhead is the reason EH inserters
want to avoid encapsulation. I think that overhead price is worth paying
compared to the trouble silent EH insertion anywhere in the packet path
could cause.

So in your own domain is fine as long as your own domain is not and never
connected to others' domains and the Internet.

Regards,
Mark.




> I do care
> what is needed for interoperability across the Internet.)
>
>     Brian
>
> >
> > Tom
> >
> >> s.
> >>
> >>
> >>
> >>> (And my understanding is that the desire of some people to make the
> >>> "actual" behavior explicitly standard-compliant is one major
> >>> background motivation of why we are having this thread.)
> >>
> >>>
> >>> --
> >>> JINMEI, Tatuya
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> [e-mail]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------