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

[Robert Raszuk <[e-mail]>]

As I think it has been very clearly documented in number of drafts dst
address of the packet in the SRv6 domain is the address of the next segment
routing node which swaps it to next segment etc ... So dst address of the
imposed encapsulation will never be the end node which is seen as hope to
put the packet to the "original shape".

I was specifically referring to src address not dst address of the
encapsulated packet.

Thx,
R.

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

> On 12/01/2017 03:34 AM, Robert Raszuk 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.
>
> Inserting an EH as suggested is not IPv6, and can break a number of
> things. The very least I would expect for a proposal to do so is why
> that cannot be done with proper encapsulation. --> i.e., add an outter
> IPv6 header with a RH header, and do your thing, as oppose to insert the
> RH in there.
>
> Of the top of my head, if part of the claim is the controlled
> environment, and that this controlled environment will take care of the
> "butchered" packets to be brought back into their original shape, I'd
> expect that having a dst addr of a system that can actually do that (as
> in the normal encapsulation case) is kind of a requirement...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>