Hi,
It seems that the draft-sun-softwire-yang-04 has been expired for a period.
Just a question: Are the authors still working on that draft? I'm still
interested in it.
Thanks !
Best wishes
Qiong Sun from China Telecom
___
Softwires mailing list
Hi all,
I agree on merging these two draft too. Thanks a lot!
Best wishes
Qiong
On Tue, Mar 22, 2016 at 9:28 AM, Zhouqian (Cathy) <cathy.z...@huawei.com>
wrote:
> Agree on merging the two drafts.
>
>
>
> Cathy
>
> *发件人:* tianxiang li [mailto:peter416...@gmail.com]
Dear Yong,
I would like to apply for 3 time slots:
1) map deployment consideration: 10 min
2) lw4over6 radius : 5 min
3) lw4over6 deployment consideration: 5 min
Thanks a lot!
Best wishes
Qiong
On Sun, Oct 4, 2015 at 8:34 AM, Yong Cui <cuiy...@tsinghua.edu.cn> wrote:
> Hi folks,
>
XLAT be included
in this draft?
I may come back with further comments. Thanks!
Best wishes
Qiong
On Fri, Mar 7, 2014 at 4:36 AM, Tom Taylor tom.taylor.s...@gmail.comwrote:
Comments and additions are invited. If there is no enthusiasm for the
project I'll drop the subject.
Scope
to
describe what is lw4o6.
Best wishes
Qiong
On Thu, Mar 6, 2014 at 12:17 AM, Qi Sun sunqi.csnet@gmail.com wrote:
Woj,
I don't think map is more optimized than lw4over6 when IPv4 and IPv6 are
totally decoupled (which is lw4over6 designed to deal with). I would prefer
to follow Ole's
Hi Tom,
I also prefer to compare with these solutions in a separate draft.
Best wishes
Qiong
On Fri, Mar 7, 2014 at 4:09 AM, Tom Taylor tom.taylor.s...@gmail.comwrote:
When in doubt, take it out.
I'll propose methodology for another draft comparing the various
approaches in a separate E
Dear all,
I also support the adoption.
Best wishes
Qiong
On Wed, Jul 31, 2013 at 2:58 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Dear all,
I support the adoption.
Thank you,
Tina
On Jul 30, 2013, at 7:25 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:
Hi all,
Today
of the BR could
be provisioned by the DS-Lite AFTR Name option. But the DMR is still in use
in MAP-T. IMO, this is an issue. But maybe the WG could give some guidance
on handling this.
[Qiong] This is also the question for the WG. I'm wondering what's the
reason of this change in MAP-E
Hi Roberta,
On Mon, Jul 15, 2013 at 7:40 AM, Roberta Maglione (robmgl) rob...@cisco.com
wrote:
In addition even if you could, it would sound confusing in my opinion,
using a DS-Lite specific option to provision MAP specific parameters.
[Qiong] I agree with you. I think using DMR is more
Hi all,
I support it to move forward.
Thanks.
Best wishes
Qiong
On Fri, May 24, 2013 at 12:18 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
This message starts a two week softwire working group last call on
advancing the draft defining the Softwire Mesh MIB
Support to move forward. Thanks!
Best wishes
Qiong
On Fri, May 24, 2013 at 12:07 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
This call is being initiated to determine whether there is WG
consensus towards adoption of draft-fu-softwire-map-mib-05 as a softwire
WG
given that the
point is made with Figure 2?
[Qiong] It is true that Figure 2 can also illustrate network model C. We
will modify it accordingly.
Section 4.2 first paragraph
===
In the middle of the paragraph there is the statement:
All CEs in the MAP domain
Hi authors,
Thanks for your work on this failover mechanism. I think it is in good
shape.
For the scope of this draft, does it only apply to DS-Lite ? I think it is
also helpful for lw4over6 scenario.
Best wishes
Qiong
On Sat, Feb 2, 2013 at 1:50 AM, Tina TSOU tina.tsou.zout
and comments are more than welcome. Thanks in advance !
Best wishes
Qiong
On Wed, Feb 27, 2013 at 11:17 AM, Maoke fib...@gmail.com wrote:
hi all,
a text mistake is discovered (by Masakazu Asama-san, the developer of
ASAMAP MAP implementation, thanks a lot to Asama-san!). the erratum must
cleaner stateless solution and easy understanding.
Best wishes
Qiong
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Dear all,
Support to adopt. This is a good starting point to work with both MAP and
LW4O6.
Best wishes
Qiong
On Tue, Feb 5, 2013 at 1:29 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
This draft was a result of the discussion initiated at the softwire
meeting in Atlanta
. The only possibility is to change the provisioning
approach to provision the Rule IPv6 prefix, the complete shared IPv4
address, and the PSID explicitly, then describe how to construct the MAP
endpoint IPv6 address.
[Qiong] Right. You have just pointed out some essential differences between
MAP
Dear Suresh,
I support this document to move forward. This version has solved all the
technical issues, and it is quite simple for some specific use case. I
think it is ready to move forward :)
Merry Christmas and Happy new year !
Qiong
On Mon, Dec 17, 2012 at 12:33 PM, Suresh Krishnan
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
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
Exactly! '4over6' indicates v4 address and v6 address is decoupled...
Best wishes
Qiong
On Tue, Nov 13, 2012 at 4:01 PM, Leaf yeh leaf.y@huawei.com wrote:
I guess '4over6' sounds a better name for the solution whether it has
IPv6(A) mapping for IPv4(A+P) or not.
Best Regards,
Leaf
Ole,
On Sun, Nov 11, 2012 at 9:11 PM, Ole Trøan otr...@employees.org wrote:
Qiong,
Now that you need to optimize the implementation for different
requirements, why not optimize it from protocol level ? So that every
vendor would know how to implement for different requirements, rather
+1 agree.
If there is no mapping with addressing and port at all, how can it still
be called MAP anymore ?
Best wishes
Qiong
On Tue, Nov 13, 2012 at 2:35 AM, Lee, Yiu yiu_...@cable.comcast.com wrote:
Ole,
From my perspective, the argument is not whether two protocols are
identical
standardization, operators could still ask vendors to implement
whatever they want. But standardization would reflect the common
requirements from operators, and that would be easier for vendors to follow
and implement. I do not understand why we do not follow this efficient way.
Best wishes
Qiong
a /32 doesn't
mean you need a different RIB implementation.
[Qiong] Actually, that's not the same. If we only need /32, there is no
need to do LPM implementation anymore, only exact matching is needed and
this is much eaiser than LPM. LPM is not optimized for /32 routing lookup.
The reason
Support for both.
Best wishes
Qiong
On Tue, Sep 25, 2012 at 12:45 PM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense of the room
Hi Chairs,
Support to move forward with MAP-E as a basis stateless solution. It is a
remarkable milestone in Vancouver meeting to end the long time arguement
over the past two years.
Best wishes
Qiong
On Wed, Aug 8, 2012 at 6:02 AM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all
for EA=0 and EA0 stems from different requirements,
it is nature to treat them with seperately.
Best wishes
Qiong
On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec wdec.i...@gmail.com wrote:
Ole's and Satoru's eaerlier replies on this thread described the how,
and even Maoke's earlier post
of workload for operators
and it is obviously not the objective of any stateless solution.
2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP rule
is redundant.
Therefore, I don't see the reason to include PSID explicitly in MAP
architecture.
Best wishes
Qiong
Wojciech Dec
://sourceforge.net/projects/laft6/ and has a field trial in commerial
network.
From the authors of this document's view, it is ready to be adopted as
working group document. We would be appreciated to have your comments.
Thanks in advance !
Best wishes
Qiong
-- Forwarded message
Hi Tetsuya,
Well, then you mean this implementation is mode 1:1 A (raised by Maoke in
review on the mode 1:1 thread).
Sorry I misunderstand your meaning about this 1:1 mode. It clarifies a lot!
Thanks!
Best wishes
Qiong
On Thu, Jun 28, 2012 at 9:58 AM, Tetsuya Murakami
tetsuya.murak
useless or not optimized. And I will not deploy
per-subscriber stateful and stateless solutions at the same.
So I encourage two seperated approaches optimized for different scenarios.
It will be good for both.
Do we really all forget about the KISS principle ?
Best wishes
Qiong
On Tue, Jun 26, 2012
Hi Leaf,
On Wed, Jun 27, 2012 at 12:18 PM, Leaf yeh leaf.y@huawei.com wrote:
I might have a naive question: why does the Softtwire-WG need a document
for deployment other than a document for motivation?
Qiong: We already have a motivation draft that clearly demenstrates the
requirements
dimensioning practices, only considerations related to the customers
number, traffic trends and the bandwidth usage need be taken into
account.
Does it still fit for 1:1 mapping mode ?
On Mon, Jun 25, 2012 at 3:01 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi Qiong,
A MAP domain
as a WG item in such a short time.
From this perspective, draft-ietf-softwire-map-00 can only be regarded
as draft-XX-softwire-mapping-address-and-port-04. It is not even
the output of MAP design team.
Best wishes
==
Qiong Sun
China Telecom Beijing
Hi Reinaldo,
In my understanding, public 4over6 is mainly designed for host-orientied
server behind the CPE. So the senario of public 4over6 is different from
lightweight 4over6. It is better to be described seperately.
I support it to be advanced. Thanks.
Best wishes
Qiong
On Mon, May 28
+1 support.
On Sun, May 27, 2012 at 10:28 PM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01.
http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio
we cannot publish both as
standard track.
Answering NO to this question means you want to see both advance on the
standard track.
Qiong Sun, China Telecom: YES
Hi Alain,
Thanks a lot for your explaination. It is much clearer now. Please see
inline ~~
On Fri, Mar 23, 2012 at 10:06 PM, Alain Durand adur...@juniper.net wrote:
On Mar 23, 2012, at 4:22 AM, Qiong wrote:
Dear Alain and all,
I'm trying to understand sd-nat-02 and I'm still wondering
environment. We have run a Coexistent test
with DS-Lite (refer to
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in
Appendix 1.3). It would be very easy and simple. Thoughts?
Best wishes
Qiong
On Wed, Mar 14, 2012 at 10:32 PM, Lee, Yiu yiu_...@cable.comcast.comwrote:
I am
want as it makes CPEs trivial
to track, 2- it doesn't remove the mandatory check on source ports
in the from CPE to the Internet way)
[Qiong] Thanks for clarification. It seems this is not mentioned when to
adopt and how to process the second NAT in current version of sd-nat. But
still, I
We have submitted it to google, but google has not finished reviewing it.
btw, is there any possible way to accelerate its reviewing process ? It has
passed more than half a year. Is there anyone who can help ?
Thanks a lot!
Best wishes
Qiong
On Wed, Mar 7, 2012 at 11:33 PM, Cameron Byrne
Dear Chairs,
With the newly published map-d document, we also would like to apply for a
slot on:
http://www.ietf.org/id/draft-mdt-softwire-map-deployment-00.txt
Thanks in advance!
Qiong
On Thu, Mar 1, 2012 at 1:09 AM, Ole Trøan otr...@employees.org wrote:
Chairs,
If you intend to present
Dear Chairs,
On behalf of our co-authors, I would like to have a time slot for our
merged version of lightweight 4over6
(http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt)
and another deployment document coming soon.
Thanks in advance!
Best wishes
Qiong
On Wed, Feb 29
+1 support
On Mon, Feb 6, 2012 at 5:33 PM, christian.jacque...@orange.com wrote:
Hi,
I support the adoption of this draft as a softwire WG document.
Cheers,
Christian.
-Message d'origine-
De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la
part de Yong
of this document's view,
it is ready to be adopted as working group document. We would be
appreciated to have your comments.
Thanks in advance !
Best wishes
Qiong
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
, there will be double ALG
issues here. But as you mentioned in previous mail, in case double
translation is optional, double ALG would also be optional.
Anyway, it is an interesting stateless scheme and I would like to discuss
with you in Taipei :)
Best wishes
Qiong
On Tue, Nov 8, 2011 at 8:41 AM, Reinaldo Penno
. It is more like a
hubspoke stateless solution, e.g. stateless 4over6, etc. I'm not sure how
this kind of stateless mechanism compared to 4rd, dIVI, etc. And I would
prefer a unified address+port allocation algorithm in softwire WG.
Best wishes
Qiong
What do you think?
Cheers,
Olivi
On 11/2/11 8:06
and that it fits well with the other
approaches we've been discussing in softwire for
IPv4 over IPv6 mechanisms. I'll read through again and provide detailed
comments asap.
Qiong: Thanks. We are looking forward to your detailed comments.
with regards to document organization, would it be possible
it in Hunan
province.
A URL for this Internet-Draft is:
http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-03.txt
Your comments are more than welcome.
Best wishes
Qiong
Hi Leaf:
On Wed, Oct 12, 2011 at 3:24 PM, Leaf yeh leaf.y@huawei.com wrote:
Satoru - I think we could have it.
Tetsuya Murakami - the decapsulation could be done for the packet having
the tunnel end-point address as the destination or having the specific IPv6
prefix as the destination.
Hi, Jacni
Qiong: My concern is specific for virtual interface implementation. If
you implement a virtual interface(as most existing encapsulation approaches
have adopted in CPE ), you still need to do routing within CE (from physical
interface to virtual interface). In traditional
Hi, Remi and Jacni,
Thanks for the discussion.
On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després despres.r...@laposte.netwrote:
The 4rd function examines ALL packets that reach the CE.
It processes all those that have V in their destination addresses, and only
those.
Qiong: I think it might
Hi, Qiong,
Please see inline.
On Mon, Oct 10, 2011 at 3:26 PM, Rémi Després despres.r...@laposte.netwrote:
The 4rd function examines ALL packets that reach the CE.
It processes all those that have V in their destination addresses, and
only those.
Qiong: I think it might be better
identification in the same way.
Best wishes
Qiong
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
to the
source address format. What do you think of it?
Best wishes
Qiong
On Tue, Oct 4, 2011 at 12:22 PM, Rémi Després despres.r...@laposte.netwrote:
Hi all,
1.
Here is a unified Address Mapping, for both encapsulation and
double-translation approaches, that is PROPOSED for IPv4 residual
of an IPv6 address is such a change.
I don't understand what requirements you are basing this 'solution' on.
if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of
the delegated prefix. then why do you need any of that?
Qiong : I agree that routing lookup for a provisioned /64
-domain, which sub-domain is a part of the super domain. Is that
correct?
Best wishes
Qiong Sun
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
, we can discuss in this meeting.
Sorry that the draft has not explained this very clearly. We will improve it
later.
Thanks again.
Best wishes
Qiong Sun
since there is only one sub-
On Mon, Sep 26, 2011 at 6:08 AM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hi auhtors,
I have
Hi Ralph,
Fully agree. From operator aspect, we do not care about whether it is a
stateful or a totally stateless one. We are just interested in a good
solution which is easy to use, operate and cost less. So any solution,
either stateless or less stateful , will be welcome if they can meet our
Hi,
I support to adopt all.
Qiong Sun
On Sat, Aug 20, 2011 at 10:21 PM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation
is irrelevant for my point. I think this
section should be modified in a way like the logging section or any
other appropriate way, which explains, that this is not the benefit of
the stateless nature, but rather the benefit of the static port allocation.
[Qiong]: +1 Agree.
Med: Your point
for 4rd mapping
rule is smaller than the resources for NAT session because usually NAT
session contains many information.
[Qiong]: Basically agree that '4rd mapping rule is smaller than the
resources for NAT session', but 4rd CEs would still do NAPT similar to
traditional CPE's NAPT
that differentiate which solution
applies best to which network.
[Qiong]: Agree.
Adapting a CE to up to 1000 rules doesn't seem difficult to me, and with
O(log n) matching this can be done with satisfactory performance.
(More details would be private consultancy ;-)).
[Tetsuya] Thousands
-contradictory.
Now:
- Some ISP's want _direct CE-CE paths_ .
[Qiong] : Agree. This is a good feature for stateless solution. But there
might be no big differences from stateful solutions when deploying CGN on
the edge of network, e.g. BRAS, etc.
- For this each CE must know mapping rules for all
Hi Lee,
Thank you very much for your interests on 'lightweight 4over6'.
In our consideration, lightweight AFTR is not doing port-range routing. In
this lightweight AFTR, it would firstly lookup a mapping table (recording
[IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then
Hi, Satoru,
Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address
sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing.
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
Thanks
Best wishes
Qiong Sun
On Sat, Jul 30, 2011 at 9:57 PM
Hi, Jan,
I guess this kind of port exhaustion problem will also exist in dynamic CGN.
Assume the average port number consumed by average subscribers are 2000
(around 32 users per public IPv4 address) and this CGN has 32 concurrent
users at that time with the only public IPv4 address in the
:
Le 1 août 2011 à 17:04, Qiong a écrit :
...
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource, or port
exhaustion.
Maybe we
:19, Qiong a écrit :
Hi, Remi, Dave,
I'm not sure whether I get the point in Dave'd slide. Please correct me if
anything is wrong.
In my understanding, the major problem in this failure mode would happen on
the downstream path, rather than the upstream one. A node which is attached
optimization work will still be needed to
make it more stateless ?
Best wishes
On Thu, Jul 28, 2011 at 3:08 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Hello Qiong,
Routing always supports us. You can choose a tunnel which have appropriate
mapping rule by your routing table
this is also a tradeoff between different solutions.
Best regards
Qiong Sun
On Thu, Jul 28, 2011 at 7:10 PM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Matsushima-san,
In this draft, we may need to refer or define the definition of
- Stateful operation
- Stateless operation
- Dynamic port
, and full IPv4 address per customer,
- the other, slightly lower, for length L+K of IPv6 prefixes, and shared
IPv4 address per customer.
Thus the number of full-address customers can be expected to decrease, and
the longest IPv4 prefixes can be expected to progressively be reclaimed.
[Qiong]: I'm
regards
Qiong Sun
2.
Unless I misinterpreted, you asked about the failure mode of a host that
isn't part of a shared IPv4 address system and is attached to such a system.
Assuming that, in the context of the discussion, this implicitly referred
to a static shared-address system, I don't
Dear Yiu,
From the perspective of an
operator, we strongly support the first use case. For transmission
efficiency, we need to deliver streaming contents through
multicast-capable network.
And we are doing our effort to make it multicast-capable.
Thanks.
Qiong SUN
On Thu, Jul 28, 2011 at 2:19
75 matches
Mail list logo
