[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] On the Transitionability of LISP - anycast ITRs
Hi Eliot,
You wrote:
>> There are two more promising options, as far as I know, for LISP
>> (other than adopting "anycast ITRs in the core" - and there's no
>> reason I know of why this couldn't be adopted):
>>
>> 1 - 20.0.0.0/20 is still advertised in BGP, by a single border
>> router of some network L. This router is an ITR.
>>
>> 2 - 20.0.0.0/20 is still advertised in BGP, by a single border
>> router of some network L. This router is a not an ITR.
>>
>> In the former case, all packets sent from any network in the world
>> to any address in 20.0.0.0/20 will either find their way to an ITR
>> in their originating network, or will be sent out of the border
>> router (from a non-LISP-upgraded network) and arrive at the ITR,
>> where they will be tunneled to wherever they should go. The
>> problems with this are mainly the possibility of longer path
>> lengths. If the sender is in Düsseldorf, the ITR is in Japan and
>> the ETR is in Cologne, then the path length is terribly
>> sub-optimal. There are also single-point of failure problems due to
>> all hosts in non-upgraded networks relying on this one ITR for their
>> connectivity to the LISP-mapped hosts using the 20.0.0.0/20 addresses.
>>
>> However, in principle, it should work.
>
> 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. 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. One
> could go further and say that it should be a 0.0.0.0/1 and 128.0.0.0/1.
> 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.
I understand that you are proposing something like this:
There are three ISPs ISP-A, ISP-B and ISP-C. ISP-A and ISP-C have
ITRs ETRs etc. - they are "LISP-upgraded" networks. ISP-B is not
upgraded in any way.
The task is to get packets sent by hosts in ISP-B's network to an
ITR, if their destination address matches one of the address blocks
which are mapped by LISP - in this case, 20.0.0.0/20.
What you are proposing is an alternative to 20.0.0.0/20 being
advertised by a sole border router (in Japan for instance) so that
in general, the packets from non-upgraded networks get to an ITR
nearby and therefore have short, nearly or exactly optimal, total
path lengths including their trip to the ITR.
Initially you suggest either ISP-A and ISP-C would advertise
20.0.0.0/20 to ISP-B, using NOEXPORT to ensure that ISP-B's routers
do not announce a path for this prefix to any other AS.
This would work, but has a single point of failure, unless both
ISP-A and ISP-B are both doing this.
Although you don't give a precise business case for this, I guess
ISP-A and ISP-C have hosts with LISP-mapped addresses and want to
encourage this, and so wish to help ensure reachability from
non-upgraded networks such as their neighbour ISP-B. On the other
hand, maybe ISP-A and ISP-B don't want their ITRs to be getting
packets from all over the Net, so they use "NOEXPORT". Maybe ISP-B
is happy to pay them to do this, rather than run an ITR of its own.
This is somewhat like Ivip's anycast idea, except that this
proposal, as I understand it, limits its reach to just the
neighbouring AS - ISP-B in this case.
Although I don't have a precise business case for why anycast ITRs
should be built, at least Ivip has a clear, simple, technical
arrangement whereby these anycast ITRs can be either in the networks
of nearby ISPs, or be truly in the "core" by being located amongst
transit routers, in an island, not connected to any ISP's
customer-supporting network.
By using proper anycast - lots of ITRs all advertising 20.0.0.0/20
there is no single point of failure. There needs to be a business
case for why these things should be built and run. I am on the
case! Ivip is not yet 3 months old.
Looking closely at what you wrote, I realise now that the "NOEXPORT"
was just an option. Without this, you are proposing exactly what
Ivip proposes - anycast ITRs.
You also wrote:
> One could go further and say that it should be a 0.0.0.0/1 and
> 128.0.0.0/1. 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.
I think you are suggesting 200 to 300 anycast ITRs around the Net.
How many would be required depends on traffic volumes and to what
degree it was desired to achieve short paths in parts of the Net
which are more tree-like rather than mesh-like.
This latter part of your message involves these ITRs advertising the
entire address space, with two routes, this has some attraction in
that if there were 50,000 prefixes being handled by LISP (or Ivip),
then doing as you suggest would reduce the number of advertised
routes by 49,998.
The idea, I think, is that each ITR is like a global vacuum cleaner
- attracting packets to all addresses for which there is no more
specific advertisement in BGP.
However, I think this has drawbacks and that it would be best to
stick with your initial idea, as with Ivip, for each ITR to
advertise prefixes specifically.
One good reason is this: Let's say there was a single Ivip stream
of update data for 20.0.0.0/20, with a single initial database file
to download. For LISP-NERD, this would be a single database file to
download, and a single set of update files to download.
It is vital that each ITR only advertise a prefix for which it can
fully handle all packets. When an ITR boots up, it may take some
time to get the various files and update streams/files. Only then
should it advertise that prefix. So I think it makes more sense to
advertise prefixes which match the specific database files or update
streams.
For instance, if a stream or set of updates became unavailable, the
ITR could stop advertising the relevant prefix and the packets would
find their way to another ITR instead.
As long as each such prefix is supporting multiple end-user networks
(including of the one end-user, but I envisage each Ivip-mapped
address block supporting multiple end-users too, in general), then
there is still a great benefit in terms of the BGP network.
Firstly, there will be fewer advertised routes than would be
required than if each such end-user had their own advertised prefix
with the current system. Secondly, there will be less churn.
However, there will be churn as ITRs boot up or disappear. This
churn will only be limited to a local area where the ITR in question
is closer than other ITRs also advertising the prefix, so it is not
a global problem.
- Robin http://www.firstpr.com.au/ip/ivip/
--
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