Re: [Softwires] [EXTERNAL] Re: ISP CGN logging inc. Destination ??

2018 at 5:42 PM To: "ramesh.r.chan...@ril.com" <ramesh.r.chan...@ril.com>, "Lee, Yiu" <yiu_...@cable.comcast.com> Cc: "ianfar...@gmx.com" <ianfar...@gmx.com>, "softwires@ietf.org" <softwires@ietf.org>, "int-a...@ietf.org" &l

Re: [Softwires] [EXTERNAL] RE: Re: ISP CGN logging inc. Destination ??

this is not a "native" feature of a BR/lwAFTR. > > Cheers, > Med > >> -Message d'origine- >> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Lee, Yiu >> Envoyé : lundi 7 mai 2018 13:16 >> À : ramesh.r.chan...@ril.com >> Cc

Re: [Softwires] [EXTERNAL] Re: ISP CGN logging inc. Destination ??

Just a quick thought. Will the dhcpv6 logs help? Sent from mobile device, pardon possible typo. > On May 7, 2018, at 7:06 AM, "ramesh.r.chan...@ril.com" > wrote: > > Dear Ian, thanks for clarifications. > > Regulator in India mandated to preserve the following

Re: [Softwires] Call for Adoption on draft-liu-softwire-lw4over6-dynamic-provisioning-02

I am one of the co-authors of this draft. I think it makes sense to have a document to describe the lw4o6 deployment model. I support to adopt it. On 11/16/16, 8:09 AM, "Softwires on behalf of Yong Cui" wrote: Hi folks,

Re: [Softwires] PLEASE READ - IPR Disclosure question on draft-ietf-softwire-dslite-multicast - Respond by 18/10/16

I support to move forward. From: "mohamed.boucad...@orange.com" Date: Tuesday, October 4, 2016 at 3:45 AM To: Ian Farrer , softwires Cc: "draft-ietf-softwire-dslite-multic...@ietf.org"

Re: [Softwires] Working group last call for draft-ietf-softwire-mesh-mib-07

Support to move forward. Cheers, Yiu On 1/20/15, 7:26 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 describing the Softwire Mesh MIB as a Standards Track RFC. The authors believe that

Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07

I support this draft to move forward. Regards, Yiu On 1/21/15, 7:05 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote: Hi folks, This message starts a two week softwire working group last call on advancing the draft of DS-Lite MIB as a Standards Track RFC. After we had the first wglc on

Re: [Softwires] Comments on 6rd and MAP Multicast

Hi Behcet, Sorry for the late reply. I didn¹t suggest to drop anything. Instead, I just had a question: If the encapsulation method encapsulated v6 multicast packets in v4 unicast packets, it might not be the best use of v6 multicast. Thanks, Yiu On 7/24/14, 6:08 PM, Behcet Sarikaya

Re: [Softwires] Proposed text that describes lw4o6 and map-e

I don¹t understand his point. Let¹s put the 1:1 aside, MAP-E requires IPv4 rule to algorithmically build the CE IPv6 prefix. In lw4o6 Section 5.1, we simple put the v4 in the IID. Isn¹t it obviously there is no v4/v6 dependency? What Woj tries to argue? I lost. Can somebody explain to me please?

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

I still have problem to include text to compare two methods. Why not remove the whole sentence as Ole stated in his email? Yiu From: Ian Farrer ianfar...@gmx.com Date: Thursday, March 6, 2014 at 11:27 AM To: Wojciech Dec wdec.i...@gmail.com Cc: Softwires-wg WG softwires@ietf.org Subject:

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Ole, A clarification question. Do you suggest to use S46 Rule Option? Thanks, Yiu On 3/6/14, 1:37 PM, Ole Troan otr...@employees.org wrote: Ian, It really depends on what you mean by 'the wheel' in this contextŠ But, as a proposal, if we extend (and maybe rename) OPTION_L46_IPV4ADDRESS

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

