Re: shim6 @ NANOG

[David Meyer <dmm () 1-4-5 net>]

        Stephen,

> Thus spake "Tony Li" <tony.li () tony li>
> > Stephen Sprunk wrote:
> > > Who exactly has been trying to find scalable routing solutions?
> >
> > Well, for the last decade or so, there's been a small group of us who
> > have been working towards a new routing architecture.  Primary
> > influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark,
> > Atkinson, Fuller, Huston, Rekhter and Meyer.  Apologies to any folks
> > that feel I've incorrectly included or excluded them.  ;-)
>
> And my apologies for not recognizing the work that y'all have done; my 
> point was that none of this seems to be officially supported by the IETF, 
> and thus hasn't borne much fruit.  I've seen a few proposals by folks 
> listed above, and it seems to be old drafts (or even napkins) that get 
> trotted out when this discussion comes up.  If there's work actively going 
> on today, it's not well publicized.

        Speaking for myself, I can say that many of us are trying
        to raise the profile of exactly these issues in the
        IETF. As you might imagine, that's not exactly a "path of
        least resistance", given the history/baggage. My
        position, however, is that the past is something we can
        learn from, but not be controlled by (a perhaps
        metaphorical way of saying "lets get on with it").

        I'm optimistic that we're getting traction, but as I
        said, history and inertia are pushing the other way (not
        that that's going to stop us, but it does slow things
        down at times).

> > > IPv6 advocates have been pushing a no-PI model for over a decade
> > > because that's what ISPs told them to do.
> >
> > More accurately, the routing community has been trying to avoid PI
> > addressing simply because of the scalability (and thus cost) concerns.
>
> s/routing/ISP/ and I'd agree with that.  The IETF has virtually no 
> enterprise representation, and those folks (a) have a lot more routers than 
> the ISPs, and (b) pay the ISPs' bills.

        Agreed, and representation is a big problem. I'm trying
        to work that too. The first thing we tried was the
        NANOG/APRICOT BOFs (and I think we're going to try it at
        RIPE too, waiting to hear from the PC on that one). So
        maybe these were not as successful as I would have hoped,
        but hey, you have to start somewhere (on the theory that
        the best way to finish anything is to start).

> I agree that PI has scaling/cost problems, but so far all of the 
> alternatives presented by the IETF present worse problems _in the eyes of 
> the people that pay the bills_.  That doesn't mean the latter are right, 
> but their views should not be taken lightly.
>
> > > When they found end users didn't like that, they went off and
> > > developed what has become shim6 as a poor apology. There has
> > > never been any significant work done on replacing CIDR with
> > > something that scales better.
> >
> > More accurately, that work (GSE/8+8) was slapped down politically
> > without due technical consideration.
>
> Correction noted.
>
> > Note that replacing CIDR isn't exactly the point.  The point is to have
> > something that scales.  Where CIDR can't cope is exactly when we
> > come to multihoming.  When multihoming was a rare exception, the
> > small number of PI prefixes remains tolerable.  However, over time,
> > the continued growth in multihoming, even solely as a function of the
> > growth of the Internet will come to dominate the cost structure of
> > the routing subsystem.
>
> I'm not sure I agree with that.  The ISPs out there have tens of prefixes 
> each even in v6 land (and hundreds in v4 land), whereas the goal is to have 
> one per end site.  Until the number of multihomed end sites exceeds the 
> number of ISPs by several orders of magnitude, the impact on the routing 
> table will be non-dominant though certainly also non-trivial.
>
> Also, consider how easy it is to do PI-based multihoming in v4: all you 
> need is a couple pipes (or tunnels), an ASN, and enough hosts to justify a 
> /24. If you believed all the chicken littles, this would leave us with 
> millions of v4 PI routes and the DFZ would be in ruins, yet only a few 
> hundred people have taken ARIN up on that offer.  In short, implementation 
> of PI-based multihoming has ground almost to a halt even under today's 
> liberal policies.
>
> Now, given the floodgates are open for v4 and all we see is a trickle of 
> water, why is everyone running around screaming that the sky will fall if 
> we do something similar for v6?  Do we have any evidence at all that 
> multihoming growth will outpace Moore and this whole debate is even 
> relevant?
>
> > The only alternative to a PI-like architecture is to provide multihomed
> > sites with multiple prefixes, none of which need to be globally
> > disseminated.  Making this multiple prefix architecture work was the
> > charter of the multi6 group.  This was constrained in interesting ways,
> > as both NAT box solutions were considered politically unacceptable, as
> > was changing the core functionality of the v6 stack (i.e., redefining
> > the TCP pseudoheader).  Given these constraints, it was somewhat
> > unsurprising that NAT got pushed into the host.
> >
> > From my perspective, we have now explored the dominant quadrants of the
> > solution space and various factions have vociferously denounced all
> > possible solutions.  You'll pardon me if some of us are feeling just a
> > tad frustrated.
>
> I think we're all a bit frustrated at this point.

        Agreed, we all are. And BTW, I'm also on the inside, and
        I think you can see how that might be frustrating. But
        things can (and will) change. Again, at the very least I
        am optimistic.

