Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

[Scott Leibrand <sleibrand@internap.com>]

On 04/04/06 at 2:16pm +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> > I disagree with this.  If a rewriting-capable host, which may or may
> > not have a rewriting router on the path, started up communication
> > observing these SHOULDs, then the host it's talking to, which may be a
> > very busy non-multihomed (or PI-multihomed) server, would have to keep
> > full shim6 context and would be unable to discard it during
> > communication due to the presence of shim6 extension headers on every
> > packet.  This would be true even if no source-rewriting routers were
> > deployed, and no one gained any benefit from the capability.
> >
> > IMO a better approach would be to continue using deferred context
> > establishment (except in the identifier/locator split case, of
> > course), and initially only put the Sent Locator Pair option packets
> > that already have shim6 headers (shim6 control packets and any packets
> > sent with non-ULID locators).  Then, *if* source locator rewriting is
> > done by a router on *those* packets, you can start putting shim6
> > extension headers on all ULP payload packets.
>
> I guess that what you want is first to discover if there is router
> rewriting in the path and if this is so, then enable this capability for
> the particular shim6 context.

Yes, I agree.  We just have to figure out how to do that.  :)

> The problem that i see with this is that i don't think it is trivial to
> detect if a rewriting router is in the path. In particular, i don't
> think that the context establishment exchange is enough to detect such
> presence, especially because it may well happen that during the context
> establishment exchange, the source address match with what the router
> would have rewritten, and even if there is a rewriting router in the
> path, the source address is unchanged.

That is true.  BUT, if the router doesn't need to rewrite the source
address, is there a need for shim6-tagging every packet?  IOW, if the
hosts are already doing what the router wants them to, it can just sit
back and let them continue.

Now I suppose the router might change its TE preferences in mid-session,
and want to start rewriting locators.  But in that case, I think it could
just do so on shim6 packets, leaving the non-shim6-tagged packets alone as
it would have to do for non-shim6-capable hosts.  That way all new flows
could be rewritten and redirected, without impacting hosts that aren't
shim6-capable, or hosts that don't want to keep all their shim6 state.
(In fact, there's no difference between the two as far as a router is
concerned.)

> I guess it hard to have both aggressive garbage collection and source
> address rewriting and i guess each site will prefer one capability
> over the other. So i guess that the best we could do is to provide
> tools so that each site can benefit from the capability that it
> prefers the most.

I agree.  And in order to do so, we have to ensure that the decisions of
one site (say a multihomed small site) to *support* source address
rewriting doesn't automatically impact all the shim6-capable hosts it
talks to.  Rather, we need to make sure that the only time we require both
sides to keep full shim6 context is when a router in the path has already
performed source locator rewriting.

-Scott