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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires