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 : [email protected] [mailto:[email protected]] De la part
de Tina TSOU
Envoyé : mercredi 5 décembre 2012 19:34
À : [email protected]
Cc : [email protected]
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,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>;
[email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