...@gmail.com Date: Thursday, March 6, 2014 at 6:27 PM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires-wg WG softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote: I still have

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires-wg softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt On 3 March 2014 17:57, Lee, Yiu yiu_...@cable.comcast.com wrote: How MAP-E aggregates CPE for N CEs in hub-and-spoke? When implementing MAP

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Sorry for my ignorance. How MAP-E optimizes states In hub-and-spoke mode compared to lw4o6? From: Wojciech Dec wdec.i...@gmail.com Date: Monday, March 3, 2014 at 1:47 PM To: ian.far...@telekom.de ian.far...@telekom.de Cc: Softwires-wg softwires@ietf.org Subject: Re: [Softwires] I-D Action:

Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05

support On 2/14/14, 12:49 AM, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi all, This message starts a two week softwire working group last call on advancing the draft about providing Mapping of Address and Port using Translation as an Experimental RFC. The authors believe that this

Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07

support On 2/14/14, 12:52 AM, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi all, This message starts a two week softwire working group last call on advancing the draft about IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd) as an Experimental RFC. The authors believe

Re: [Softwires] Changes to DHCP MAP Option draft

in the wg. Does that work for you? Thanks Suresh On 07/15/2013 12:48 PM, Lee, Yiu wrote: Woj, I am not objecting it. I just stated the new draft has been updated the scope w/o getting explicit consent from the ML. BR, Yiu From: Wojciech Dec wdec.i...@gmail.com mailto:wdec.i...@gmail.com

Re: [Softwires] Changes to DHCP MAP Option draft

Since this is a WG draft, did the authors ask the WG to update this? When the WG accepted this draft, it was only for MAP. But seems the scope has been changed. This should start as an Individual draft. I will recommend to revert back to the last version and present this in Berlin to replace the

Re: [Softwires] Changes to DHCP MAP Option draft

place, and naturally will also be held in Berlin. Re-spinning draft versions is easy. On 15 July 2013 17:29, Lee, Yiu yiu_...@cable.comcast.com wrote: Since this is a WG draft, did the authors ask the WG to update this? When the WG accepted this draft, it was only for MAP. But seems the scope

Re: [Softwires] Call for agenda in IETF 87

Hi Chairs, We would like to ask for 10 min slot to present the Lightweight 4over6 Failover draft. Thanks, Yiu From: Yong Cui cuiy...@tsinghua.edu.cn Date: Tuesday, July 9, 2013 6:54 AM To: Softwires WG softwires@ietf.org Cc: Yong Cui cuiy...@tsinghua.edu.cn Subject: [Softwires] Call for

Re: [Softwires] Working group last call for draft-ietf-softwire-dslite-mib-02

+1 which is needed for dslite On 5/24/13 12:21 AM, 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 DS-Lite MIB as a Standards Track RFC. The authors believe that this version has

Re: [Softwires] Call for adoption of draft-fu-softwire-map-mib-05 as wg draft

+1 supported On 5/24/13 12:07 AM, 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 draft. Please state whether or not you're in favor of the

Re: [Softwires] Working group last call for draft-ietf-softwire-mesh-mib-03

+1 supported On 5/24/13 12:18 AM, 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 as a Standards Track RFC. The authors believe that this version has addressed all

Re: [Softwires] Call for adoption of draft-jiang-softwire-map-radius-04 as wg draft

Support On 5/24/13 12:09 AM, 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-jiang-softwire-map-radius-04 as a softwire WG draft. Please state whether or not you're in favor of the

