Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
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; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to be added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org, draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org, draft-cui-softwire-b4-translated-ds-lite draft-cui-softwire-b4-translated-ds-l...@tools.ietf.orgmailto:draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo Penno (repenno) repe...@cisco.commailto:repe...@cisco.com, softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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 : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories.
Re: [Softwires] MAP-E 1:1 for HA
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 think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. -- == Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * === ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
dear Med, thanks for the response. please see inline. 2012/11/30 mohamed.boucad...@orange.com ** 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; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org *Objet :* Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks. [maoke] i a little doubt the binding mode is a proper way to unify the MAP 1:1 and lw4over6. because MAP 1:1 is still working in the model of delegation while lw4over6 applies the WAN IPv6 address for the encapsulation. what if the CPE has a delegated prefix at LAN and an address at WAN simultaneously? which address is used for the source address of the tunnel in the binding mode? is the CPE choice fits the reality at the AFTR/BR? to my understanding, the behaviour of MAP 1:1 is identical with any MAP but different from lw4over6 to some extent. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. [maoke ] why only ONE mode MUST be activated? [maoke] we noticed a fact that a domain of softwire, at least MAP, can be different from the domain in the sense of autonomous system, because the model of prefix delegation is totally independent of the deployment of the softwire. this feature makes the softwire domain able to spread over different AS. therefore it is possible that a CPE is involved in a AS's lw4over6 domain and meanwhile also involved in a inter-AS MAP domain. administration of the lw4over6 domain and that of the MAP domain are surely independent to each other but they impact the CPE simultaneously -- it could be treated as a typical case of softwire multi-homing. and we expect the CPE gets the benefits from the multi-homing: policy-based path selection, load-balance, fault-tolerance, etc. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to be added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes. thanks, - maoke P.S. i will be in a 3-nights2-days trip since tonight so any further discussion will be responded in the beginning of next week. sorry in advance for the delay. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.com mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.org
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. B) I disagree that co-existance between Lw4o6 and MAP is a goal; a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. In Section 3 the draft coin a new term/class of solution called Binding approach. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. For a unified solution a functional breakdown in a solution neutral text is essential. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. One can comment further on the details of the draft, but getting the basic functional breakdown is essential (example above) before we get into that. The only thing different between the solutions are not the basic functionalities but rather how this functionality is configured. Regards, Woj.. On 29/11/2012 11:16, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: 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 : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename: draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date: 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP-E 1:1 for HA
And much as was also said before, this categorization is bogus as all solutions need configuration state, ie categorizing solutions based on amount of configuration or some fluffy term like binding approach is equivalent to categorizing them based on how long is a piece of string and ultimately useless. What we do know is one-size of string does not work for all, and the implementers need to scale their configuration state as per their best judgement/capabilities. Cheers, Woj. On 30 November 2012 09:48, Qiong bingxu...@gmail.com wrote: 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 think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. -- == Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * === ___ 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] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
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; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution a functional breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) Med: What does that mean? In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. Med: Isn't that what is captured in Table 3: Supported Features ? +--++-+-+ | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | | Element | tunnel | IPv4 | NAT44 | | |endpoint| | | +--++-+-+ | B4 | Yes | N/A |No | +--++-+-+ | lwB4 | Yes | Yes | Optional| +--++-+-+ | MAP-E CE | Yes | Yes | Optional|
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: 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; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing things. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. You don't need any terminology like binding mode, especially in the CPE spec since the CPE side doesn't care about what configuration is on the concentrator. It only cares about its own configuration and there is no difference Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution a functional breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. Suggestion is to can the myriad of tables and agree to the break down the basic functionality. This then allows us to focus on how it is expected to be configured (the mechanism of configuration) and using what external means (eg IP addresses, DHCP option). IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. Section 3.1 - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an
Re: [Softwires] MAP-E 1:1 for HA
This solution space is the outcome of Vancouver meeting. And IMO, the word 'binding' not only means there are state to maintain, but also indicates that IPv4 and IPv6 addresses are just bound together, with no algorithmic relationship. Thanks, Qi Sun On 2012-11-30, at 下午6:51, Wojciech Dec wrote: And much as was also said before, this categorization is bogus as all solutions need configuration state, ie categorizing solutions based on amount of configuration or some fluffy term like binding approach is equivalent to categorizing them based on how long is a piece of string and ultimately useless. What we do know is one-size of string does not work for all, and the implementers need to scale their configuration state as per their best judgement/capabilities. Cheers, Woj. On 30 November 2012 09:48, Qiong bingxu...@gmail.com wrote: 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 think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. -- == Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: http://sourceforge.net/projects/laft6/ PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ === ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : 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. Here are some: - First, I think this is very positive. I like what I'm reading. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
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: draft-bfmk-softwire-unified-cpe Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : 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. Here are some: - First, I think this is very positive. I like what I'm reading. Med: Thanks. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ 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] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Re-, Please see inline/ Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 13:21 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: -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; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it. All the solutions we are discussing have the same objectives: offer IPv4 service continuity over IPv6 network. Unlike A+P related solution, * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint The draft provides these items as a reminder. Having this big picture view will help in assessing which modules are worth to be re-used and which functions are missing. New solutions is almost a combination of existing modules + new configuration parameters. As I said earlier, all Section 3 can be removed to an appendix. I personally preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing things. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. You don't need any terminology like binding mode, especially in the CPE spec since the CPE side doesn't care about what
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Simon, One answer in line (I think Med covered off the rest) Cheers, Ian On 30/11/2012 13:59, Simon Perreault simon.perrea...@viagenie.ca wrote: Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : 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. Here are some: - First, I think this is very positive. I like what I'm reading. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. I'm not sure if it's a strong enough use case to build the provisioning model around, however. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ 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] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit : - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. Ah, right, I missed that reference. Thanks. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. Something like: DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint Lw4o6: - DS-Lite set of provisioning information - IPv4 address - Port set MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? Well just from reading I thought it was different. Maybe your intent was what I expected, just not formulated the way I expected it. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 14:22, ian.far...@telekom.de a écrit : Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. Ah good point. I always forget about that use case. I'm not sure if it's a strong enough use case to build the provisioning model around, however. Not sure either. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
On 30/11/2012 14:17, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Re-, Please see inline/ Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 13:21 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: -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; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it. All the solutions we are discussing have the same objectives: offer IPv4 service continuity over IPv6 network. Unlike A+P related solution, There are/were many unfortunate things in softwires, but keeping ds.-lite-isms out of this spec would certainly not be one of them. I sympathize with your POV that a way to co-exist is desired, and a CGN-exit draft needed, but that is simply *outside* the scope of this spec. The ds.-lite ship has sailed, and there is nothing common between this spec and ds.-lite other than RFC2473. Anything with RFC2473 heritage should be included otherwise. * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint The draft provides these items as a reminder. Having this big picture view will help in assessing which modules are worth to be re-used and which functions are missing. New solutions is almost a combination of existing modules + new configuration parameters. As I said earlier, all Section 3 can be removed to an appendix. I personally preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Re-, -Message d'origine- De : Simon Perreault [mailto:simon.perrea...@viagenie.ca] Envoyé : vendredi 30 novembre 2012 14:24 À : BOUCADAIR Mohamed OLNC/OLN Cc : softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit : - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. Ah, right, I missed that reference. Thanks. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. Something like: DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint Lw4o6: - DS-Lite set of provisioning information - IPv4 address - Port set MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP. My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. Med: you need also MAP parameters (offset, EA-...). One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? Well just from reading I thought it was different. Maybe your intent was what I expected, just not formulated the way I expected it. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Med: Isn't this covered by the combination of these two points: o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. and (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE MUST be configured with the required provisioning information listed in Table 4. If all of the required information is not available locally, the CPE MUST use available provisioning means (e.g., DHCP) to retrieve the missing configuration data. If one mode is enabled, the CPE won't ask
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 15:18, mohamed.boucad...@orange.com a écrit : MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP. I don't follow. A MAP default mapping rule is exactly like a forwarding mapping rule, with added semantics saying this chunk of IPv4 is yours. That can be split into a forwarding mapping rule + the usual LW4o6 parameters, can't you? My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. Med: you need also MAP parameters (offset, EA-...). That stuff is included in a forwarding mapping rule. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Med: Isn't this covered by the combination of these two points: o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. and (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE MUST be configured with the required provisioning information listed in Table 4. If all of the required information is not available locally, the CPE MUST use available provisioning means (e.g., DHCP) to retrieve the missing configuration data. If one mode is enabled, the CPE won't ask for more than what it needs. If its receives more, it will ignore them. I can add this to text if you think it is missing. I think it would be good, and I would even add a specific example of what happens if you plug a LW4o6 CPE in a MAP-enabled network. (What I wrote above.) Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP-E 1:1 for HA
On 30 November 2012 13:37, Qi Sun sunqi.csnet@gmail.com wrote: This solution space is the outcome of Vancouver meeting. And IMO, the word 'binding' not only means there are state to maintain, but also indicates that IPv4 and IPv6 addresses are just bound together, with no algorithmic relationship. You just described an algorithm. I will assert that the *only* tangible difference between is whether it is derived from the data plane or not. Both lw46 and MAP do not derive their state from the data plane, but from a higher control plane as opposed to DS-lite/NAT44. Thus once again, coming up with binding categorization appears to be a pointless exercise. And yes, one must be able to maintain configuration state... Thanks, Woj. Thanks, Qi Sun On 2012-11-30, at 下午6:51, Wojciech Dec wrote: And much as was also said before, this categorization is bogus as all solutions need configuration state, ie categorizing solutions based on amount of configuration or some fluffy term like binding approach is equivalent to categorizing them based on how long is a piece of string and ultimately useless. What we do know is one-size of string does not work for all, and the implementers need to scale their configuration state as per their best judgement/capabilities. Cheers, Woj. On 30 November 2012 09:48, Qiong bingxu...@gmail.com wrote: 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 think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. -- == Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * === ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP-E 1:1 for HA
All, 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 but why would a CPE have to know what amount of state a tunnel concentrator keeps? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Med, et al, Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address now you got me thinking, are these really the right modes from a CPE perspective? let me try to explain, with my CPE implementor hat on, what modes would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT no IPv4 address == DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the WAN interface, but only use it for the outbound side of the NAT. then there might be a sub-modes for tunnel endpoint determination i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As native IPv4 (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
