Ole,
On 2012-12-3, at 下午5:06, Ole Trøan wrote:
> Ian,
>
>> Whichever state is selected, NAT is certainly fundamental to how the state
>> will operate and so we tried to weave it into the functional description.
>> I'm not sure that provisioned NAT info enough to be able to use to
>> unambiguously define with operating 'mode' (for want of a better word) to
>> use.
>>
>> One of the reasons for the use of state in the draft is try and define the
>> operating modes with as little overlap as possible (it's not 100%, but
>> there's only 1 exception at the moment for binding mode and MAP1:1). From
>> this, then it is easier to align the specific solution names to the state
>> characteristics.
>
> I don't think you should try to define modes such that the map (no pun
> intended) into the specific solution names.
> shouldn't the purpose of a "unified CPE", be for the CPE not to have to care
> about the different "deployment modes" on the head end?
[Qi] I think the modes are "functional modes" rather than "deployment modes".
CPE has different functional characteristics under different modes and it has
to know what behavior it should perform under different mode.
>
>> But, with what you've suggested, there is more overlap, i.e. both 2&4 have
>> NAT functions that are supported by two different mechanisms.
>>
>> However, what you've said does raise the following point:
>>
>> The way that state is described in the draft at the moment is actually taken
>> from a concentrator perspective. This could be taken to be almost the
>> inverse of the amount of state that is required from the CPEs perspective
>> (i.e. if all of the state is in the providers network (DS-Lite), then the
>> CPE doesn't need it. If the providers network has less state
>> ('per-customer', 'stateless'), then the CPE needs to have more - i.e.
>> dynamic state table for NAT, configuration for local IPv4/port set, MAPing
>> rules etc.
>>
>> Would describing the different states more from the CPE's perspective make
>> this clearer?
>
> that would certainly help. although I don't think "state" is the defining
> characteristic.
[Qi] IMHO, using state as the defining characteristic, the CPE can determine
which module to mount and which functionality to perform.
Best Regards,
Qi
>
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
