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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 > [email protected] > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
