Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip

[Robin Whittle <rw@firstpr.com.au>]

Hi Eliot,

Thanks for your reply, in which you wrote:

>> Eliot developed a similar "anycast ITRs in the core" approach 
>> for LISP-NERD.
> 
> This has been ascribed to me before, and either I misspoke or was
> misunderstood.  

You didn't use the term "anycast", but you wrote an alternative
approach to two proposals I made, both of which have problems, and
which I think were the only alternatives to "anycast ITRs in the
core".

  http://psg.com/lists/rrg/2007/msg00260.html

   > I think I would handle this differently. Prior to withdrawing
   > 20.0.0.0/20 there should be a reasonable number of ITRs in SP
   > environments.

So far I think this is the standard LISP approach of relying on
there being enough networks with ITRs that the unreachability of
20.0.0.0/20 from networks without ITRs would somehow not be a
problem when this prefix is no longer advertised in BGP.  The
trouble is that even a few hosts in networks without ITRs is
probably a completely unacceptable problem for anyone contemplating
using this address space.

   > At that point it makes sense for those to at least locally
   > propagate a NOEXPORT route along the lines of 20.0.0.0/8.

This is not exactly anycast, but I understand it involves multiple
border routers of multiple ISPs acting as multiple ITRs and
advertising the same prefix to neighbouring ISPs - with NOEXPORT
preventing those ASes (or is it those routers?) from propagating the
route to this prefix any further.  So the neighbouring ASes which do
not yet have ITRs would have their hosts able to reach hosts in the
LISP-mapped prefix 20.0.0.0/20.  NOEXPORT ensures that those
neighbouring ISPs would not transit traffic from their neighbours to
this prefix.

Depending on AS topology and how many ASes didn't yet have ITRs,
this would marginally reduce the number of ASes in which hosts could
not send packets to 20.0.0.0/20.  So it is not a complete solution.

  > One could go further and say that it should be a 0.0.0.0/1 and
  > 128.0.0.0/1.

That would make each border router in a LISP-upgraded AS (each one
is implicitly an ITR as well) attract packets for all otherwise
unadvertised address space from its neighbouring ASes.  This would
collect all the packets from neighbouring ISPs which need to go to
an ITR, when the neighbouring ISP has no ITRs.

 > At that point you can have multiple ITRs doing this for
 > redundancy's sake, and you're doing it with very few routes.
 > Maybe 200-300 at most.

The key points you make include having multiple ITRs advertising the
same prefix.  To me, this is anycast.  However, as long as they all
advertise with NOEXPORT, maybe this isn't quite the same as
"anycast".  I don't see the purpose in limiting the range of packet
collection with NOEXPORT.

Still, it was close enough for me to regard it as "similar" to
"anycast ITRs in the core".  I wrote about this to the list because
it was at a time when no-one else involved in LISP had said anything
positive about my "anycast ITRs in the core" proposal.


> I believe Dino early on recognized that anycast 
> could be a useful scaling mechanism for LISP.  I myself have not 
> explored anycast in any substantial way.  I have, however, 
> pondered transitions, but I have not devoted as much "ink" to 
> transition as perhaps you and others have.  Our early exchange 
> you quote below refers to multiple announcements and not anycast.

I don't see how "multiple announcements" - multiple ITRs in the DFZ
advertising the same prefix is different from "anycast", as I use
the term or as it is used in the new ID:

  http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt

unless your use of NOEXPORT is regarded as such as difference.

Normal BGP practice is to have one router advertising a particular
prefix.  If two or more do, I think it is reasonably described as
"anycast".  The principles are the same whether it is 2 or 20,000
routers advertising the same prefix.


>> It seems, from the language with which [Eliot] expressed his 
>> ideas, that he developed this independently of whatever he 
>> might have known about Ivip.  He acknowledged that his approach
>>  resembles mine:
>> 
>> http://psg.com/lists/rrg/2007/msg00260.html 
>> http://psg.com/lists/rrg/2007/msg00264.html 
>> http://psg.com/lists/rrg/2007/msg00288.html
> 
> As I said, I was told there were similarities, probably by you.

Yes - as much as I understand what you wrote, it seems to be
very similar in principle to "anycast ITRs in the core/DFZ", which
is in Ivip and draft-lewis-lisp-interworking-00.

I recognise that what you wrote was in a mailing list message rather
than an ID, but you were providing information on the possible
future direction of LISP-NERD and helping to show how it could be
incrementally deployed.


> Also, I have not been focusing on transition but longer term 
> matters.  Although it may appear the case by company name, we are
> not all at Cisco of one mind, and sometimes our best
> coordination occurs at IETF, IRTF, and similar places.  

LISP IDs are written by quite a number of people and I don't assume
you all think alike or work closely together.  The basic LISP
architecture can be used with various mapping systems.  NERD takes
the middle road in terms of speed for a push system - faster than
eFIT-APT and slower than Ivip's ambitious "few seconds" goal.  I
think push to the ITRs (and/or push to local query servers, as is
possible with Ivip and as is the basic architecture of eFIT-APT) is
better than relying on a global query system as does LISP-CONS and
TRRP.  That global query system is bound to be slow and unreliable -
and also costly and potentially complex, as is LISP-CONS or LISP-ALT.


> And to be fair, I do not have a full understanding of iVIP.

I didn't suggest you understood Ivip, or what I wrote to the RAM
list starting on 2007-06-15.  I guess you developed it independently
- though I was arguing the inevitability of "anycast ITRs in the
core" in list discussions at the time.


> Finally, please understand that with such a fast moving field,
> and a -00 draft out, I think figuring out who did what first has
> not been foremost on people's minds.  I personally try not to be
> original about anything ;-)
> 
> All the best,
> 
> Eliot

Who thought if this first and who wrote in public about it first are
minor matters compared to the importance of acknowledging that a
mechanism Y in scheme X is similar or identical to mechanism B in
scheme A.  We owe that to the readers of our IDs.

This field is difficult enough without people writing up the same
thing, as if it was a new and different approach to what has already
been publicly proposed in another scheme.

There is a strong tradition in science, engineering and the IETF of
correctly attributing the source of ideas - or at least any prior
publication of similar or identical ideas.


I do try to be original.  I come into this field with less
experience of networking than most people on this list.  That is an
obvious disadvantage - but one advantage is I see may things in a
fresh light.  There is an adage about never asking an expert to do
something which is "impossible", because they know it can't be done.

If I propose 10 things and only one of them turns out to have
long-term value, I figure this is worthwhile.

Few people seem to think it is practical to do what I intend with
Ivip - fan relatively simple mapping data out around the world to a
few hundred thousand (later millions?) ITRs in a few seconds.  I
reckon it can be done.  If not, there are plenty of other ideas in
Ivip and IPTM which I think might have long-term value.

If it can be done, then the ITR-ETR scheme can be simpler and
support mobility in efficient ways not previously dreamed of by
mobile IP people - because they never considered that something like
a global ITR scheme could be justified just for mobility.

Since we have to build a global ITR scheme, I say lets make it fast
and simple from the start.  If LISP was built, in any form, people
would soon be trying to soup it up to get the mapping data to the
ITRs faster.

  Cheers

    - 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