Re: [Softwires] [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6

Med, I agree we can talk more motivations in the draft. However, draft-scskf-dhc-dhcpv4-over-dhcpv6 discusses a generic specification of DHCPv4 over DHCPv6. I am not sure what we want to mention specific to MAP or lw4over6 in this draft. Thanks, Yiu On 4/15/13 11:52 AM,

Re: [Softwires] Call for confirming the adoption of draft-cui-softwire-b4-translated-ds-lite-11 as WG item

+1 On 3/19/13 1:13 PM, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi all, This draft was presented during the softwire WG meeting at IETF86 and a subsequent poll of the room indicated that there was strong support for adopting this draft as a WG document. This call is being initiated

Re: [Softwires] map-deployment-01 draft

+1. Adding an example will definitely help. From: Maoke fib...@gmail.com Date: Friday, March 15, 2013 8:45 PM To: Poscic, Kristian (Kristian) kristian.pos...@alcatel-lucent.com Cc: softwires@ietf.org softwires@ietf.org Subject: Re: [Softwires] map-deployment-01 draft hi Kristian, thanks

[Softwires] #21: Fragmentation must not be handled according to RFC 2473

I was tasked in IETF-85 to find out why mss rewrite was removed before publishing RFC6333. Here is my finding: Back in 2009-4-7, people in ML reported rewriting MSS would break TCP-AO if TCP option flag set to 0. In IETF-75, Dave Thaler suggested to delete mss rewrite from the draft. The argument

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-08.txt

This version addressed the comments addressed by Robert Sparks and Stephen Farrell. I do have a question for the WG. In 07 Section 2.4, we use user to indicate the user behind the B4 element. However, Stephen suggested this wasn't clear because we could have multiple users/devices behind a B4

Re: [Softwires] MAP-E 1:1 for HA

:1 be part of a stateless solution. MAP-E 1:1 looks a stateful solution to me. On 11/10/12 1:34 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a deployment choice. Cheers, Rajiv -Original Message- From: Lee, Yiu

Re: [Softwires] MAP-E 1:1 for HA

Ole, From my perspective, the argument is not whether two protocols are identical or not. I found MAP-E 1:1 is a stateful solution. I found it odd to make it part of MAP-E which was originally decided a stateless solution. Regards, Yiu On 11/11/12 8:11 AM, Ole Trøan otr...@employees.org wrote:

[Softwires] MAP-E 1:1 for HA

I have a question for the HA design concept of MAP-E 1:1. The central theme of MAP-E is to make BR as stateless as possible and use Anycast address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the operator must have to pre-provision all the subscribe rules to all the BRs sharing

Re: [Softwires] Gen-ART review of draft-ietf-softwire-dslite-deployment-06

: Lee, Yiu [mailto:yiu_...@cable.comcast.com] Sent: Wednesday, October 17, 2012 8:46 PM To: Black, David; roberta.magli...@telecomitalia.it; ca...@mcsr-labs.org; christian.jacque...@orange.com; mohamed.boucad...@orange.com; gen-...@ietf.org Cc: softwires@ietf.org; i...@ietf.org; Ralph Droms Subject

Re: [Softwires] Gen-ART review of draft-ietf-softwire-dslite-deployment-06

Hi David, Thanks very much for review the draft. Comments inline. Thanks, Yiu On 10/15/12 7:10 PM, Black, David david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

Re: [Softwires] Confirming way forward with MAP-T and 4rd

+1 Favor of both On 9/25/12 8:01 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Favor of both. When will the opportunity be to change from experimental to standards? and what will it take ? Thanks. Cheers, Rajiv Sent from my Phone On Sep 25, 2012, at 12:45 AM, Suresh Krishnan

Re: [Softwires] draft-ietf-softwire-dslite-multicast-03

Hi Stig, Agree we should review this in mboned. We will send a separate message to mboned for review. Thanks very much for all your comments. Thanks, Yiu On 8/23/12 1:45 PM, Stig Venaas s...@venaas.com wrote: On 8/23/2012 7:54 AM, mohamed.boucad...@orange.com wrote: Dear all, A new version

Re: [Softwires] map-00: review on the mode 1:1

27, 2012 8:06 AM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Ole Trøan otr...@employees.org, Softwires-wg softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu yiu_...@cable.comcast.com wrote: Ole, IMHO the WG will need to decide whether

Re: [Softwires] map-00: review on the mode 1:1

Woj, I got a general question. The current MAP support 1:1 mode where EA-bit is a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something? Thanks, Yiu From:

Re: [Softwires] map-00: review on the mode 1:1

Ole, I am not asking whether MAP supports 1:1 mode with no EA bits or not. I am asking MAP allows to embed the 32-bit address in the EA bits to achieve 1:1 mode: The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set

Re: [Softwires] map-00: review on the mode 1:1

Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0)

Re: [Softwires] map-00: review on the mode 1:1

