Dear Dave, all,
I'm not talking about that, but when I don't want to add any entry to my DNS
due to some reasons (avoid extra configuration task of DNS for instance.)
Cheers,
Med
-Message d'origine-
De : Dave Thaler [mailto:dtha...@microsoft.com]
Envoyé : lundi 16 novembre 2009
Dear all,
Please find below a link to a new submitted draft which aims to avoid involving
several AFTR devices in the path. A procedure is proposed to withdraw an AFTR
from the path.
Comments are more than welcome.
Cheers,
Med
-Message d'origine-
De : i-d-announce-boun...@ietf.org
Dear Alain, all,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Alain Durand [mailto:adur...@juniper.net]
Envoyé : vendredi 7 mai 2010 18:19
À : Behcet Sarikaya
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org
Objet : Re: [Softwires] GI-DS-lite as working group item?
Dear Sri,
Thank you for answers.
Please see inline.
Cheers,
Med
-Message d'origine-
De : Sri Gundavelli [mailto:sgund...@cisco.com]
Envoyé : mardi 11 mai 2010 23:31
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Cameron Byrne
Cc : softwires@ietf.org; BINET David NCPI/NAD/TIP
Objet : Re:
Re-,
Please see inline.
Cheers;
Med
-Message d'origine-
De : Sri Gundavelli [mailto:sgund...@cisco.com]
Envoyé : mercredi 12 mai 2010 09:12
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : softwires@ietf.org
Objet : Re: [Softwires] GI-DS-lite as working group item?
Hi Mohamed,
Please see
Hi Yiu,
Yes, I understand that point. My comment was related to the claim that
GI-DS-Lite allows to migrate to IPv6...which I still don't agree with.
What you mentioned is valid for any NAT-based solution. My concerns are as
follows:
(1) Since it seems that 3GPP is interested in this
Hi Yiu,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Lee, Yiu [mailto:yiu_...@cable.comcast.com]
Envoyé : mardi 18 mai 2010 21:58
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli
Cc : softwires@ietf.org
Objet : Re: [Softwires] GI-DS-lite as working group item?
Hi Med,
Dear Jacni,
Please see inline.
Cheers,
Med
De : softwires-boun...@ietf.org [softwires-boun...@ietf.org] de la part de
Jacni Qin [jac...@gmail.com]
Date d'envoi : jeudi 27 mai 2010 17:54
À : Lee, Yiu
Cc : Durand, Alain; softwires@ietf.org
Objet : Re:
Dear all,
FYI, we have submitted this new I-D.
Comments, critiques, suggestions and questions are more than welcome.
As mentioned in the draft, the provisioning of the AFTR is a very sensitive for
the delivery of the IPv4 connectivity when DS-Lite is enabled. Any failure to
provision such
Dear Tomek,
Thank you for this clarification.
Providing the IP address in the option is not flexible enough and especially it
may not be recommended to achieve load balancing. Otherwise the DHCPv6 server
should act as a load balancer, which is not currently our preference.
To illustrate more
Hi Yiu, all,
If there is a real issue with defining two DHCPv6 options (which I don't see),
an alternative would be to define one option with a sub-code field. This field
indicates whether the option carries an IP address or a name option.
Cheers,
Med
De :
Dear Raplh,
Do you suggest the I-D should elaborate further on the FQDN use cases so this
to be acceptable by the IESG?
Chairs, how should we proceed? The version which passed the WG LC is not the
05.
Cheers,
Med
-Message d'origine-
De : softwires-boun...@ietf.org
Dear Ted,
The version which passed the Softwire LC is
http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which
included both name and IP address options.
After IESG review, 05 has been published but this version has significant
changes.
We are at least two service
Dear Alain, all,
I strongly object to define only a single AFTR address option. As I mentioned
in previous e-mails, the FQDN name option is needed for some scenarios such as
load balancing. Having DHCP server acting as a load balancer is not an option
for us.
If the problem is only with the
David (document shepherd), Jari, all,
In can answer to the technical questions, but before that let
position this discussion in its context in the overall process
(softwire should follow the ietf process). Below a reminder of the
main steps for the adoption of this document:
o
Dear chairs,
We would like to have a slot for
(1)
Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-dslite-v6only-00
Time slot: 10 mins
Presenter: Yiu Lee
and for
(2)
Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03
Time slot: 10 mins
Presenter:
Dear Alain, all,
In addition to the technical reasons mentioned in previous e-mails, I
would like to raise that operational issues should be also taken
into account for the provisioning of the DS-Lite AFTR reachability
information. In particular, we are considering two levels of
Dear all,
When per-interface NAT is applied to 3GPP networks, a NAT function
can be embedded in the GGSN/PGW. The GTP tunnel identifier will be
used as an identifier in the NAT table to identify sessions belonging
to each UE. Packets are then translated and forwarded to their
Dear Alain,
I believe draft-cui-softwire-host-4over6 and
draft-boucadair-softwire-dslite-v6only have the same scope: Provide IPv4
connectivity over an IPv6-only network.
I would expect these I-Ds to be listed under the same category.
Cheers,
Med
-Message d'origine-
De :
Dear all,
This version is almost Ok. I still have two comments:
(1) Malformed DHCP answers sent by the DHCP Server:
The I-D restricts the server to convey only on FQDN in the AFTR-Name. Then, it
is coherent for the client to not accept an AFTR-Name which conveys several
FQDN since this is a
Dear Alain, Yiu,
Is there any plan to update the DS-Lite draft to take into account the comments
received so far and to make this document progress?
Cheers,
Med
-Message d'origine-
De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr]
Envoyé : mercredi 18 août 2010 21:48
À
Dear all,
I have just read the new DS-Lite version and I have the following comments for
Section 8:
(1)
8.2. NAT conformance
A dual-stack lite AFTR SHOULD implement behavior conforming to the
best current practice, currently documented in [RFC4787] and
[RFC5382]. Other discusions
Dear Ole,
For sure, the text can be shortened whenever possible.
If you point me to sections you think it need to be re-worded, this would be
appreciated.
Thank you.
Cheers,
Med
-Message d'origine-
De : Ole Troan [mailto:ichiroumak...@gmail.com] De la part de Ole Troan
Envoyé :
Dear all,
An updated version of the Motivations for Stateless IPv4 over IPv6 Migration
Solutions I-D has been submitted. The document is available at:
http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02
This document has been largely reviewed and inputs from other
Dear Dave,
I would personally appreciate if you can draft your thoughts in form of an I-D
before the meeting so that we can comment on them and discuss the points you
are raising.
FWIW, draft-operators-softwire-stateless-4v6-motivation does not argue against
stateful but it elaborates on a
Hi Rémi,
Yes, there was a vote in favour of adopting this document as a WG document but
as you know this vote should be confirmed in the ML. A call for adoption should
normally be issued by the chairs according to the IETF procedure.
As for the content of the next iteration of the document, we
Dear Qiong,
Yes, port ranges can be used in a CGN-based architecture too to reduce log file
volume as discussed in
http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02#section-3.1.3
but then you should be aware you loose a feature offered by the CGN which is:
* The
Dear all,
I fully agree with Rajiv.
I would like to add to the list of stateless solutions the proposal specified
in: http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04 and its
companion I-D:
http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-01.
Hi Tina,
Thank you very much for reviewing carefully this document.
Your editorial suggestions will be considered when we will generate the next
revision of the I-D.
As for the comment about the co-location of the MLD Querier and mAFTR, this is
a deployment scenario among others. The I-D
Hi Tina,
Please see inline.
Cheers,
Med
De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part
de Tina TSOU
Envoyé : mercredi 24 août 2011 04:21
À : Jacni Qin
Cc : softwires@ietf.org
Objet : Re: [Softwires] Comments on
Hi Tina,
I agree with Yiu. FYI, we had a discussion between co-authors of the draft
whether we maintain
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or
remove it.
You can read in that section:
Additionally,
mechanisms such as MLD Snooping, MLD Proxying,
Hi Tina,
I agree with Yiu. FYI, we had a discussion between co-authors of the draft
whether we maintain
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or
remove it.
You can read in that section:
Additionally,
mechanisms such as MLD Snooping, MLD
Hi Tina,
Please see inline.
Cheers
Med
De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com]
Envoyé : vendredi 26 août 2011 04:35
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin
Cc : softwires@ietf.org
Objet : RE: [Softwires] Comments on
Re-,
L2-relatd considerations described in Section 8 of draft-qin does not require
any specific behaviour from the mAFTR.
I suggest we continue this thread off-line.
Cheers,
Med
-Message d'origine-
De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com]
Envoyé : vendredi 26 août 2011
Dear all,
We have just submitted an I-D analysing the port set algorithms we have on the
table. A set of properties are used to characterize the port set algorithms.
This is a call for review. In particular, we invite authors of the following
proposals to review their section:
o
Hi Jacni,
Please see inline.
Cheers,
Med
De : Jacni Qin [mailto:ja...@jacni.com]
Envoyé : mardi 6 septembre 2011 11:30
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Wojciech Dec; softwires@ietf.org
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
Hi Satoru,
What I have done is I clarified the text as follows:
o Complexity: Reflects the complexity level of understanding the
algorithm and the expected complexity to configure an
implementation.
Is this fine or you think we need to elaborate further?
Cheers,
Med
Dear all,
We submitted a new I-D identifying the requirements to be met when designing
the format of IPv4-embedded IPv6 addresses/prefixes enclosing the port
information. The first list of requirements is available at:
Re-,
Please see inline.
Cheers,
Med
De : Jacni Qin [mailto:ja...@jacni.com]
Envoyé : mercredi 7 septembre 2011 10:12
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Wojciech Dec; softwires@ietf.org
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
Dear Maoke,
Please see inline.
Cheers,
Med
De : Maoke [mailto:fib...@gmail.com]
Envoyé : mercredi 7 septembre 2011 15:43
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [Softwires] Requirements for extending IPv6 addresses with port
range
Hi Rémi,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Rémi Després [mailto:despres.r...@free.fr]
Envoyé : mercredi 7 septembre 2011 10:56
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : GangChen; softwires@ietf.org; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing
Hi Rémi,
Please see inline.
Cheers,
Med
De : Rémi Després [mailto:despres.r...@laposte.net]
Envoyé : mercredi 7 septembre 2011 14:06
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Jacni Qin; Softwires-wg; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing
Dear Gang,
The logic we adopted for guessing complexity of a valid port and for the whole
range is as mentioned in
http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2:
In each analyzed port derivation algorithm, an attacker may implement
a redirection
Dear all,
To avoid confusion with address format discussion, we generated an document
grouping a set of requirements to be met by stateless solutions. I know some of
you have in mind a set of features to be supported. These features may be
translated into requirements. Comments and inputs are
Dear all,
A new version of the motivations I-D is available at:
http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00
I updated the I-D according to the conclusions of this thread:
http://www.ietf.org/mail-archive/web/softwires/current/msg02558.html.
The changes since
Hi Rémi,
Thank you for this input.
As for the differentiated port sets, I'm planning to add the following
properties to -01 of draft-bsd-* (need to be discussed with my co-authors):
o Differentiated Port Sets (Bound to the same IP address):
Capability to assign port sets of
Hi Rémi,
Thank you or your answer but my question was not on the CPE side but the
operations at the border router side.
Cheers,
Med
-Message d'origine-
De : Rémi Després [mailto:despres.r...@laposte.net]
Envoyé : lundi 12 septembre 2011 17:05
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc :
Hi Rémi,
I didn't get my answer yet. I'm looking for the explanation about the behaviour
of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned
with port sets of different sizes. What is the configuration of that node?
Cheers,
Med
-Message d'origine-
De :
Hi Behcet,
This property aims to assess if the proposed algorithms:
1. Preserve the port parity as discussed in Section 4.2.2 of
[RFC4787].
and
2. Preserve port contiguity as discussed in Section 4.2.3 of
[RFC4787] (i.e., RTCP=RTP+1).
An elaboration is also provided in:
Dear Gang,
Please see inline.
Cheers,
Med
-Message d'origine-
De : GangChen [mailto:phdg...@gmail.com]
Envoyé : samedi 17 septembre 2011 10:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Simon Perreault; softwires@ietf.org
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
Hi Behcet,
It is part of the service provider business to offer services which rely on the
0-1023 range even in a shared address environment (e.g., host an FTP server,
etc.). Because statically not all subscribers use these features, the whole
0-1023 range may be assigned only to few
Hi Rémi, all,
Since there is only an excerpt of e-mails, I lost the context.
Could you please clarify what is the issue discussed here? Thanks.
Cheers,
Med
-Message d'origine-
De : Rémi Després [mailto:despres.r...@laposte.net]
Envoyé : jeudi 3 novembre 2011 10:05
À : Jacni
Dear WG members,
I would like to close this document so that we can meet the following item from
the WG Charter:
4. Developments for stateless legacy IPv4 carried over IPv6
- develop a solution motivation document to be published as an
RFC
- develop a protocol specification response to the
Dear Cameron,
Yes, I know it is tempting to have such section but it won't help in making a
decision and, furthermore, it may maintain a tension between stateless and
stateful camps. We tried in the document to be neutral as much as possible and
avoid claiming stateless is superior to stateful
Dear chairs, WG members,
The answers received so far are in favour of initiating a WG LC on this
document.
As an editor of the document, I would like to progress this document for the
next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
Cheers,
Med
-Message
Hi Reinaldo, all,
I read the updated version of draft-penno-softwire-sdnat. I like this new
version. Below some questions for clarification:
(1) draft-penno is converging to what is documented in
draft-cui-softwire-b4-translated-ds-lite:
(*) Question 1: It is not clear in text if
Hi Francis,
Please see inline.
Cheers,
Med
-Message d'origine-
De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr]
Envoyé : mardi 13 mars 2012 17:56
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG;
Re-,
Thanks Rajiv for the pointer.
BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must be
adjacent), draft-cui-* and the like can use pseudo-random algorithms to
generate port ranges.
Cheers,
Med
-Message d'origine-
De : Rajiv Asati (rajiva)
Dear Qiong,
Please see inline.
Cheers,
Med
De : Qiong [mailto:bingxu...@gmail.com]
Envoyé : mercredi 14 mars 2012 00:50
À : Francis Dupont
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG;
draft-cui-softwire-b4-translated-ds-lite;
Re-,
Thanks Alain for the answers. Please see inline.
Cheers,
Med
-Message d'origine-
De : Alain Durand [mailto:adur...@juniper.net]
Envoyé : mercredi 14 mars 2012 12:11
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG;
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Alain Durand [mailto:adur...@juniper.net]
Envoyé : jeudi 15 mars 2012 12:11
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG;
draft-cui-softwire-b4-translated-ds-lite
Hi Francis,
Yes, you are right. There is no explicit method in PCP to get the external IP
address. You know we have both asked for it in early days of PCP but the WG
consensus was that we can mimic this by using MAP with short lifetime.
As for your PS, this a discussion point for the PCP WG.
Hi Yiu,
Sending back an ICMP message when receiving a port out of range should be
configurable IMHO.
When receiving a port out of range, the behaviour of REQ#12 (A, B and C) of
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3 can
be followed by the AFTR.
No need to
Dear Stig,
For sure mboned will had the opportunity to review it. No matter where the
document is specified if a piece of work is needed.
This is the kind of cross-WG documents that would require some flexibility form
the IETF to make progress.
Cheers,
Med
-Message d'origine-
De :
Dear Washam,
This is an issue common to all stateless solutions, including deterministic NAT
with (anaycast) IPv4 address pool.
FWIW, we recorded this issue here:
http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2.
As a solution to this issue, we proposed to implement the
Dear Gang,
Thanks, but I failed to find the text describing how to handle two fragments
received by two distinct BRs.
Could you please point me to that text in case I miss it?
Cheers,
Med
-Message d'origine-
De : GangChen [mailto:phdg...@gmail.com]
Envoyé : jeudi 22 mars 2012 08:33
À
Hi Rémi,
This is well understood. The issue and the behaviour you are describing is
common to all address sharing solutions with or without NAT; including all A+P
flavours (MAP, 4rd, SDNAT).
The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** issue,
consider the solution
Dear WG members,
I didn't had time to read the last version of 4rd-U but I read carefully -03
when it was published.
I really appreciated the work done by Rémi to write down -03. The document is
well written, easy to read and the requirements are clearly sketched. I really
think this spirit
Dear all,
I personally regret this decision and reject the justifications provided. If
you don't want people to contribute and express their opinion, it is easy: make
it a close community.
If you insist to ignore what expressed the majority of individuals who
participated to the poll, may I
Hi Simon,
We tried in this document to avoid as much as possible including implementation
details but instead we focused on the external behaviour of the interworking
functions. Let me recall there are already available implementations based on
the specification of
Re-,
See inline.
Cheers,
Med
-Message d'origine-
De : Simon Perreault [mailto:simon.perrea...@viagenie.ca]
Envoyé : jeudi 7 juin 2012 15:47
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Yong Cui; softwires@ietf.org
Objet : Re: [Softwires] WG last call on
Hi Peng,
I vote for having one single document which covers both shared and full IPv4
address.
If you start for instance from draft-cui-softwire-b4-translated-ds-lite, what
is needed is to add one sentence to say a full IPv4 address can be provisioned.
Does this make
Hi Woj,
Your comment is valid.
The point I wanted to make is to recall the initial motivation of this draft:
solve an issue raised by DS-Lite people.
Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This
will be reflected in the updated version of the draft.
Cheers,
Dear Dapeng,
Please see inline.
Cheers,
-Message d'origine-
De : liu dapeng [mailto:maxpass...@gmail.com]
Envoyé : vendredi 8 juin 2012 13:49
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Yong Cui; softwires@ietf.org
Objet : Re: [Softwires] WG last call on
Hi Dapeng,
A state maintained in the endpoint does not make the solution stateful, see
this excerpt from RFC1958:
This principle has important consequences if we require applications
to survive partial network failures. An end-to-end protocol design
should not rely on the maintenance
Hi Behcet,
I failed to understand the point you are trying to make.
The current situations is:
* this document provides multicast extension to deliver multicast to DS-Lite
serviced customers
* we rely on multicast capabilities, as such no AMT-like considerations are
included
* the proposed
Re-,
I was answering to your last proposed wording to include the port translation
in the host. Except that change, all your proposed changes are included in my
local copy:
* The title has been updated as your requested
* The introduction has been updated.
Cheers,
Med
-Message
Hi Yiu,
Works for me. Thanks.
Cheers,
Med
-Message d'origine-
De : Lee, Yiu [mailto:yiu_...@cable.comcast.com]
Envoyé : lundi 11 juin 2012 16:54
À : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng
Cc : softwires@ietf.org; Yong Cui
Objet : Re: [Softwires] WG last call on
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : liu dapeng [mailto:maxpass...@gmail.com]
Envoyé : mardi 12 juin 2012 11:49
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action:
draft-ietf-softwire-stateless-4v6-motivation-02.txt
Behcet,
If you are suggesting we need get rid of multicast capabilities and use unicast
between the AFTR and B4, I still claim this is a bad design choice. The
rationale for the design documented in the draft is as follows (excerpt from
the draft):
If customers have to access IPv4
Re-,
Did you read draft-ietf-softwire-dslite-multicast?
I have some doubts given your message below.
Cheers,
Med
-Message d'origine-
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : lundi 11 juin 2012 18:08
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org;
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : liu dapeng [mailto:maxpass...@gmail.com]
Envoyé : mercredi 13 juin 2012 12:09
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action:
Hi Tom,
Thank for the proposal. I can update the text with your proposed wording if
Dapeng is OK.
Dapeng, are you happy with the text proposed by Tom?
Cheers,
Med
-Message d'origine-
De : Tom Taylor [mailto:tom.taylor.s...@gmail.com]
Envoyé : mercredi 13 juin 2012 17:44
À :
Dear all,
I really don't understand this issue.
It is even misplaced to have this comment at this stage, since this is a
document which has been adopted by the WG and the solution it specifies is the
same as the one reviewed by the WG prior to its adoption (i.e., since April
2011).
Anyway,
Woj,
The argument you are raising applies also for (1) and (3): one can argue this
justifies editing an RFC6333-bis to cover the per-subscriber state case ;-)
As I mentioned in my first message, MAP can be extended to cover the
per-subscriber case at the cost of adding confusion by abandoning
Re-,
Yes, the CGN is not required. This design choice is motivated in the draft
(read the Introduction text).
What is the issue then?
If you are saying this is a generic solution and it does not apply only to
ds-lite, this point is taken (see the note below).
Cheers,
Med
Hi Stig,
Wouldn't be sufficient enough to add this sentence to the abstract and the
Introduction:
The proposed solution can be deployed for other 4-6-4 use cases.
Thanks.
Cheers,
Med
-Message d'origine-
De : Stig Venaas [mailto:s...@venaas.com]
Envoyé : vendredi 27 juillet 2012
Hi Behcet,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : vendredi 27 juillet 2012 18:48
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwire issue tracker;
draft-ietf-softwire-dslite-multic...@tools.ietf.org;
Dear all,
A new version taking into account comments received during the WGLC has been
submitted. The main changes are:
* change the title
* clarify the solution is generic for any 4-6-4 use case and the solution has
been designed with DS-Lite in mind
* add a discussion about scoping: preserve
Hi Behcet,
I'm ready to record in the document whatever the WG agrees to do. But as far as
I know the solution which consists in encapsulating all multicast flows to the
unicast AFTR has not been accepted by the working group. The drawbacks are even
been documented in this draft.
I'm aware
Dear Edwin,
Thank you for sharing the experiment results.
I saw you made tests for torrent applications. FWIW, we had done an extensive
testing of this application. The results of these testing are valid for all
address sharing variants (including A+P):
Dear Joel,
Thank you for the review.
Please see inline.
Cheers,
Med
-Message d'origine-
De : softwires-boun...@ietf.org
[mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : vendredi 5 octobre 2012 17:15
À : A. Jean Mahoney
Cc : softwires@ietf.org;
Dear Joel,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Joel M. Halpern [mailto:j...@joelhalpern.com]
Envoyé : vendredi 5 octobre 2012 17:52
À : BOUCADAIR Mohamed OLNC/OLN
Cc : A. Jean Mahoney; softwires@ietf.org; gen-...@ietf.org;
Yong Cui;
Dear all,
A new version was submitted with the following change:
* Remove a normative reference.
We believe this version is ready for a WGLC.
Cheers,
Med
-Message d'origine-
De : softwires-boun...@ietf.org
[mailto:softwires-boun...@ietf.org] De la part de
internet-dra...@ietf.org
Dear Ted,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Ted Lemon [mailto:ted.le...@nominum.com]
Envoyé : jeudi 18 octobre 2012 14:51
À : BOUCADAIR Mohamed OLNC/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action:
draft-ietf-softwire-multicast-prefix-option-02.txt
Behcet,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : jeudi 18 octobre 2012 21:40
À : BOUCADAIR Mohamed OLNC/OLN
Cc : softwires@ietf.org
Objet : Re: [Softwires] I-D Action:
draft-ietf-softwire-dslite-multicast-04.txt
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
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;
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 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:
1 - 100 of 224 matches
Mail list logo
