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?
> 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.
cheers,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