to see why we want to include this in the base spec. Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4

Re: [Softwires] [v6ops] DS-Lite DNS

Since the DNS server at home only manages its own dns-domain, the dns-server should still use the CPE's IP for external dns query. If user decides not to use the CPE's IP, all dns packets would use the tunnel. If an operator wants to block this, in theory this will require implementing ACL to

Re: [Softwires] map-00: review on the mode 1:1

Hi Woj and Satoru, Thanks for spending time to explain MAP to the ML. It really helps to understand it better. Thanks I concur with Maoke's analysis. If the 1:1 mode means giving the CE a complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e. EA-bit=0 and r = 32) , this is what

Re: [Softwires] map-00: review on the mode 1:1

I didn't check there was a newer version. My bad. On 6/28/12 9:28 AM, Tomek Mrugalski tomasz.mrugal...@gmail.com wrote: On 28.06.2012 14:17, Lee, Yiu wrote: Hi Woj and Satoru, Thanks for spending time to explain MAP to the ML. It really helps to understand it better. Thanks I concur

Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

Hi Shailesh, Thanks very much of reviewing the draft. Please read comments inline: On 6/26/12 8:07 AM, Shailesh Suman sumanshail...@gmail.com wrote: Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop

Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Dear Satoru, I do not understand how to create per-subscriber mapping in a stateless manner. In the end, the BR must contain all mapping rules for all 1:1 subscribers. This is stateful to my understanding. Could you please explain how not to maintain any mapping rule in BR to achieve this?

Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Hi Satoru, To me, this changes the stateless operation model. I respectfully disagree your statement Nothing changed. Regards, Yiu On 6/24/12 11:47 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: This could be same operation with any other, configure FMRs into a map tunnel. Nothing

Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt

- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document

Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

Hi Woj, Let me try to answer some of your questions: From: Wojciech Dec wdec.i...@gmail.com Date: Thursday, June 14, 2012 9:07 AM To: Peng Wu pengwu@gmail.com Cc: softwires@ietf.org softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn Subject: Re: [Softwires] WG last call on

Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt

I prefer Tom suggestion. It is typical to have a NAT but not a must or should. On 6/13/12 12:38 PM, liu dapeng maxpass...@gmail.com wrote: I can change may to should to please you but it really does make sense. = thanks smime.p7s Description: S/MIME cryptographic signature

Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

Hi Behect, You confuse me. 4.3 said this: When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source

Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

+1 On 6/12/12 4:46 PM, Stig Venaas s...@venaas.com wrote: On 6/12/2012 1:11 PM, Behcet Sarikaya wrote: I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not

Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward 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

Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

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? On 4/26/12 10:50 AM, Jan Zorz @ go6.si j...@go6.si wrote: On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan

Re: [Softwires] Mailing list question to gauge consensus on 4rd-U vs MAP

= Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a whole) on the standard track, the other being published as experimental or informational. Answering YES to this question means you agree we cannot publish

Re: [Softwires] Provisioning Hub-and-spoke in MAP - How?

Hi Remi, I think Woj has answered the question that MAP-E will require explicit provision. He may not answer very clearly YES or NO, but saying it is durable. IMNO, explicit or implicit is very critical. Implicit is definitely better but it isn't a real concern if we have to provision a

Re: [Softwires] Provisioning Hub-and-spoke in MAP - How?

I didn't mean to send this to the ML. I still don't know why it did. I apologize if it offends anybody. Anyway, my position reminds the same. I would like to work with others to improve technology, not arguing for the sake of arguing. Yiu On 4/10/12 8:02 PM, Lee, Yiu yiu_...@cable.comcast.com

Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

Dear Maoke, Comments inline: From: Maoke fib...@gmail.com Date: Mon, 9 Apr 2012 07:24:30 + To: Sheng Jiang jiangsh...@huawei.com Cc: Yiu L. LEE yiu_...@cable.comcast.com, Liubing (Leo) leo.liub...@huawei.com, Simon Perreault simon.perrea...@viagenie.ca, softwires@ietf.org

Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

