Dear Maoke,
Thank you for the review and comments.
Please see inline.
Cheers,
Med
De : Maoke [mailto:fib...@gmail.com]
Envoyé : vendredi 30 novembre 2012 03:31
À : Suresh Krishnan
Cc : BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite;
Right. That's why I prefer the solution space provided by Med before, which
will be much clearer and easy to understand:
* Full stateful approach
* Binding approach
* Full stateless approach
Best wishes
Qiong
On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh leaf.y@huawei.com wrote:
Mark - I
dear Med,
thanks for the response. please see inline.
2012/11/30 mohamed.boucad...@orange.com
**
Dear Maoke,
Thank you for the review and comments.
Please see inline.
Cheers,
Med
--
*De :* Maoke [mailto:fib...@gmail.com]
*Envoyé :* vendredi 30 novembre
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
And much as was also said before, this categorization is bogus as all
solutions need configuration state, ie categorizing solutions based on
amount of configuration or some fluffy term like binding approach is
equivalent to categorizing them based on how long is a piece of string
and ultimately
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
À :
This solution space is the outcome of Vancouver meeting. And IMO, the word
'binding' not only means there are state to maintain, but also indicates that
IPv4 and IPv6 addresses are just bound together, with no algorithmic
relationship.
Thanks,
Qi Sun
On 2012-11-30, at 下午6:51, Wojciech Dec
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:
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
On 30 November 2012 13:37, Qi Sun sunqi.csnet@gmail.com wrote:
This solution space is the outcome of Vancouver meeting. And IMO, the word
'binding' not only means there are state to maintain, but also indicates
that IPv4 and IPv6 addresses are just bound together, with no algorithmic
All,
Right. That's why I prefer the solution space provided by Med before, which
will be much clearer and easy to understand:
* Full stateful approach
* Binding approach
* Full stateless approach
but why would a CPE have to know what amount of state a tunnel concentrator
keeps?
cheers,
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
20 matches
Mail list logo
