Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Rémi Després <[e-mail]>]

Le 10 oct. 2011 à 17:33, Qiong a écrit :

> Hi, Qiong,
> 
> Please see inline.
>> On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després <[e-mail]> wrote:
>> 
>> The 4rd function examines ALL packets that reach the CE.
>> It processes all those that have V in their destination addresses, and only those.
>> 
>> Qiong: I think it might be better achieved via routing lookup for prefix+V bits (e.g. /80 ), rather than extracting V bits before traditional routing.
>>  
>> 
>> The reason why 4rd packets reach the CE is NOT that their destinations are the IPv6 address that the CE has on its link to the ISP. 
>> It is that their destinations start with the CE delegated prefix. The routing information base of the ISP edge router is such that, for such destinations, the next hop is the CE. 
>> 
>> 
>>> Then the variable "max" PSID derived from dst. ports may get a problem.
> 
>>  Qiong: I think the "max" PSID design might have a problem in virtual interface implementation. When implementing an virtual encapsulation/translation interface, the packets can reach the virtual interface from a downstream physical interface via traditional routing.
> 
>> For example, identifying a specific address or /80 prefix to the destinated virtual interface. However, when the "max" PSID is not stable and the length of "Rule IPv6 prefix+ Max PSID" exceeds 64 bit long, how to construct this kind of internal routing table ? I think it would be too many routing entries here.
> 
> Routing being only concerned with /64s, and information in IIDs being used only by 4rd functions themselves, or for O&M, I don't see the problem.
> 
> Qiong: My concern is specific for virtual interface implementation. If you implement a virtual interface(as most existing encapsulation approaches have adopted in CPE ), you still need to do routing within CE (from physical interface to virtual interface). In traditional encapsulation implementation, a specific routing entry can be assigned to help forward the traffic with a tunnel endpoint address. And all the following decapsulation things can be done in this virtual interface. I think this kind of implementation can be applied to translation as well, to make use of traditional routing and implementation translation functionality only on the virtual interface. And since the first 64 bits will be same for both native traffic and translated traffic, the lower bits would be needed for internal routing. That's why I think unstable "max" PSID would make it difficult to construct internal routing table (not routing procedure from ISP to CE). But anyway, it is only restricted to this kind of implementation (determine the translated traffic by routing rather than bit extracting). 
> 
> Hope it is clear now.

This is an implementation issue about which others may be better placed than me to give a quick answer.

I only know it is feasible by putting some simple code at some appropriate place(s).
Sorry I can't tell more without some consultancy based on details of your implementation.

Regards,
RD



> 
> Thanks 
> 
> Qiong
>