Eric> In Figure 2.1, you show CE2 connected to PE3 and PE4. Now suppose we also Eric> have CE4 connected to PE3 and PE5. If PE3 fails, one might want use PE4 as Eric> a backup for CE2, while using PE5 as a backup for CE4. Your scheme doesn't Eric> seem to handle this.
Mingui> If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5 Mingui> allocate (1101, vNH2) for CE4. The scheme works well. Are you now suggesting to allocate a vNH address and shared label for every CE? Since there are many more CEs than PEs, that would make the scaling properties of the scheme a lot less favorable. Eric> Also, even in the case of Figure 2.1, it seems entirely possibly that Eric> one might want PE3's primary route to CE2 to be via the directly Eric> attached interface, while wanting PE4's primary route to CE2 to be via Eric> PE3. Does your scheme handle this case? Mingui> Yes, it handles. Please see the right part of eq1: Sxy3+M. If the Mingui> backup tunnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < = Mingui> Sxy4+S. That means eq1 does not hold. I think that equation is based only on the IGP link costs. A service provider might use BGP LOCAL_PREF to give the PE3-->CE2 route a higher degree of preference than the PE4-->CE2 route, in which case PE4's normal route to CE2 could be via PE3, independent of the IGP link costs. Of course, PE4 will switch to the directly attached route when it learns, through IGP, that PE3 is not reachable. But in that case you might not meet the FRR goal.
