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

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


El 04/04/2006, a las 19:02, Scott Leibrand escribió:
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.
ok, i may agree with this, but you still need to avoid deferred context establishment in this case. I mean, i agree with the point that if the shim6 context estalishment exchenge does not needs rewriting, then it is likely that the data packets won't need it neither (depending on how dynamic the policy is anyway) So i guess it may be reasonable to send the I1,R1,I2,R2 and see if there is a rewriting router on path. If it is, then the host needs to include the payload header in all data packets to allow rewriting 
If not, it may skip that and the peer can tear down the context
but still we need to avoid deferred context estbalishment in this case, in order to figure out early in the communication if we need rewriting or not
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.)
yes, but depending how dynamic the policy is and how much control the admin of the site wants, this may be acceptable or not 




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.
well, shim context establishment requires acceptance from both peers, so both parties must agree. However, once that the context is established, it seems rasonable to expect that both parties will keep the context if this is needed (at least by one of the parties) 

not sure what is the behaviour that you would expect

regards, marcelo


  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