Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

[Mark Smith <[e-mail]>]

On 1 Dec. 2017 6:35 am, "Robert Raszuk" <[e-mail]> wrote:

Hi Fernando,

So in the case of encapsulation you normally put the node performing the
encap as source address. That may impact how you handle this packet via
number of services or even by src-dst routing correct ?

So while perhaps some may consider it "cleaner" I think both variants have
their own use cases and should be supported.



The trouble is they're not explained at all.

All there is is an assertion that "operators want this", which is the
logical fallacy of an appeal to authority.

 I'm an operator, and I don't want it. I think it'll be harder to
troubleshoot than NAT over the Internet and NAT is bad enough.


Thx,
R.

On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont <[e-mail]>
wrote:

> On 11/30/2017 08:45 PM, Ole Troan wrote:
> >>
> >> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
> >> -- this is the standard, straightforward and most clean approach.
> >
> > The best example I've heard is when you don't have a natural tunnel
> endpoint to encapsulate to.
>
> What's a natural tunnel-endpoint here? Aren't you expecting such
> endpoint to exist, to remove the inserted EH, after all? (and listing it
> in the RH)
>
> I seem to remember some folks arguing that the rationale for EH
> insertion is that performance go to hell if they do proper encapsulation...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------