[RRG] comments on IVIP Conceptual Summary and Analysis documents

[<philip.eardley@bt.com>]

Robin

Here are a few questions & comments, based on reading http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf  

I guess some of them also apply to other map & encap proposals. Please feel free to point me at emails etc where you've already answered them!

<In this way, instead of each end-user gaining
conventional PI space, with its own one or more BGP advertised prefixes, the needs of all these end-users
are satisfied with only the single advertisement of the MAB burdening the control plane of the BGP
network.>

yes, although there's the burden on the mapping system (which hopefully is less). What would be good would be to get order of magnitude estimates of how much *overall* this is saving (if that makes sense)

<Every micronet is mapped to a single ETR's
address. Load sharing can be achieved as long as the load is spread over multiple IP addresses (or /64s),
by making each one a separate micronet, and mapping each micronet to a different one of several ETRs.>

Today multihoming & route flapping are big causes of BGP updates - I think a good % come from sites that flap at whatever the max rate allowed is (partly this seems to be how some do load balancing /TE). How many updates can your global push system cope with? Does it assume that these are just for change of provider, or are TE updates also ok? 

I also worry about the single ETR approach (although I can see it has attractions from the simplicity point of view). What are the implications for resilience? Ie after there's a failure, how long will it be before a site gets connectivity /reachability again (do I have to wait for the global push to get everywhere)? For the most sensitive customers (say stock exchange trading floors) we probably want to aim at msecs. 

< In
particular, ITRs (presumably ITRDs, but not necessarily) can be located in the DFZ, where they advertise
the MAB prefixes and attract packets sent from networks which have no ITRs. This "anycast ITRs in the
DFZ (or core)" approach makes Ivip incrementally deployable.>

First, Let me check. If one end (A) is legacy & the other end (B) is Ivip, then comms go A-> "anycast ITR"-> ETR-> B and the other direction goes B -> A.
Second, what's the benefit for the network deploying the "anycast ITR"? Initially one end is legacy for all the Ivip end's comms, so they all have to go through the anycast ITR. But presumably the anycast ITRs have to be well distributed through the Internet (eg would it be any good if just the Ivip network put in an anycast ITR? Would the legacy nws be able to reach it?)

< The new type of space will be attractive to end-users because it can be used for multihoming and
portability>

I'm not yet convinced about this. it seems to me that more of the benefit is for the transit nws. After all, the end-users can do portability (PI) today, it's just that Ivip hopefully reduces the burden on BGP.

< With Ivip, mapping changes, or at least frequent mapping changes, should be charged for, so that endusers
contribute to the cost of running the global push system,>

this is a nice idea, but the commercials of how to introduce this when others don't are tricky. Not necessarily insuperable - after all, you can give people a generous allowance as part of their contract. 
I wonder: if we assumed it was commercially doable (charging for over-frequent updates), why couldn't we do this today? If we charged today for sites sending over-frequent updates, and charged on the expected impact (*) they cause the global BGP (eg update of a PI goes everywhere, so charge more) - would you get enough of the benefit compared with doing Ivip? would the migration difficulty of doing this be harder or easier than Ivip? 
(*) Similarly, 'charge' wouldn't have to mean '£ money per msg'; in fact, you could think of today's route flap damping as a form of charging, and this would just be a bit more sophisticated.


I have a slightly unfocussed concern about introducing a new 'layer' of the ITR-ETRs (unfocussed meaning I can't quite put my finger on it, so it's hopefully wrong). Basically, in addition to today's inter-domain 'cloud' we have on top an ITR-ETR cloud. Does this effectively add another layer of policy control, failure management, fault tracing, perhaps even topology mgt, etc? do these things operate separately for each (are their operations hidden from each other)? Or does the mapping system effectively expose the inter-domain 'cloud' to the ITR-ETR cloud? Even the latter would seem to mean a big change from a policy mgt perspective, in that policy control shifts from BGP into the mapping system?

Thanks,
phil.


> -----Original Message-----
> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf Of Robin
> Whittle
> Sent: 25 February 2008 23:09
> To: rrg
> Cc: Lixia Zhang; Tony Li
> Subject: Re: [RRG] Process proposal: Conceptual Summary and Analysis
> documents
> 
> Lixia and Tony wrote, in part:
> 
> > Thanks to Robin who reminded us about this (see his msg February
> > 19, 2008 7:00:47 AM PST) and was the first one to submit the
> > requested documents!
> 
> I missed the deadline by a day or two, but Christian Vogt's
> documents were there before the deadline.
> 
> In the event that I change the Ivip proposal in a way which affects
> the description and analysis, I hope it will be OK to replace the
> linked to document with another version of similar length.  Whenever
> this occurs, I plan to do this, with a note at the top stating the
> new version's date and a pointer to the previous version and a
> changelog.
> 
>   - Robin
> 
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg