Hi Ole, Answers inline.
Cheers, Ian -----Original Message----- From: Ole Trøan [mailto:[email protected]] Sent: Montag, 3. Dezember 2012 10:06 To: Farrer, Ian Cc: [email protected]; [email protected] Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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? Ian: But a MAP CPE does have to care about what is on the tunnel head end as it could be another mesh client, or it could be the BR. It uses a different mapping rule type for each, so it is aware of the capabilities of 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. Ian: Is the problem with the what's being described (i.e. the content and functional differentiations) or the naming and terminology used to describe it? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
