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

[Jacni Qin <[e-mail]>]

hi,

On 10/10/2011 11:33 PM, Qiong wrote:
> Hi, Qiong,
>
> Please see inline.
>
>>     On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després
>>     <[e-mail] <mailto:[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.
I doubt whether the two can share the same interface by just switching 
between encapsulation/translation modes, maybe a separated one is needed 
for translation since the implementation is different.


Cheers,
Jacni

> 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.
>
> Thanks
>
> Qiong
>