Christian, Thanks for your answers, a couple of follow-ups/ > But if a host contacts a peer by transit address, even though both > hosts are in upgraded edge networks and would more appropriately > use edge addresses, then this transit address will not be translated > at the initiator's side, and must hence be translated throughout the > entire packet at the recipient's side. This may happen when the > initiating host is referred to the transit address by another host.
> purpose. Packet payloads must then be translated if and only if the > remote edge network is legacy, and extension headers must be added in > that and only that case. as nearly everything's legacy to start with, I'd like to understand the performance implications better? Is this something that could be deployed at current NATs /firewalls /DPI boxes? (I tend to think of Six/one router as a super NAT) - any idea what the performance implications on them would be? (eg if have to install 2* NAT/firewalls, then the benefit to that party has to be >2* ?) > > > > 4. in your analysis doc [ref 1 below] I wasn't completely convinced by > > the scalability section (3.1). I can believe that the transit (ie > > global) routing system is more stable. But haven't you shifted this > > problem to the mapping system - it now has to cope with changes in > > edge/transit mappings? (does this necessarily make things easier?) > > Six/One Router does not impose more frequent updates on the mapping > resolution system than other address indirection proposals such as LISP, > APT, Ivip. In all cases, the mapping resolution system only provides a > set of feasible address mappings. The selection of a particular > mapping, initially and possibly subsequently due to traffic engineering, > has to be done end-to-end. Three possibilities: > > The mapping for a packet's destination address is chosen by... > > (a) the sending side > > (b) the sending side initially, but the receiving side controls all > subsequent re-selections > > (c) the receiving side, both initially and subsequently > > In cases (a) and (b) the sending side should probe the available > destination address mappings that it has gotten via mapping resolution. > It should do so initially in case (b), and also periodically thereafter > in case (b). In cases (b) and (c), the receiving side must signal > preferred reachability information to the sending side. > > Which approach to follow is something that I think should be more > carefully discussed on this mailing list. This is a general topic that > is not specific to Six/One Router. It may be a delicate topic because > it is about the distribution of routing power. > yes, I agree that some discussion would be excellent - I think the analysis can be done at a fairly general level (ie without getting into how specific protocol proposal x works). Certainly agree the distribution of routing /policy power (and the capability) is important - at least to recognise that changes to it are a migration barrier. phil -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
