[rrg] Summary of architectural solution space

[Teco Boot]

Agreed with Brian.

Moreover, I think the strategy is orthogonal to the others
and it provides additional functionality, like multipath transport.
I would call this strategy "map and forward" as encap is not needed; 
assuming edge routers are upgraded for Source Address to 
Border Router mapping.

Teco.


> -----Oorspronkelijk bericht-----
> Van: rrg-bounces at irtf.org [mailto:rrg-bounces at irtf.org] Namens Brian E
> Carpenter
> Verzonden: maandag 24 november 2008 2:26
> Aan: William Herrin
> CC: RRG
> Onderwerp: Re: [rrg] Summary of architectural solution space
> 
> 
> > The third draft is now available at
> > http://bill.herrin.us/network/rrgarchitectures.html .
> 
> Looking at Strategy B, I have two comments.
> 
> One is that
> "Assign multiple LOCs to each host such that in the network
> topography hosts appear as stubs in multiple locations..."
> appears to me to be quite clearly the *standard* model for
> IPv6, a.k.a. Plan A, so I would suggest inverting the names
> of Strategy A and Strategy B.
> 
> The second comment is that
> "LOCs dynamically mapped to each host are pushed towards a
> distributed registry as they change."
> is only one variant. The other variant is that they aren't
> considered to be dynamically mapped but rather administratively
> mapped (in solutionism, that's called DNS). That doesn't change
> most of what you write, but it does affect the two major
> criticisms:
> 
> 1. There's no problem with transport protocols as long as the
> IP stack conceals the address dynamics from the upper layer.
> It would be solutionism to point out that there's already running
> code for that.
> 
> 2. If the LOCs are assigned administratively, the firewalls
> can deal with multiple LOCs.
> 
>    Brian
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> https://www.irtf.org/mailman/listinfo/rrg