RE: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

[<philip.eardley@bt.com>]

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 rrg-request@psg.com 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