Subject: [RRG] Moving the problem to the global mapping system

From: Robin Whittle <[email-masked]>
Date: Thu, 10 Apr 2008 16:24:54 +1000

In "Re: [RRG]", responding to Tony's message of 22 March:

  http://psg.com/lists/rrg/2008/msg00964.html

Michael Meisel wrote, in part:

> (1) Is the mapping function successful in preventing edge 
>     network reachability from being propagated into the
>     global routing system?
> 
> (2) If yes, does it do so without simply moving the problem 
>     to the global mapping system?
> 
> Note that proposals that both (a) put reachability information into the
> mapping system and (b) involve any sort of push model start to look a
> lot like BGP, and therefore are going to have a hard time answering
> "yes" to (2) convincingly.

I think a good proposal should provide a Yes answer for (1) and may
well provide Yes for (2), as Ivip does.

Ivip's mapping information is a single ETR address.  If that ETR
becomes unreachable, the end-user (or some system they nominate)
uses the global fast hybrid push-pull mapping distribution system to
change the mapping to point to another ETR.

If Ivip's mapping distribution system was as costly, slow and
generally problematic as BGP's way of communicating route changes
globally, then a Yes answer to 2 would indicate that nothing of
great value had been achieved.  (BGP has to do it this way, since
each router in the system needs to make its own decisions, which
depend on the decisions of other routers.)

However, Ivip's mapping distribution system is completely different
from how BGP works and is optimised to handle much greater flows of
information, faster and more reliably than BGP.

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

When trying to frame questions about something like the "mapping
function", as we get down to questions which provide meaningful
answers regarding important principles and implementation details, I
think the questions only tend to make sense if certain architectural
attributes can be assumed.

I find it hard to think of common questions which tell us anything
meaningful about the five current map-encap schemes - LISP-NERD,
LISP-ALT, APT, Ivip and TRRP.

My message a week ago:

   http://psg.com/lists/rrg/2008/msg01091.html
   Taxonomy: 25 questions

had several questions which teased out commonalities and differences
in the mapping systems of these proposals.

  - Robin             http://www.firstpr.com.au/ip/ivip/

--
to unsubscribe send a message to [email-masked] 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

---

From: Michael Meisel <[email-masked]>
Date: Thu, 10 Apr 2008 01:54:29 -0700

>   http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

Hi Robin, you often refer to Ivip's "fast" mapping distribution method 
as an unabashedly positive thing. However, it seems to me that you've 
simply picked a different point in the tradeoff space -- by increasing 
the speed of mapping distribution, you increase the amount of mapping 
traffic as well. So even if each update can be handled more efficiently, 
there could be many, many more of them. So you may not have a win 
overall in terms of (processing per update) * (number of updates) * 
(number of devices doing the processing), even versus BGP. Notice I said 
you /may/ not -- if you can come up with some defensible worst-case 
numbers, people may be convinced. Also, people may disagree with me that 
this is a good metric. But I think you'll find yourself fighting an 
uphill battle.

> attributes can be assumed.

Actually, I tend to agree with you on that. I quite enjoyed your post on 
the subject. =) However, I think it's possible to set some quantitative 
constraints on possible designs. In particular, setting constraints that 
the design must be able to solve the problems we are setting out to 
solve (without re-introducing them elsewhere) seems quite reasonable to me.

> LISP-ALT, APT, Ivip and TRRP.

Yes, whether such constraints are meaningful is another issue entirely. 
=) My worry about generalities is that they always seem to be up for 
dispute when it comes down to applying them to any specific case.

> in the mapping systems of these proposals.

I saw that post, in fact, you can expect something from me or Dan in 
reply (probably Dan) in the next few days.

-Michael