[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] A Late Response to Questions on Six/One Router
On Aug 7, 2008, Lixia Zhang wrote:
better later than never: I have 3 questions on this writeup; Robin
already brought up the first one in his long review comment (dated
July 30, 2008 10:25:39 AM PDT), but I have not seen the rest been
asked (or maybe I read Robin's long msg too quickly and missed).
1/ fig-4 in the above pdf file shows an example of backward
compatibility packet exchanges between an upgraded and a legacy edge
network, however note that both are single-homed in this example. If
the legacy net L is multihomed, everything still works, as (I assume)
L still has its prefix injected into the global routing table. However
if the upgraded network U is multihomed, the communication with L can
only use the address of one of U's providers, right? (this would be a
dis-incentive for U to do upgrading...)
Hi Lixia,
you are right in that a multi-homed upgraded edge network is reachable
from a given legacy edge networks only via a single provider. That
provider may differ depending on the legacy edge network, so all
providers can still be used. Also, the provider may change over time,
e.g., for fail-over. But such a fail-over requires that affected
packet exchanges (with legacy edge networks) are re-established.
I replace the original question 2/ with the following:
2/ how does six/one handle transient failures? Take Figure-3 for
example: if the link between provider-1 and six/one router fails,
since the other end sends to the specific address block of this
six/one router (as explained in fig-2), what causes the other end to
change the translation to the address belonging to the right-side
six/one router? Or there is some "local repair" done between
provider-1 and provider-2?
The paper describes a secure method with which edge networks can
communicate reachability information to other edge networks. This is
the Mapping Preferences message plus its accompanying validation
protocol (section 2.5.2 in the paper). This method can be used for
recovery from an edge network attachment failure as long as there
exists an entity that (a) knows about the attachment failure, and (b)
knows about remote Six/One routers sending packets to the failed
attachment.
For failure recovery when such an entity does not exist, additional
mechanisms are necessary. What I was thinking of (but what the paper
does not describe) is mechanisms executed by the sending Six/One
router: probing of destination Six/One routers, monitoring of ICMP
Destination Unreachable messages, or monitoring of locator prefix
withdrawals in BGP. (These mechanisms are not novel, of course; they
have been described elsewhere.)
3/ the paper shows that six/one deployment is at edge sites--how does
this help align cost with incentives?
It's not a must to deploy Six/One Router in edge networks. You can
deploy it on the provider side as well. I tried to write the paper in
a way that is independent of which side on a border link Six/One
routers are placed.
As a matter of fact, I personally prefer the option where the
providers deploy Six/One Router because they are the ones who benefit
from the improved routing scalability. But again, it doesn't matter.
Different deployment schemes could be used for different edge
networks.
- Christian
--
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