[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.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] 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. 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? 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. 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 draft-ietf-softwire-map-d...@tools.ietf.org, draft-ietf-softwire-public-4ov...@tools.ietf.org draft-ietf-softwire-public-4ov...@tools.ietf.org, draft-cui-softwire-b4-translated-ds-lite draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo Penno (repenno) repe...@cisco.com, softwires@ietf.org 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.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 ___ 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
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. Even in the case of MAP-E 1:1, there still has 2 kinds of deployments: a. map PSID into the EA bits of the delegated end-user IPv6 prefix; b. length of EA bits = 0, which might mean no mapping at all; Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Mark Townsley Sent: Thursday, November 29, 2012 10:04 PM To: Lee, Yiu Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA I think Rajiv's point is more about how summarization of routes in IP brings fundamental scalability advantages for IP routers, not whether the routes are programmed with a what is traditionally referred to as a routing protocol or via CLI, DHCP, netconf/yang, XML, or however the MAP rules are programmed in a given network. Another way of saying this is that, in IP (v4, for example here) a /32 route is no different than a /31, /24, etc. other than a /32 just happens to refer to one address rather than two or more. The routing system *could* be run with /32s everywhere, and while scalability would suffer tremendously, hosts would have the flexibility to be numbered with a static unique address no matter where the user connected to the network. The system would have IP mobility built right in! No need for Mobile IP tunnels! It's all possible right now, just turn the state dial all the way to the right and enjoy. The point where your existing equipment falls over requiring you to redesign the network accordingly depends on the number of hosts, limitations in routers, churn and convergence, etc. but there is nothing prohibiting this per se in the protocol design - it's all just IP and CIDR. Relating this to MAP: At one extreme, you can choose to setup rules in advance such that rule aggregation is possible to a degree whereby MAP can be supported inline with routers positioned where they normally would for regular IPv6 forwarding. At the other extreme, you have less aggregation and at some point you'll probably have to introduce special-purpose tunnel concentrator hardware at specific locations. The point where this crossover occurs isn't necessarily at the 1:1 MAP rule point, it could be 2:1, 8:1, 256:1... it all depends on how many MAP rules are supported by the vendor equipment chosen and the number of endpoints being addressed. Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, 128:1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly that it should also support 1:1 - to do otherwise would be arbitrary. 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. We could have a MAP hostrule for 1:1, and aggregate-rule for N:1. Vendor equipment optimized for 1:1 mode would advertise how many hostrules it can support. A more general MAP implementation might advertise x number of rules, aggregate or not. The protocol mechanism from Softwires remains happily agnostic to all of this; To the protocol, its nothing more than semantics. Bottom line, Stateless operation is a variable tipping point... It's roughly the point where you can no longer affordably stuff all rules into all border routers in your network. If you have 2 rules for millions of endpoints, it's pretty easy to see that stateless operation is possible. If you have millions of rules for millions of endpoints, it's probably not. It's all highly dependent on the hardware, size, and design of the network. Softwires should focus on the best protocol design, and let the vendors, operators and market battle over where to turn the dial and what to optimize for in their implementations and deployments. - Mark On Nov 16, 2012, at 12:19 AM, Lee, Yiu wrote: Hi Rajiv, With all due respect, I disagree the analogy. Comparing MAP-E to routing protocol is comparing apple to orange. MAP-E is not a routing protocol. MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-E requires to statically provision states (aka rules) in the BR. Original MAP-E describes a mechanism to reduce user states in BR by using programatic logic. 1:1 MAP-E does not require any of the good stuff defined in MAP-E. I just found it odd to combine stateful and stateless mechanisms in a single draft and use a same name. Thanks, Yiu On 11/12/12 2:51 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Sure, and it is really a deployment choice (just like it is a deployment choice to use a dynamic routing protocol to advertise host routes or summary routes or both in an IP network). But that's not to say that we need one protocol for advertising the host routes, and another for advertising the summary routes.
