Author(s) : Jacni Qin
Mohamed Boucadair
Christian Jacquenet
Yiu L. Lee
Qian Wang
Filename: draft-ietf-softwire-dslite-multicast-03.txt
Pages : 20
Date
Stig,
Thanks a lot for the comments and the proposed text, we'll consider that.
Cheers,
Jacni
On 8/23/2012 Thursday 1:39 AM, Stig Venaas wrote:
On 7/30/2012 12:06 AM, mohamed.boucad...@orange.com wrote:
Hi Stig,
Wouldn't be sufficient enough to add this sentence to the abstract
and the
Re-,
Seems to be a good choice, I'm in favor of it.
Cheers,
Jacni
On 8/8/2012 Wednesday 6:02 AM, Suresh Krishnan 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 was
On 7/13/2012 Friday 9:22 PM, Tom Taylor wrote:
On 13/07/2012 1:44 AM, Stig Venaas wrote:
On 12.07.2012 20:21, Jacni Qin wrote:
On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote:
Well, from the so many mails below it is clear that
No, it's clearly clarified from the mails, about
Hi Stig,
Thanks a lot for your comments.
On 7/14/2012 Saturday 4:57 AM, Stig Venaas wrote:
On 7/12/2012 8:20 PM, Jacni Qin wrote:
Hi all,
Please see below the text updated according to the comments received.
Many thanks to Stig, Simon, Shailesh, and others for their review and
discussions
Hi all,
Please see below the text updated according to the comments received.
Many thanks to Stig, Simon, Shailesh, and others for their review and
discussions.
4.2. Multicast Distribution Tree Computation
...
The mAFTR MUST advertise
wrote:
Hi
On 7/2/2012 9:00 AM, Jacni Qin wrote:
Hi Stig,
Inline please,
On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote:
On 6/27/2012 10:24 PM, Jacni Qin wrote:
Hi Stig,
Thanks for you comments and support, please see below inline.
On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote:
FWIW, here
Hi Stig,
Inline please,
On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote:
On 6/27/2012 10:24 PM, Jacni Qin wrote:
Hi Stig,
Thanks for you comments and support, please see below inline.
On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote:
FWIW, here is my take on this.
On 6/27/2012 8:30 AM
and Assembly Overheads in mAFTR and mB4
respectively.
I think, addressing these points would be vital for this I.D.
[YL] I agree. We will propose some text in next revision.
Thanks,
Yiu
Regards
-Shailesh
Message: 1
Date: Tue, 26 Jun 2012 07:36:41 +0800
From: Jacni Qin ja...@jacni.com
On 6/27/2012 Wednesday 11:30 PM, Behcet Sarikaya wrote:
On Mon, Jun 25, 2012 at 6:36 PM, Jacni Qin ja...@jacni.com wrote:
Re-,
On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote:
On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote:
Hi Behcet, all,
On Friday, June 22, 2012 2
Re-,
On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote:
On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qinja...@jacni.com wrote:
Hi Behcet, all,
On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote:
Folks,
We have published revised version of our draft on multicast extensions
to DS-Lite
Re-,
On 6/5/2012 Tuesday 9:09 PM, Simon Perreault wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS
hi simon,
Sorry for the late reply, please see below,
On 5/28/2012 Monday 10:11 PM, Simon Perreault wrote:
On 2012-05-27 10:34, Yong Cui wrote:
This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
to pick one he
believe it is feasible suitable, or even not pick any of these solution.
Best Regards,
Leaf
*From:*softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
*On Behalf Of *Jacni Qin
*Sent:* Friday, May 04, 2012 10:03 AM
*To:* Ole Trøan
*Cc:* softwires@ietf.org
*Subject:* Re
Ole,
On Thursday, May 03, 2012 2:58:35 PM, Ole Trøan wrote:
Jacni,
My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.
would it alleviate your concerns if the documents had MUSTs for both? i.e.
increasing the
Ole,
On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote:
Jacni,
My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.
would it alleviate your concerns if the documents had MUSTs for both? i.e.
increasing the probability
Re-,
On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote:
Well, even the WG decided to go with MAP, we would still need to coin toss
between MAP-T and MAP-E, wouldn't we?
May I share your concern.
Cheers,
Jacni
On 4/26/12 10:50 AM, Jan Zorz @ go6.sij...@go6.si wrote:
On 4/26/12 11:50 AM, Mark
and T.
Cheers,
Jacni
From: Jacni Qin ja...@jacni.com mailto:ja...@jacni.com
Date: Wednesday, May 2, 2012 9:03 PM
To: Yiu L. LEE yiu_...@cable.comcast.com
mailto:yiu_...@cable.comcast.com
Cc: Jan Zorz @ go6.si j...@go6.si mailto:j...@go6.si,
softwires@ietf.org mailto:softwires@ietf.org
Re-,
Thanks Jiang Dong, for your comments, I'll discuss with the authors
about it.
Cheers,
Jacni
On 4/18/2012 Wednesday 11:08 AM, Jiang Dong wrote:
HiShishio,
It seems the definition of 6rd MIB is more acceptable than the
extension of IP tunnel MIB according to the Softwire meeting in Paris.
Re-,
+1,
IMHO it's unacceptable in practice.
Cheers,
Jacni
On 2/9/2012 2:39 AM, Lee, Yiu wrote:
Hi Remi,
I know this is possible to do, in theory. However my question is more
toward manageability of the network. IMHO, layering one tunnel (or
translation) protocol on another tunnel protocol
Re-,
+1
Cheers,
Jacni
On 2/8/2012 12:53 AM, Reinaldo Penno wrote:
Hello Chairs/AD,
I've been following this discussion and believe both 4rd-U and MAP should be
given a fair and impartial evaluation. IMO we should also avoid 'designing
by committee' and mashing everything together just in an
Hi all,
On 1/30/2012 7:31 PM, Ole Trøan wrote:
hi,
the MAP (Mapping of address and port) design team has now written and published
the following sets of drafts.
the base document (port mapping algorithm):
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
) : Lei Cai
Jacni Qin
Filename : draft-cai-softwire-6rd-mib-00.txt
Pages : 10
Date : 2011-05-19
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols. In particular, it
defines objects for managing 6rd devices.
A URL for this Internet-Draft
Hi Alain and Yong,
We'd like to request 10 minutes for:
draft-ietf-softwire-dslite-multicast-01,
and another 10 minutes for: draft-qin-softwire-multicast-prefix-option-01
Cheers,
Jacni, on behave of all authors
On 11/4/2011 8:26 PM, Alain Durand wrote:
If you want to present during the
hi Remi,
On 11/3/2011 5:04 PM, Rémi Després wrote:
Le 3 nov. 2011 à 09:50, Jacni Qin a écrit :
if the MAP just covers shared address with one single sharing ratio for one
domain,
the design will be greatly simplified?
Requiring ISPs to maintain IPv4 routing in their networks, just to serve
hi,
On 11/3/2011 5:24 PM, Rémi Després wrote:
Le 3 nov. 2011 à 10:04, Ole Troan a écrit :
...
Requiring ISPs to maintain IPv4 routing in their networks, just to serve the
few users that need to keep IPv4 prefixes, seems to me a step backward.
can you clarify why this? I don't understand why
hi,
On 10/19/2011 7:33 PM, Maoke wrote:
..
a single value over the domain or possible variable among
different shared IPv4 addresses? (to my understanding, one
address should have a common value of PSID length for all
the CEs sharing the address, right?)
hi,
On 10/19/2011 10:00 AM, Maoke wrote:
hi Jacni,
2011/10/19 Jacni Qin ja...@jacni.com mailto:ja...@jacni.com
there is still another issue, the MAX PSID. personally i like the
algorithm of making longest-match for the PSID. however, the
position of the PSID is somehow a problem
hi,
On 10/17/2011 11:59 AM, Maoke wrote:
hi Jacni,
thanks a lot for the reply. please see inline.
2011/10/17 Jacni Qin ja...@jacni.com mailto:ja...@jacni.com
hi,
Let me try to answer your questions, please see below,
On 10/15/2011 10:14 AM, Maoke wrote:
hi Remi and all
hi
On 10/17/2011 8:26 PM, c-...@bb.softbank.co.jp wrote:
Hi,
This is my command in line.
therefore my answer to Q1, is NO, unless we carefully select
IPv4 addresses for CEs with giving up to use some of them, which
have been so precious.
Q2. then it must fine as long as we
hi,
On 10/18/2011 10:28 AM, Maoke wrote:
...
the consensus is keeping the exclusiveness of IPv4 address blocks in
IPv6. therefore, i understand the logic of address planning for CEs in
4rd could be the following 4 steps:
1) list all mutually exclusive IPv4 networks to be involved in the
hi,
Let me try to answer your questions, please see below,
On 10/15/2011 10:14 AM, Maoke wrote:
hi Remi and all,
a discussion on the address mapping in -01.txt, trying to fully
understand the design. comments are requested.
- what if there are two rules?
suppose we have 192.32../12
Hi,
On 10/15/2011 10:35 AM, Maoke wrote:
errata:
2011/10/15 Maoke fib...@gmail.com mailto:fib...@gmail.com
Q2. then it must fine as long as we map them to different Rule
IPv6 Prefix. (?)
suppose CE1 is the same as (1). for 64.32../16, we use a
longer stuff.
Hi,
On 10/13/2011 1:43 PM, Satoru Matsushima wrote:
Hi Remi,
It seems far from to be unified _packet_ format. it doesn't support diff-serv
tunneling model, pipe and short-pipe.
The type of service can be copied to the IPv6 header. Sorry, what are
the pipe and short-pipe?
Cheers,
Jacni
Re-,
Yes maybe, to some extent. If accepted, the address format, even for
CE-BR is unified as well.
Cheers,
Jacni
On 10/13/2011 1:03 AM, Behcet Sarikaya wrote:
This is interesting proposal in favor of double translation.
Regards,
Behcet
On Wed, Oct 12, 2011 at 4:56 AM, Rémi Després
hi Remi,
On 10/10/2011 3:26 PM, Rémi Després wrote:
...
The 4rd function examines ALL packets that reach the CE.
It processes all those that have V in their destination addresses, and
only those.
This is a big change to the current forwarding behavior of CPE devices,
doable, but quite
hi,
One comment on the example you proposed, please see below,
On 10/9/2011 7:30 PM, GangChen wrote:
...
I'm not sure what formula you have to deduce this *requirement*.
Different sharing ratios should implicitly be expressed by different
IPv6 prefix lengths when an operator would deploy PD.
hi,
Inline please,
On 10/6/2011 10:03 PM, Ole Troan wrote:
i couldn't understand why we don't see such limitation in 4v6 translation.
4via6 translate the private ipv4 address with 4rd mapping rule while the public ipv4
address with RFC6052 algorithm, right? can the both case work fine if an
On 9/29/2011 2:10 AM, Ole Troan wrote:
In this case, CPE should terminate the packet whose IPv6 destination is matched
to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this
means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd
functionality
CE when forming the IPv6
address of the target CE based on the IPv4 destination address + port.
Cheers,
Jacni
Best Regards,
Leaf
*发件人:* Jacni Qin [ja...@jacni.com]
*发送时间:* 2011年9月26日 7:17
*到:* Leaf yeh
*Cc:* Rémi
On 9/24/2011 7:01 PM, Leaf yeh wrote:
The following is my quick comments questions on the new updated draft.
https://datatracker.ietf.org/doc/draft-despres-softwire-4rd-addmapping/?include_text=1
Section 6
...Its CE IPv6 prefix, Rule IPv6 prefix, and Rule
IPv4 prefix, are supposed
Hi Med,
More inline please,
On 9/7/2011 1:22 PM, mohamed.boucad...@orange-ftgroup.com wrote:
*) Is the focus of the document (properties used) on the whole address
architecture/format, or just on the algorithms to build port sets? As
in some proposals, for example 4rd, the port indexing
Re-,
On 9/7/2011 11:03 PM, Rémi Després wrote:
Hi Satoru-san, Tetsuya-san,
As you have seen, I-D.despres-4rd-addmapping includes for the first time an explanation
about use cases of the Domain IPv6 suffix (sec 5.5 titled The CPE cascade
option).
As originators of the need for this option,
hi Med, all,
Thanks for writing this, it helps.
A couple of quick comments below,
*) Is the focus of the document (properties used) on the whole address
architecture/format, or just on the algorithms to build port sets? As
in some proposals, for example 4rd, the port indexing algorithm can
hi,
On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In
section 5.1, it says, “It is possible that a packetization layer, perhaps
a UDP application outside the kernel, is
hi,
On Fri, Aug 26, 2011 at 10:31 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Bonjour Med,
Thank you for your comments.
What Yiu said is not reflected in figure 3. In the current figure, mAFTR
can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6
network is layer 2
Hi,
On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Hi all,
In section 6.3, To avoid fragmentation, a
service provider may increase the MTU size by 40 bytes on the IPv6
network or mAFTR and mB4 may use IPv6 Path MTU discovery.
How to use IPv6 Path MTU
On Thu, Aug 25, 2011 at 3:16 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
...
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
so mB4 could not determine whether to de-capsulate the packets only based on
mPrefix64 and uPrefix64. Propose to
Thanks for the comments, inline please.
On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast
sit together to discuss and compromise. So we did.
Here are some comments on
hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast
solutions, e.g., potential collocation or reuse of functions? Do
hi,
On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
...
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
so mB4 could not determine whether to de-capsulate the packets only based on
mPrefix64 and uPrefix64. Propose to
Re-,
On 8/22/2011 1:02 PM, Qiong wrote:
Hi,
I support to adopt all.
+1
Cheers,
Jacni
Qiong Sun
On Sat, Aug 20, 2011 at 10:21 PM, Yong Cui cuiy...@tsinghua.edu.cn
mailto:cuiy...@tsinghua.edu.cn wrote:
Hi folks,
Following our rough concensus during Quebec City meeting and
.
Cheers,
Jacni
Thanks,
washam
2011/8/17 Rémi Desprésdespres.r...@laposte.net:
Le 17 août 2011 à 03:10, Jacni Qin a écrit :
hi Remi,
On 8/16/2011 4:27 PM, Rémi Després wrote:
...
As already discussed privately, I don't know realistic cases where two rules
would have IPv6 or IPv4 overlapping
Hi,
On 8/16/2011 11:03 PM, mohamed.boucad...@orange-ftgroup.com wrote:
...
As for the content of the next iteration of the document, we have two options
so far:
(1) Put back some sections which have been removed in -02, add a new section to
discuss dynamic vs. static, handle the comments
hi,
If I understand it correctly, a per user address/port mapping table is
maintained on the LW AFTR, then no session table on it.
Cheers,
Jacni
On 8/9/2011 9:11 AM, Lee, Yiu wrote:
Hi Qiong,
I see your point. So what is the difference between a lightweight AFTR
and 4rd BR?
Cheers,
Yiu
for all users in the same domain (4rd BR case) and
group rule or user specific rule for different users (LW AFTR)?
From: Jacni Qin ja...@jacni.com mailto:ja...@jacni.com
Date: Tue, 9 Aug 2011 09:23:36 +0800
To: Yiu L. LEE yiu_...@cable.comcast.com
mailto:yiu_...@cable.comcast.com
Cc: Qiong bingxu
Re-,
On 8/8/2011 9:18 AM, Jiangsheng wrote:
The best would be the week before BBF in Beijing, say Sep 18, 19. I would like
to inform everyone that the week starting from Oct 1st is the golden holiday
week in China, and hundred million people will travel the weeks before and
after. So the
hi,
On 8/3/2011 10:59 PM, Rémi Després wrote:
...
Thousands of rules seems to me a lot.
(I keep doubts that, if CE's support statically shared addresses,
keeping thousands of IPv4 prefixes would be needed to support IPv4 via
IPv6.)
In any case, this can be among factors that differentiate
hi Jan,
On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote:
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing information for prefixes but forwarding plane is
Hi Simon,
On 8/1/2011 10:45 PM, Simon Perreault wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in port-set/range, end
user can exhaust them.
The fact that most ISPs have been successfully operating with 65536 ports per
hi Remi,
On Thu, Jul 28, 2011 at 9:37 PM, Rémi Després despres.r...@laposte.netwrote:
Hi, all,
How to use the 4rd stateless address mapping to support, in a provider
network having multiple IPv4 prefixes, both exclusive and shared IPv4
addresses, is an typical question.
Jacni: Yes, it is.
hi Remi,
On Wed, Jul 20, 2011 at 3:28 PM, Rémi Després despres.r...@laposte.netwrote:
Le 19 juil. 2011 à 21:18, Tetsuya Murakami a écrit :
Hi Remi,
In terms of 4via6 translation, 4via6 CE can process the received IPv6
packets if the IPv6 destination address is the tunnel end-point
Hi Remi,
Thanks, inline please,
On Wed, Jul 20, 2011 at 5:45 PM, Rémi Després despres.r...@laposte.netwrote:
Hi, Jacni,
...
In addition to Satoru's answer, an ISP that has many IPv4 prefixes can:
- use only a few, or even only one, of its shortest IPv4 prefixes, and
- use IPv4 address
hi Mark,
On Wed, Jul 20, 2011 at 12:16 AM, Mark Townsley m...@townsley.net wrote:
On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote:
The schedule is obviously rather busy. Here's a suggestion: Softwires
has 30
minutes of Multicast transition presentation, while we have an entire
hi Chairs,
We'd like to present the DS-Lite Multicast draft,
Presenter: Yiu Lee
Draft: Multicast Extensions to DS-Lite
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04
Cheers,
Jacni
On Thu, Jul 7, 2011 at 9:37 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi guys,
If you
On Thu, May 26, 2011 at 4:36 PM, Ole Troan otr...@employees.org wrote:
I like the draft and I think it covers the motivational points well.
as a general comment, I do think the document is too wordy. could the
authors make the next revision terser or do you want me to propose text
changes?
Re-,
Just to confirm it, only 4-4 and 6-6 are covered, no 4-6, right?
Cheers,
Jacni
On Tue, May 10, 2011 at 2:27 PM, Satoru Matsushima
satoru.matsush...@gmail.com wrote:
Remi-san has simply pointed out that the service use case section of the
draft assumes same implication in the ds-lite
Dear Authors,
A quick question,
I read 2.1 and the section 6 of 2.2, It seems that, for the multicast data
traffic, the IPv6 multicast packets are translated to native IPv4 packets on
BR then translated back on 6rd CE?
Or they are encapsulated over IPv4 and de-capsulated on 6rd CE?
Cheers,
-multicast-01.txt has been
successfully submitted by Jacni Qin and posted to the IETF repository.
Filename:draft-qin-softwire-dslite-multicast
Revision:01
Title: Multicast Extensions to DS-Lite in Broadband Deployments
Creation_date: 2010-10-25
WG ID
Dear Alain David,
We'd like to have a slot for
Document:draft-qin-softwire-dslite-multicast-00
Time: 10 mins
http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-00
Thanks,
Jacni
On Fri, Oct 15, 2010 at 7:31 AM, Alain Durand adur...@juniper.net wrote:
This is a call for agenda
with Alain to clarify the text. Thanks for the comments!
On 5/30/10 3:57 AM, Jacni Qin jac...@gmail.com wrote:
i agree with you that dns proxy over v6 in B4 should be preferred,
while we should mention this special case in the draft, because this will
be not so special
if many hosts running
, currently there is no option defined for
passing the v4 DNS server address to hosts.
and for the DNS proxy case, do you mean if the OS doesn't support DNS
request over v6, we should then provider a patch for this function along
with the B4 implementation?
thanks,
On 5/26/10 12:47 PM, Jacni Qin
72 matches
Mail list logo
