Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

[<[e-mail]>]

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Trøan [mailto:[e-mail]] 
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: [e-mail]; [e-mail]
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