Hi, after one nights sleep and looking on it again I noticed a flaw in the diagrams. The MPTCP subflow can not be initiated/terminated on different ITRs/ETRs, it must be assembled/disassembled on the same endpoint (xTR).
-- patte On Wed, Dec 9, 2009 at 11:59 AM, Patrick Frejborg <[email protected]> wrote: > Hi all, > > played around a little bit with this and had to update the > presentation...throwing another early brain dump on the table... > > The reason is - what if the ALT network is the current DFZ???? > > Then early adapters could start to build their own ALOC realms, find > peering partners and once in place start to move their customers from > DFZ to their ALOC realm. This would give the early adapters an > advantage, once they have completed their transition of customers they > control the size of their RIB and do not need to pay for a possible > upgrade of FIBs in the DFZ zone. > The ALOC realm might be build by introducing another address-family or > by using MPLS VPN L3 address-family during the transition phase. > > The DFZ would slowly implode - which I think is the main goal :-) > > I hope the RRG-team can consider this approach during the evaluation > of proposals - unfortunately I have no time to update my draft at the > moment, sorry. > > -- patte > > On Wed, Dec 9, 2009 at 3:58 AM, Patrick Frejborg <[email protected]> wrote: >> Hi all, >> >> Sorry for spamming the list with a presentation but it was the fastest >> and easiest way to show my findings when I checked the corner cases if >> both camps are integrated into one framework. >> >> When e.g. LISP is used between two endpoints, there is nothing new >> When hIPv4 is used between two endpoints, that is described in my >> draft and nothing new >> >> Two new use cases needs to be checked, i.e. >> 1) legacy client with an ITR in front establishing a session to a >> hIPv4 enabled server >> 2) a hIPv4 client establishes a session to a legacy server with an ETR in >> front >> >> To better understand I need to explain some syntax, please don't throw >> stones on me because it has been a hot topic for while :-) >> - endpoint locator, ELOC = endpoint identifier, EID in LISP >> - RLOC, as defined in LISP >> - ALOC, as defined in hIPv4 >> So three types of locators are needed, but in the Map-server and DNS >> either ALOC or RLOC is used at a time for an entry - depending upon >> the status of the site, are the endpoints upgraded to hIPv4 or not. >> >> And the xTRs could also act as MPTCP proxies :-) >> >> This is an early brain dump, so give it hard times - but it seems to >> be possible to integrated both into one framework and then the >> Internet citizens do have a choice to upgrade what suits them best. >> >> Comments? >> >> -- patte >> On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[email protected]> >> wrote: >>> I like the picture painted below of synergistic, incremental, flexbile >>> deployment of improved behavior. >>> >>> However, this two-ended incentive relates to one of the things that concerns >>> me about the current paths of this work. >>> >>> On the one hand, we are looking at a variety of tunneling mechanisms >>> designed to relive the PI pressure on the core. >>> One of the other important goals of most of these proposals is that they >>> remove the difficulty of multihoming and changing providers (thus providing >>> an incentive for enterprise cooperation / deployment.) >>> >>> Meanwhile, other sides of our house are looking at interesting ideas such as >>> TCP Multipath support. These techniques work most simply when the tcp >>> sender and receiver have visibility to the attachment addresses of the site >>> to the Internet, and the ability to select which one is used. >>> All of the network based tunneling techniques I can see seem to have the >>> property that in providing for multihoming and the ability to change >>> providers, they remove exactly the visibility that our other hand is trying >>> to utilize. >>> >>> There seems to be a systemic disconnect. >>> >>> Yours, >>> Joel >>> >>> Shane Amante wrote: >>>> >>>> Scott, >>>> >>>> On Dec 7, 2009, at 11:06 MST, Scott Brim wrote: >>>>> >>>>> Excerpts from Brian E Carpenter on Mon, Dec 07, 2009 09:30:45AM +1300: >>>>>> >>>>>> I was thinking about commenting on this point too, but Christian >>>>>> beat me to it. >>>>>> >>>>>> We *can* propagate changes to the numerically significant host >>>>>> operating systems. It takes years, so any solution based on this >>>>>> must be one with a completely incremental deployment model. One >>>>>> view of the IPv6 deployment problem is that it depends on *both* >>>>>> incremental deployment to all hosts *and* centralised deployment >>>>>> by operators. That's the worst case, but seems inevitable for >>>>>> an actual change of the IP packet format. >>>>>> >>>>>> So, I think that tells us that a solution that requires host stack >>>>>> changes only, *or* infrastructure changes only, but not both, >>>>>> is deployable. >>>>>> >>>>>> Personally, I wouldn't expect something called "routing research >>>>>> group" to propose a strategy based 100% on host changes and 0% on >>>>>> changes to the routing system. But we could conceivably propose >>>>>> something based on changes to both, and that would surely be >>>>>> a big mistake. >>>>> >>>>> Right. And best of all is to start at both ends and work toward >>>>> something good. Do something in endpoints that helps them accomplish >>>>> their goals without depending on the network. Do something in the >>>>> network that has the ability to help scale routing and addressing even >>>>> assuming hosts don't change, BUT is designed so that as the hosts DO >>>>> change that ability can be abandoned, and the whole system can become >>>>> more streamlined. >>>> >>>> I *very* much agree with all of the above points! Specifically, it's >>>> critical that we develop both types of solutions as different >>>> networks/domains are going to be vastly different in terms budget, staff, >>>> priorities and size/scale. For example, those with large size/scale may >>>> have a significant amount of 'legacy' equipment they have to maintain "as >>>> is" (or it would take [much] longer to 'upgrade' it in some form), >>>> therefore >>>> they're likely to start with a network-based solution. OTOH, those >>>> networks >>>> that are green-field, planning/obligated to do host O/S upgrades and/or >>>> small(er) networks may choose to start with a host-based solution. >>>> >>>> An analogy from a security standpoint is that hopefully most >>>> administrators realize that host-based firewall solutions are superior >>>> (particularly for laptops, etc. that roam outside a corporate firewall)[1]; >>>> however, 'legacy systems' may not [ever, or initially] support host-based >>>> firewall solutions, therefore a network-based firewall is necessary to >>>> provide protection to them ... >>>> >>>> The bottom-line is various networks (and, hosts in them) are continually >>>> evolving *and* are evolving at different time-scales. >>>> >>>> -shane >>>> >>>> [1] This would be analogous to host-based ID/Loc split solutions, assuming >>>> they provide adequate mobility. >>>> _______________________________________________ >>>> rrg mailing list >>>> [email protected] >>>> http://www.irtf.org/mailman/listinfo/rrg >>>> >>> _______________________________________________ >>> rrg mailing list >>> [email protected] >>> http://www.irtf.org/mailman/listinfo/rrg >>> >> > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