> However, I think we haven't adequately explored several ideas that allow PI 
> space for all that need it yet don't require carrying all those routes in 
> every DFZ router or schemes that do away with our current idea of the DFZ 
> entirely.  The solution space is a lot bigger than the few corners that 
> we've explored over and over.
>
> > > Every such proposal I've seen has been ignored or brushed aside by
> > > folks who've been doing CIDR for their entire careers and refuse to
> > > even consider that anything else might be better.
> >
> > More accurately, the folks that have been CIDR advocates 'for their
> > entire careers' are exactly the same folks who have been advocating
> > shifting to something else, but have been rejected by other political
> > elements when trying to propose actual architectural change.  Further,
> > those same CIDR advocates have been, and continue to be, in such
> > political disfavor that they are effectively powerless anyhow.  It
> > hardly seems like their rejection could count for much.
>
> CIDR is in political disfavor?  Then explain how the IETF's golden solution 
> for multihoming perfectly toes the CIDR line of not allowing end sites to 
> have PI space, forcing them to use multiple CIDR-style PA prefixes in 
> parallel.

        It doesn't. The current thinking seems to be a
        combination of PI+SHIM6 until some other solution is
        found. Even if one agrees with this approach, one must
        first start trying to find such an "other solution", and
        second, understand how we're going to drain the
        (potentially massive) swamp created by PI
        allocations (if that is even going to be possible, given
        technical and nontechnical issues such as grandfathering,
        etc). 

> Or did you mean that the folks that came up with CIDR are now personally 
> out of favor?  That'd be a shame, since that was good work at the time and 
> we need every bright mind we can get to make the next step past CIDR.
>
> > > All this time, energy, and thought spent on shim6 would have been better
> > > spent on a scalable IDR solution.
> >
> > On that, we can agree.  However, my feeling is that fully exploring the
> > solution space is an unfortunate necessity before the community is
> > willing to accept changes to the fundamental v6 architecture.
>
> IMHO, it's 5+ years too late to change _anything_ about how end hosts 
> process IPv6 packets.  If we need to do that, it's time to scrap v6 and 
> start working on IPv9 (or whatever the next unassigned number is), with the 
> understanding it won't be deployed for another 15+ years and we'll need to 
> keep IPv4 working that long.

        Continuing with the "you need to start somewhere" theme...

> > > Luckily, we still have another decade or so to come up with something.
> >
> > Unfortunately, that's not entirely true.  If the RIR's begin wholesale
> > PI assignment, then we start down the road of re-constituting the v4
> > routing architecture, locking in additional cost and complexity with
> > each PI prefix.  All such prefixes will be indefinitely grandfathered,
> > so even if something new does come along, we will continue to pay for
> > the overhead forever.
>
> If the new solution is sufficiently attractive, then folks using PI-based 
> multihoming will switch.  If nobody wants to switch and/or there's still 
> demand for PI space, that is a very strong sign that the proposed solution 
> is not acceptable in the first place.

        Exactly.

        Dave

Attachment: _bin
Description: