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

Hi Tina,

Many thanks for the comments. Some clarifications below:

* DS-Lite is included in the scope for the reasons detailed in the draft (see Section 1.1):

   (2)  Simplify solution migration paths: Define a unified CPE behavior
        which allows for smooth migration between the different modes
and

   (4)  Re-usability: Maximize the re-use of existing functional blocks
        including Tunnel Endpoint, port restricted NAPT44, Forwarding
        behavior, etc.

* Public 4over6 is already included in the draft:

   (2)  Binding approach (e.g., Lightweight 4over6 (Lw4o6)
        [I-D.cui-softwire-b4-translated-ds-lite<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.cui-softwire-b4-translated-ds-lite>],
        [I-D.ietf-softwire-public-4over6<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.ietf-softwire-public-4over6>] or MAP 1:1
        [I-D.ietf-softwire-map<http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#ref-I-D.ietf-softwire-map>] ): Requires a single per-subscriber
        state (or a few) to be maintained in the Service Provider's
        network.

* I agree with you the title should be updated to reflect the scope of the draft. The proposed scope is IPv4 service continuity over IPv6 mechanisms.

Cheers,
Med

________________________________
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la part de Tina TSOU
Envoyé : mercredi 5 décembre 2012 19:34
À : ian.farrer@telekom.de
Cc : softwires@ietf.org
Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written very well to reach consensus.
Two small comments are below.

1.      I'm not sure whether it is appropriate to put DS-Lite case into the document, since in DS-Lite case the CPE is only the tunnel end point without NAT, which is basically different with lw4over6/MAP. But if the objective of this document is to define an unified CPE for all the 4over6 mechanisms, other mechanisms like public 4over6 should also be included in the document. My understanding may be wrong.

2.      The title says "unified softwire CPE", but in softwire, there are many other transition technologies, e.g., 6rd. To be specific, maybe 4over6 CPE is more appropriate.

Thank you,
Tina

On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>" <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>> wrote:

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Trøan [mailto:otroan@employees.org]
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: simon.perreault@viagenie.ca<mailto:simon.perreault@viagenie.ca>; softwires@ietf.org<mailto:softwires@ietf.org>
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
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires