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

[Qiong <[e-mail]>]

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.

Thanks

Qiong