I am sorry, the two drafts should be RFC4447 and RFC4761. My mistake. From: Yiu L. LEE yiu_...@cable.comcast.com Date: Mon, 9 Apr 2012 22:45:50 + To: Maoke fib...@gmail.com, Sheng Jiang jiangsh...@huawei.com Cc: softwires@ietf.org softwires@ietf.org Subject: Re: [Softwires] Path to move

Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

I am sorry flooding the mailing list. Rajiv is kind to remind me I am wrong. RFC4761/4762 are meant for VPLS. According to this link http://www.networkers-online.com/blog/2009/01/draft-martini-draft-kompella-a nd-l2vpn-services/, draft-martini was published as RFC4906 (Categorized as Historic).

Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent as MAP-E

I also followed the discussion. I appreciate both teams bought up the technical details for both designs. To be honest, I fail to see which one is better than other (yet). I like the fact that 4rd-u can do what MAP-T does w/o introducing any encap overhead. But I understand the concerns others

Re: [Softwires] Path to move forward with 4rdŠ

Hi Guanghui, Just curious, how common IPv4 option is used these days? I don't have any data in-hand. Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Fri, 23 Mar 2012 13:43:07 +0800 To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires WG softwires@ietf.org Subject: Re:

Re: [Softwires] Path to move forward with 4rdŠ

Hi Guanghui, Is the original use case for MAP is to deliver v4 over v6 in a stateless fashion in the network? This is stated in the stateless-requirements draft. If we can get v4-v6 (single translation) for free, I am all for it. But this isn't the original requirements we are trying to solve.

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt

Good feed back. We started to address dslite and like what you said this could be more generic then just dslite. I will talk to the authors and see what we should do. Thanks again! On 3/23/12 1:02 PM, Stig Venaas s...@venaas.com wrote: On 3/22/2012 7:29 PM, Lee, Yiu wrote: Hi Stig, DS-Lite

Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT

Hi Alain, Quick question. What snag suggests to keep in the customer database? Port range info? Thanks, Yiu On 3/23/12 10:06 AM, Alain Durand adur...@juniper.net wrote: Not necessarily. Operators maintain large database for customers, this is just one more field there. The real question is how

Re: [Softwires] Path to move forward with 4rd

Hi Wjociech, So the only different between MAP-T and dIVI-PD is the new PSID calculation in MAP. Otherwise, they are identical. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 14:01:59 +0100 To: Reinaldo Penno repe...@cisco.com Cc: Softwires WG softwires@ietf.org

Re: [Softwires] Path to move forward with 4rdŠ

Hi Ole, Technically, I think it now comes down to one question to debate between MAP-T and 4rd-u. Btw reservable header and double-translation, what technology better serves the requirements. Do you agree? Thanks, Yiu On 3/23/12 5:28 AM, Ole Trøan otr...@employees.org wrote: Remi, who was

Re: [Softwires] Path to move forward with 4rdŠ

Hi Guanghui, I agree that both MAP and 4rd-u are similar technology and solving the same problem. From technical perspective, can you elaborate this a lithe bit? Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Thu, 22 Mar 2012 20:26:40 +0800 To: Softwires WG softwires@ietf.org

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt

Hi Stig, DS-Lite was designed to deliver v4 unicast packets over v6-only network to v4 host. However when we started thinking about how to deliver multicast packets in the same network setup, we will have to tunnel all multicast packets over tunnels. This is very inefficient to use of AFTR. This

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt

One more note. When we developed this draft, we focused on access network delivery. There is a mesh-multicast draft which also solve the same problem (i.e. Tunneling v4 mcast through v6-only network) in the core network. On 3/22/12 10:29 PM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Stig

Re: [Softwires] Path to move forward with 4rdŠ

packets on the Internet, which are not compatible with existing IPv6 packets and no existing devices can understand those packets. Yu Guanghui ygh at dlut.edu.cn http://dlut.edu.cn Network and Information Center Dalian University of Technology, China On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu

Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite

Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. On 3/20/12 9:06 AM, Alain Durand adur...@juniper.net wrote:

Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

Hi Maoke and Remi, Thanks very much for discussing this issue on the mailing-list. I guess the points are now clear for both options. IMHO, there is no one better than the other, it is all about choice of implementation. Perhaps it is time for more people to comment how they feel for both

Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite

I am a little lost. Let's put the double-nat aside for a moment. Except the fact that sd-nat uses icmp for port-set provisioning, what else different between Lightweight 4over6 vs. sd-nat? Am I missing something? For Lightweight 4over6, we can use anycast for redundancy. I fail to see what sd-nat

Re: [Softwires] Stateless implementation plan

+1 On 2/8/12 7:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: IOW, if CE is able to get native IPv6 anyway for MAP, then anything non-native IPv6 would have no usage. ___ Softwires mailing list Softwires@ietf.org

Re: [Softwires] Stateless implementation plan

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 is asking for trouble. Cheers, /Yiu On 2/8/12 2:13 AM, Rémi Després remi.desp...@free.fr wrote: 6rd

Re: [Softwires] Stateless implementation plan

May I ask a question. Why will people deploy MAP over another tunnel schema such as 6rd? On 2/7/12 1:27 PM, Tina TSOU tina.tsou.zout...@huawei.com wrote: Now if they have to deploy MAP over this for 4over6 traversal, is MAP always independent of whether 6to4 was used or 6rd used.because the

Re: [Softwires] 答复: Stateless implementation plan

[mailto:softwires-boun...@ietf.org] 代表 Lee, Yiu 发送时间: 2012年2月8日 10:37 收件人: Tina TSOU; Rajiv Asati (rajiva) 抄送: softwires@ietf.org 主题: Re: [Softwires] Stateless implementation plan May I ask a question. Why will people deploy MAP over another tunnel schema such as 6rd? On 2/7/12 1:27 PM, Tina

Re: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt

Hi Shishio, Thanks for sharing this. I am glad but not surprised to see the result because free.fr has shown to scale 6rd to millions of their users since few years ago. Yiu On Feb 8, 2012, at 0:17, Shishio Tsuchiya shtsu...@cisco.com wrote: v6ops and ARMD Sakura internet are providing IPv6

Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option

I support to adopt this draft. On 2/5/12 7:57 PM, Yong Cui cuiy...@tsinghua.edu.cn wrote: Dear Softwires wg, As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in Taipei meeting, the chairs would like to ask for WG adoption on the mailing list. Please review this document

Re: [Softwires] draft-ietf-softwire-dslite-deployment - review

Hi Maoke, Thanks for the review. We will capture your comments in next revision. Yiu From: Maoke fib...@gmail.commailto:fib...@gmail.com Date: Sat, 19 Nov 2011 23:08:36 +0900 To: draft-ietf-softwire-dslite-deploym...@tools.ietf.orgmailto:draft-ietf-softwire-dslite-deploym...@tools.ietf.org Cc:

[Softwires] DS-lite Multicast Demo

Hi guys, We have the DS-lite Multicast demo running in the Terminal room on 4th Floor. Please come and see!! /Yiu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] draft-ietf-softwire-dslite-deployment

Hi Nejc, Thanks so much for the review. The PDF format works very well. We will make the changes according to your suggestion in the next revision. Thanks, Yiu On 11/14/11 4:15 PM, Nejc Škoberne n...@skoberne.net wrote: Dear authors, I volunteered yesterday at the Softwires IETF 82 meeting to

Re: [Softwires] DS-Lite fragmentation RFC2473 reference

Hi Daniel, Host behind B4 isn't aware he tunnel between B4 and AFTR. To make the host transparent to IPv4 fragmentation, we made the decision to mandate B4 (and AFTR) fragment and reassemble the oversized packet. We agree that there is a price to pay (i.e., CPU intensive operation in B4 and

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-00.txt

No. Our intent is make I standard track document. On Sep 12, 2011, at 6:18 PM, Behcet Sarikaya behcetsarik...@yahoo.com wrote: Status of this draft should be informational, right? Behcet A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a

Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-00.txt

