Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
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 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: 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, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. I think I agree with the above. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. This is all I've been asking for. An update to abstract/introduction to indicate that it is a generic solution. And then say that DS-Lite is one of the use-cases. You can even say that the solution was developed to solve the problem for DS-Lite. All I want is to make it clear that it is a generic solution. Stig Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
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; softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: 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, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. These are religious arguments. Translation multicast integrates well with several IPv6 transition technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. Let's use translation multicast with those technologies. No matter what you want to believe, DS-Lite is a tunneling technology. Why do you think DS-Lite was standardized in Softwires WG? Same thing with 6rd. Remember softwire means tunnel. Translation has only been added to Softwires WG recently after Behave WG stopped working on it. Med: I failed to get the point you are trying to make. Do you want draft-ietf-softwire-dslite-multicast to cover the translation case also? Let me remind that draft-ietf-softwire-dslite-multicast covers only the encapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IETF84 - MAP Interop event
Hi All, small update: After an on0site visit it's been determined that we'll relocate the MAP interop to room Plaza-C Regards, Woj. On 29 July 2012 11:38, Wojciech Dec wdec.i...@gmail.com wrote: Hi All, small update regarding the location of the MAP Interop event: We'll be making use of the IETF Terminal room. We're have indication that 5 implementations will be tested. We'll be documenting the results. Regards, Woj. On 24 July 2012 17:51, Wojciech Dec wdec.i...@gmail.com wrote: Hello All, at the upcoming IETF84 meeting we'll be holding a first open MAP Interop event to which we would like to cordially invite any implementers implementations of MAP, besides of course interested WG members. The goal of the event will be to verify basic MAP CE-BR communication use-cases, covering both -T and -E. We currently anticipate a number of different implementations to participate. The Interop will commence on Tuesday 31, 2012 starting at 1300. The exact room/location will be communicated shortly. An ethernet switch Internet connectivity will be provided, but for the rest please bring your own MAP device(s) and any end-host devices that can help with the testing. Given that the set-up activities are likely to commence earlier, please let us know (by unicast) if you'd be available to participate or help in such preparations. Regards, Woj. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
On Mon, Jul 30, 2012 at 7:04 AM, mohamed.boucad...@orange.com wrote: 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; softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: 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, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. These are religious arguments. Translation multicast integrates well with several IPv6 transition technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. Let's use translation multicast with those technologies. No matter what you want to believe, DS-Lite is a tunneling technology. Why do you think DS-Lite was standardized in Softwires WG? Same thing with 6rd. Remember softwire means tunnel. Translation has only been added to Softwires WG recently after Behave WG stopped working on it. Med: I failed to get the point you are trying to make. Do you want draft-ietf-softwire-dslite-multicast to cover the translation case also? Really? Take a look at Fig. 1, IGMP Report (join) received at so-called mB4 becomes MLD Report sent upstream. How is this encapsulation? Let me remind that draft-ietf-softwire-dslite-multicast covers only the encapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones. You are talking about multicast data, and it is curious why you are doing it? Anyway, what I want is clear: draft-sarikaya-softwire-dslitemulticast-01.txt is the solution that integrates with DS-Lite and that is the solution we need :-). Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] draft-hu-softwire-multicast-radius-ext-01
Hi, All Here, we've updated the multicast radius attribute drafts. In the draft, we use many terminology “DS-Lite Multicast”, after [I-D.ietf-softwire-dslite-multicast] updates according to the mailing list , we'll update the abstract and introduction in our draft. Any comment is welcome , thanks. Wang. A new version of I-D, draft-hu-softwire-multicast-radius-ext-01.txt has been successfully submitted by Cui Wang and posted to the IETF repository. Filename: draft-hu-softwire-multicast-radius-ext Revision: 01 Title:RADIUS Extensions for DS-Lite Multicast Creation date:2012-07-13 WG ID:Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-hu-softwire-multicast-radius-ext-01.txt Status: http://datatracker.ietf.org/doc/draft-hu-softwire-multicast-radius-ext Htmlized: http://tools.ietf.org/html/draft-hu-softwire-multicast-radius-ext-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-hu-softwire-multicast-radius-ext-01 Abstract: DS-Lite Multicast [I-D.ietf-softwire-dslite-multicast] is a solution to offer multicast service on DS-lite circumstance. DS-Lite Multicast requires pre-configuration of the IPv4-embedded IPv6 prefixes information on the multicast Basic Bridging BroadBand (mB4) element and multicast Address Family Translation Router(mAFTR). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the DS-Lite multicast prefixes information; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_PREFIX64 option. The IETF Secretariat ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
