Re: [shim6] Exit selection [New Version Notification - draft-mrw-nat66-08.txt]

[Brian E Carpenter <[e-mail]>]

On 2011-03-14 10:14, Geoff Huston wrote:
> On 13/03/2011, at 3:32 AM, Rémi Després wrote:
> 
>> Le 11 mars 2011 à 20:13, Scott W Brim a écrit :
>> 
>>> Shim6 itself cannot select an exit.  In all but trivial
>>> cases the network has the intelligence and must be
>>> involved (e.g. the exit points).  Given that one has to
>>> involve the network, then an exit selection mechanism is
>>> not just for Shim6 but for anything that can take
>>> advantage of multiple src+dst pairs, and it should not be
>>> Shim6-specific. Therefore whatever needs doing, I
>>> recommend that it not be done in Shim6 but somewhere more
>>> general -- IntArea WG looks like a good place.
>> +1
>> 
> 
> wg co-chair hat OFF
> 
> I appreciate that in the context of the IETF saying "we
> should not do this" is invariably like standing in front of a
> bulldozer, and like the bulldozer, it rarely has any effect -
> but nevertheless I want to share with you a personal opinion
> that we should not do this! :-)

If by "we" you mean the shim6 WG, I'm inclined to agree,
beyond documenting that this problem needs to be solved
generically for IPv6. I don't believe shim6 is really a
special case: once you have prefixes from and exits to several
different ISPs, you have a potential problem.

> 
> I have two problems with this issue of "exit selection".
> 
> Firstly, I recall the demise of the site-local scoped address
> in IPv6. The compelling argument for me was one of inability
> of self-awareness of context. i.e. it was never clear where
> the edge of a site actually lay. So let me replay the same
> problem statement here - what is an "exit" and how does a
> packet know when it has gone through it? And how does a
> router "know" its the exit router and not an interior router?
> In the context of nested sites (e.g. workgroup, department,
> faculty) whats _the_ exit?

The host and the departmental router cannot know the answer to
that question, I fear, without erecting some very complicated
machinery.

> 
> Secondly, its not just the problem of scope of a site here.
> Its also trying to clearly understand the nature of the
> problem and place that into juxtaposition with the various
> proposed "solutions." From memory the various exit selection
> solutions proposed in the context of shim6 were all various
> forms of source-address based forwarding, and for me its
> getting the cart well and truly before the horse. Hop-by-hop
> stateless destination-based forwarding is an incredibly
> powerful architectural concept in packet networks, and any
> other forwarding mechanism tends to invoke copious quantities
> of complexity and state, and should only be contemplated as a
> last resort of the desperate rather than the first line
> solution. 

I fully agree. That would be baroque, and despite having started
this conversation, I am not in favour of a host-based or even
departmental-router-based solution.

> So why was exit selection an issue in shim6? Surely
> if routing is working, and shim6 does not assume broken
> routing, if a route to a destination is offered, then its a
> valid route. So why select exits that are not being offered
> by routing as being on the best path? From my memory I
> believe it was because some folk  thought that a) unicast
> reverse route filtering would be prevalent in IPv6 and that
> b) clients could not negotiate filters with their provider.
> But is a) true? and is b) really true? 

Well, it seems from other responses that both are real problems,
but not specific to shim6. draft-v6ops-multihoming-without-nat66
talks about this, and at first sight, a valid approach for
the problems described in that draft would work just fine for
shim6 too. Maybe shim6 people should read that draft carefully.

    Brian

> Frankly I'm pretty
> sceptical that this is the case and it concerns me that this
> is a case of over solving.
> 
> my 2c anyway
> 
> Geoff
> 
> 
> _______________________________________________ shim6 mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/shim6
>