Hi Behcet, Ah. Thanks for the heads-up . This also happened to dslite. It was charted to be informational and when the document proceeded, it beame standard track. I think it depends on how the draft ia being developed. Thanks, Yiu On Sep 12, 2011, at 6:31 PM, Behcet Sarikaya

Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi Tina, To use PMTU in this scenario, this is more complicated than what you explain. First, this traffic flow is from mAFTR to the mB4. In between, there could be more than one IPv6 multicast routers. In our spec, mAFTR will replicate the packet once in the multicast I/F to the IPv6 MDT, can

Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi Tina, Sure can but IPv6 MTU discovery like IPv4 MTU discovery, it is unreliable. We can list it as an option but readers should notice this may not work in all cases. Regards, Yiu On 8/25/11 10:36 PM, Tina TSOU tina.tsou.zout...@huawei.com wrote: Hi all, In section 6.3, To avoid

Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU

Re: [Softwires] Clarification of the stateles/stateful discussion

I also agree this is a very nice piece of work. The current title is Implementing AplusP in the provider's IPv6-only network. I think this not only covers Implementing AplusP in an IPv6-only network, but also captures very important information about the port usage in various applications. I would

Re: [Softwires] Clarification of the stateles/stateful discussion

Hi Satoru, I think you answered your question. As you said, it is possible to use 1 port (in theory) to reach 2000 sessions as long as each destination is different. So given user 256 ports could create a much larger set of NAT sessions in the CGN. Cheers, Yiu On 8/2/11 2:33 AM, Satoru

Re: [Softwires] Clarification of the stateles/stateful discussion

Hi Qiong, I see your point. So what is the difference between a lightweight AFTR and 4rd BR? Cheers, Yiu From: Qiong bingxu...@gmail.commailto:bingxu...@gmail.com Date: Tue, 2 Aug 2011 14:11:55 +0800 To: Yiu L. LEE yiu_...@cable.comcast.commailto:yiu_...@cable.comcast.com Cc: Satoru Matsushima

Re: [Softwires] Clarification of the stateles/stateful discussion

, 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 From

Re: [Softwires] Clarification of the stateles/stateful discussion

@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: Re: [Softwires] Clarification of the stateles/stateful discussion hi Yiu, On 8/9/2011 10:28 AM, Lee, Yiu wrote: Agree that the CE-CE communication will be possible for LW AFTR because the rules are not store

Re: [Softwires] Clarification of the stateles/stateful discussion

Couple thoughts. 1. The current draft doesn't specify the static mapping rule like what 4rd does. So I guess we can't compare this to 4rd. 2. I keep thinking what are the difference of this and PRR. I guess Qiong's PRR definition is the forwarding decision would be done in the FIB. I don't

Re: [Softwires] Softwire Interim meeting

I am speaking for myself. It will be tough for me to go to China in Sept and Taiwan in Nov. On 8/5/11 3:57 PM, Mark Townsley m...@townsley.net wrote: On Aug 5, 2011, at 2:38 PM, Alain Durand wrote: Following-up on the Quebec meeting, we would like to organize an interim meeting end of

Re: [Softwires] Clarification of the stateles/stateful discussion

+1 On 7/30/11 9:26 AM, Peng Wu wea...@csnet1.cs.tsinghua.edu.cn wrote: Hi Gang, Before making such comparison (of course it should be as fair as possible), I think we need to state what solution space we are targeting and what category mode we should take care. If I understand correctly, I

Re: [Softwires] Clarification of the stateles/stateful discussion

You are right. The current 'draft-cui-softwire-host-4over6' describes how a server is provisioned a public IPv4 address over an IPv6-only network. IPv4 address sharing wasn't discussed in the draft. On 7/30/11 9:57 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote: AFAIK, the

Re: [Softwires] Clarification of the stateles/stateful discussion

In this case, http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt couldn't be controversial because it will turn AFTR a PRR. On 8/1/11 7:07 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote: If you imagine dynamic port ranges within stateless, it sounds like port

Re: [Softwires] Clarification of the stateles/stateful discussion

Actually, Orange Lab did some tests on A+P. They published the results in v6ops: http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01 In their tests, bittorrent seems use most ports (200). Other public apps use no more than 100 ports. For a family of 5, I think 2000 ports

  1   2   >