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 [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
