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

[Robert Raszuk <[e-mail]>]

Tom,

Imagine the case where packets are subject to go via service chains. I can
steer the packet to the router which has service nodes connected to it but
original src address may be used to decide which service given packet is
subject to take.

Sure I can impose an SR function and map it up front such that the router
above would never need to inspect src address, but why to construct such
architecture which only allows limited set of network programming as
opposed to offer the choice on how to setup things by network operators ?

Thx,
R.

On Thu, Nov 30, 2017 at 10:19 PM, Tom Herbert <[e-mail]> wrote:

> On Thu, Nov 30, 2017 at 11:34 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 ?
> >
> Robert,
>
> I don't understand your point. Isn't the underlying idea here to use
> SR to source route a packet through a domain? I don't see why an outer
> source address of a tunnel is relevant for that. Also, I'd point out
> that encapsulation is hardly a new concept. It is well deployed in
> various forms and many network services have already adapted to its
> use.
>
> > So while perhaps some may consider it "cleaner" I think both variants
> have
> > their own use cases and should be supported.
> >
> It's not just about being cleaner, there are questions about
> correctness that need to be addressed.
>
> Tom
>