Re: [v6ops] Up-leveling Transition Coexistence

[Mark Townsley <[e-mail]>]

On Dec 19, 2011, at 8:35 AM, Wuyts Carl wrote:

> Some feedback on the below, being a CPE vendor for residential market.
> First note that, although our main deployment is in the residential CPE market, we're not present in retail, so maybe my view is "spoiled" due to this.
> 
> I don't believe in this configuration-oriented approach at all as it is mainly to complicated or not really a possible approach.  There are 4 possibilities listed in this scenario, where we would have to pick one from, but none of them are really suitable I think, for sure not the one where you'd have to run a "couple" of configuration attempts with timeouts etc" or "have to shut down intfs based upon ...".
> Although some of these can possibly covered through some scripting, this is nothing really one should force upon a CPE, in fact, to no other IP device either.  Let's stick to standard behavior, threating an IP intf as it should be, not try to enforce some "extra's" on top of them.  An IP intf gets enabled, and can start forwarding traffic if the forwarding is allowed upon it (so routes availabe etc).  If you want to accomplish the below, I think you've to force lots of policy on top of the present CPE's capabilities in this area, so a no-go I'd say.  Please don't mix a residential CPE with a full-blown business router.  Again this seems to be an attempt of enforcing some stuff upon the CPE, to be avoided I'd say (again).

Fully agree that the "configuration-oriented" approach is very problematic. Unfortunately, this was the path that 6204-bis seemed to have been headed down. I hope we're changing that course.

> 
> I also see some replies on "what if multiple transition scenario's are being used at the same time, combining DSLite with 4over6 or whatever".  This is of course possible in multi-homed scenario's but again here the same applies.  Let's try to keep normal IP behavior in place, read forwarding-oriented approach, not try to enforce all kind of tricky things.  As our customers are operators, not end-users, dual-homed scenario's are not our main target, but I can't see any added value looking into this "configuration-oriented" approach.

I think you are saying the "forwarding-oriented" approach is preferred, given the alternative being the "configuration-oriented" approach. However, perhaps you are saying you really want to do "none of the above". 

Problem is, you have to choose one or the other if you are going to support DS-Lite or 6rd. Take your pick. Neither is not an option. 

- Mark

> 
> My 2 cents
> Regs
> Carl
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark Townsley
> Sent: woensdag 14 december 2011 18:27
> To: [e-mail] Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
> 
> 
> Folks,
> 
> We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs. 
> 
> The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:
> 
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc) 
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 
> 
> Digging deeper into transition between these states:
> 
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other. 
> 
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.
> 
> For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.  
> 
> I'd like to identify two strategies to deal with these situations. 
> 
> The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version. 
> 
> (a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or 
> 
> (b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or
> 
> (c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch. 
> 
> (d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.
> 
> The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.
> 
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4. 
> 
> Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.
> 
> Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-) 
> 
> Thanks, and Happy Holidays in advance to those who will be celebrating soon,
> 
> - Mark
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops