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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <fgont@xxxxxxxxxxxxxxx> 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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]