Re: Comments on draft-bagnulo-multi6dt-hba-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

[catching up]

Erik Nordmark wrote:
> Iljitsch van Beijnum wrote:
>
> > I think it's possible to solve this. We've been talking about a bit 
> > that indicates (among other things) that rewriting is allowed. For a 
> > long time, I've been saying that we could use the prefix in the source 
> > address for this. So magic prefix = rewrite, regular prefix = don't 
> > rewrite. We can reserve some bits in the magic prefix that indicate 
> > the type of rewriting that's allowed. For instance, if the prefix is 
> > <iana:32><x:16><subnet:16><iid:64> then we can encode permission to 
> > rewrite to one or more of 16 different prefixes. There is the slight 
> > problem of having all systems involved know which prefix corresponds 
> > to which bit of course, but this should be doable.
>
>
> Such an approach would require there to be a source locator rewriting 
> router in the path, right?
> If the above funny prefix isn't rewritten in the path the peer will not 
> be able to respond AFAIK.
>
> Since we want to allow incremental deployment of any multi6 technology, 
> such an approach would require that the host can find out
>  1) whether there is a source locator rewriter out there
>  2) whether the source locator rewriter is in the path to reach a
>     particular destination (for instance, the path to a destinations
>     within the site may or may not go through a rewriter)
>
> If the host needs to probe the network per destination locator to answer 
> #2, we might as well have the answer tell the host which is the 
> preferred source locator to use so that there is no actual rewriting 
> along the path. (Yes, there are some subtle differences should the path 
> change.)
>
> The above complexity combined with Geoff's observations that in real 
> networks today it is hard to define which is the "site border router" 
> which would do the rewriting, makes me personally think that locator 
> rewriting along the path might not be worth to complexity even in the 
> future.

For me, encoding semantics in the address in any way is an architectural
red alert. It always comes back to bite. With multipath routing and
virtualized IP addressing common, I just don't see how to ensure
consistent behaviour (i.e. I don't see how to make it one atom better
than NAT).

   Brian