[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Robin Whittle wrote:

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
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. 


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.
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. 


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.
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. 


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.
I saw that post, in fact, you can expect something from me or Dan in reply (probably Dan) in the next few days. 

-Michael

--
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