de Tina TSOU
Envoyé : mercredi 5 décembre 2012 19:34
À : ian.far...@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
Qiong,
from MAP's perspective it doesn't matter if it is a /64 on the WAN or a /56
delegated prefix.
any prefix can have EA bits.
[Qiong] In theory, right. But I think it still have several issues here:
1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying
hey, I'm
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
CPE:
draft-bfmk-softwire-unified-cpe
Med, et al,
Med: The rationale we adopted in this draft is as follows:
* there are three major flavors: full stateful, full
stateless, and binding mode
* all these modes can support assigning a full or a shared
IPv4 address
now you got me thinking
Trøan [mailto:otr...@employees.org]
Envoyé : vendredi 30 novembre 2012 20:36
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Simon Perreault; softwires@ietf.org
Objet : Re: [Softwires] Unified Softwire CPE:
draft-bfmk-softwire-unified-cpe
Med, et al,
Med: The rationale we adopted in this draft is as follows
Ole,
On 2012-12-3, at 下午5:06, Ole Trøan wrote:
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
...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Ole Trøan
Sent: Samstag, 1. Dezember 2012 09:48
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Simon,
Med: The rationale we adopted in this draft is as follows
Qiong,
[Qiong] and a sub-mode for source IPv6 address determiniation, how to
determine the encapsulated IPv6 source address.
1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface
Identifier (MAP)
2) WAN IPv6 address (DS-Lite, LW46, Public 4over6)
Right ?
MAP could also
Simon,
Med: The rationale we adopted in this draft is as follows:
* there are three major flavors: full stateful, full stateless, and binding
mode
* all these modes can support assigning a full or a shared IPv4 address
now you got me thinking, are these really the right modes from a CPE
Ole,
On Sat, Dec 1, 2012 at 4:44 PM, Ole Trøan otr...@employees.org wrote:
Qiong,
[Qiong] and a sub-mode for source IPv6 address determiniation, how to
determine the encapsulated IPv6 source address.
1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface
Identifier (MAP)
Qiong,
[...]
MAP could also create its tunnel endpoint address from the WAN prefix (not
address).
so you'd have, for CPE tunnel end point address:
Thanks for clarification. But if MAP uses the WAN prefix as its tunnel
endpoint address, does BR need to keep all the records for CPEs
-ietf-softwire-...@tools.ietf.org;
draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org;
draft-ietf-softwire-map-d...@tools.ietf.org
Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
thanks Med for the initialization of the work!
i noticed that:
1
-public-4ov...@tools.ietf.org,
draft-cui-softwire-b4-translated-ds-lite
draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo
Penno (repenno) repe...@cisco.com, softwires@ietf.org
softwires@ietf.org
Sent: 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE: draft-bfmk
Hi,
While thanking the authors for their attempt, I need to provide some high
level feedback first on key issues:
The rationale section 1.1 states co-existance as the goal - this appears
to imply some entirely different solutions for which co-existance is
needed, and here are two points:
A) I can
Hi Woj,
Many thanks for the comments.
Please see inline.
Cheers,
Med
-Message d'origine-
De : Wojciech Dec (wdec) [mailto:w...@cisco.com]
Envoyé : vendredi 30 novembre 2012 11:42
À : BOUCADAIR Mohamed OLNC/OLN;
draft-ietf-softwire-...@tools.ietf.org;
Hi Med.,
On 30/11/2012 12:10, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Hi Woj,
Many thanks for the comments.
Please see inline.
Cheers,
Med
-Message d'origine-
De : Wojciech Dec (wdec) [mailto:w...@cisco.com]
Envoyé : vendredi 30 novembre 2012 11:42
À :
Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit :
As agreed in Atlanta, we prepared an I-D describing a proposed approach for the
unified CPE.
We hope this version is a good starting point to have fruitful discussion.
Your comments, suggestions and contributions are more than
Hi Simon,
Please see inline.
Cheers,
Med
-Message d'origine-
De : softwires-boun...@ietf.org
[mailto:softwires-boun...@ietf.org] De la part de Simon Perreault
Envoyé : vendredi 30 novembre 2012 13:59
À : softwires@ietf.org
Objet : Re: [Softwires] Unified Softwire CPE:
draft-bfmk
Re-,
Please see inline/
Cheers,
Med
-Message d'origine-
De : Wojciech Dec (wdec) [mailto:w...@cisco.com]
Envoyé : vendredi 30 novembre 2012 13:21
À : BOUCADAIR Mohamed OLNC/OLN;
draft-ietf-softwire-...@tools.ietf.org;
draft-ietf-softwire-map-d...@tools.ietf.org;
Hi Simon,
One answer in line (I think Med covered off the rest)
Cheers,
Ian
On 30/11/2012 13:59, Simon Perreault simon.perrea...@viagenie.ca wrote:
Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit :
As agreed in Atlanta, we prepared an I-D describing a proposed approach
for the
Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit :
- Didn't we also consider public 4o6 as one mode? Any reason
why it was
left out?
- Is public 4o6 the minor change to lw4o6 that section
4.1 hints at?
Med: The rationale we adopted in this draft is as follows:
* there are three
Le 2012-11-30 14:22, ian.far...@telekom.de a écrit :
Ian: I broadly agree with what you've said, but one use case that did
cross my mind is if you only needed to provision mesh routes to a client
with no need for a concentrator/default route. A closed machine-to-machine
type service could be an
On 30/11/2012 14:17, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Re-,
Please see inline/
Cheers,
Med
-Message d'origine-
De : Wojciech Dec (wdec) [mailto:w...@cisco.com]
Envoyé : vendredi 30 novembre 2012 13:21
À : BOUCADAIR Mohamed OLNC/OLN;
Re-,
-Message d'origine-
De : Simon Perreault [mailto:simon.perrea...@viagenie.ca]
Envoyé : vendredi 30 novembre 2012 14:24
À : BOUCADAIR Mohamed OLNC/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] Unified Softwire CPE:
draft-bfmk-softwire-unified-cpe
Le 2012-11-30 14:09
Le 2012-11-30 15:18, mohamed.boucad...@orange.com a écrit :
MAP-E:
- Lw4o6 set of provisioning information
- Forwarding mapping rules
Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional
parameters are needed for MAP. This is why the table included two entries for
Med, et al,
Med: The rationale we adopted in this draft is as follows:
* there are three major flavors: full stateful, full stateless, and binding
mode
* all these modes can support assigning a full or a shared IPv4 address
now you got me thinking, are these really the right modes from a
Dear all,
As agreed in Atlanta, we prepared an I-D describing a proposed approach for the
unified CPE.
We hope this version is a good starting point to have fruitful discussion.
Your comments, suggestions and contributions are more than welcome.
Cheers,
Med
-Message d'origine-
De
, Reinaldo Penno
(repenno) repe...@cisco.com, softwires@ietf.org softwires@ietf.org
Sent: 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear all,
As agreed in Atlanta, we prepared an I-D describing a proposed approach
for the unified CPE.
We
28 matches
Mail list logo
