Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

[Robert Raszuk <[e-mail]>]

Hi Fernando,

The WG document talks about two cases ...

* EH insertion at the host (src of packet)

* IPv6 new encapsulation + EH insertion on the ingress to SR domain
followed by decapsulation at the egress of SR domain.

I hope we can agree on that.

However is it wise to expect any time within SR domain for a packet (v6
encapsulated on ingress) to get steered differently (say coming out of
service chain) to decapsulate and encapsulate again ? Seems to me like
quite local box decision anyway.

Hence my comment about implicit insertion.

In any case if we see this entire thread the only technical concern with EH
insertion was MTU. And how that issue is solved when you do additional IPv6
header encap ?

Or maybe encap is allowed simply as it can not be forbidden :))

Cheers,
Robert.


On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont <[e-mail]> wrote:

> On 03/31/2017 04:11 PM, Robert Raszuk wrote:
> > I do not understand how 2460bis makes it "easier" if proposed change to
> > the text directly tries to prohibit what is described in a document
> > already long time back accepted as a 6man working group draft.
>
> This is incorrect. For instance, the condition to accepting such I-D as
> a wg items was indeed that EH insertion was removed, and that
> encapsulation be used instead.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>