Subject: Re: [lisp] An Incremental Deployable Mapping Service Draft

From: [email-masked] (Noel Chiappa)
Date: Thu, 9 Jul 2009 08:57:50 -0400 (EDT)

> From: "Dong HUO" <[email-masked]>

    >> It isn't clear if the EIDs are carried in the same BGP instance as the
    >> RLOCs. If it is a separate instance, this is very similar to the ALT.

    > [Dong]: in the same BGP instance.

I have not had the time to read your draft yet, but I wanted to ask a
question about this point: If I correctly understand what you both are saying
above, LEIDs are injected into the main BGP plane (i.e. the plane which
carries DFZ routing information).

If so, is that just for backwards compatability - i.e. for 'non-LISP' hosts
(i.e. hosts which are not 'behind' an xTR) to be able to get to 'LISP' hosts?
Or are the additional reasons (e.g. having to do with the operation of your
mapping system)?

Also, how 'granular' are those EID 'injections' - i.e. are they aggregated
into large blocks, with EIDs of machines at different locations in the
networks aggregated into a single block? And what is the 'scope' of the
advertisement - i.e. does it have to go out to the entire Internet, or only
to a reduced area?

I should explain that I have been thinking about how to (eventually) operate
LISP in a way that reduces the routing load on the 'core' BGP (i.e. the BGP
which carries the DFZ routing information), via reducing the granularity and
scope of various advertisements.

There are three kinds of addreses being advertised: 'legacy' addreses (i.e.
non-mapped IPv4 addresses), EIDs (for use by 'legacy' sites and hosts), and
RLOCs. If we have to advertise all three over global scopes, with high
granularity, we will have gained some capabilities (e.g. mobility,
multi-homing) only at the expense of greater routing overhead.

At the same time, the existence of these three classes does offer us the
opportunity, if we can reduce the granularity and scope of some of them, to
actually reduce routing overhead. What will be possible depends on exactly
what the operational scenario is - e.g. if we have entire areas of the
network which are surrounded by LISP-capable devices (which would allow us to
dispense with advertising EIDs in that scope - and potentially drop legacy
addresses as well, if we set up Proxy xTRs at the edge of that area to handle
legacy addresses).

	Noel

---

From: "Dong HUO" <[email-masked]>
Date: Thu, 9 Jul 2009 23:35:23 +0800

[Dong]: Yes.

[Dong]: Yes it's for backwards compatability, but not for 'non-LISP' sites going to 'LISP' sites.
We consider the compatability for the first place, so the big difference between our solution 
and the LISP+PTR (draft-lewis-lisp-interworking) is that
in LISP+PTR, PTR is for 'non-LISP' sites going to 'LISP' sites. It's supplementary to support non-LISP sites.
However in our solution, the ER is indispensable, and the DHT MO is supplementary to reduce the tunnels.

So the deploying sequence in LISP+PTR would be: firstly several sites deploy LISP and then PTR for non-LISP sites.
However in our solution, it would be: firstly an ER is deployed in a provider AS, and after serveral ASes are deployed,
they can join the DHT MO individually and optionally for improvement.

[Dong]: In this draft, the addresses from non-DFZ are all considered as EIDs (including the 'legacy addresses' you mentioned).
And we treat the address as different three kinds: EID aggregated (only have EID components), 
EID+RLOC aggregated (have EID and RLOC components, i.e., some EID blocks and RLOCs are aggregated), 
and RLOC.  The ER only holds the EID aggregated prefixes.

[Dong]: I personally think placing PTR is difficult. As mentioned in *draft-lewis-lisp-interworking*,
"For large transit providers, deploying PTRs may attract more traffic, and therefore more evenue, from their customers",
but what if these providers compete with each other to attract the traffic, 
isn't there another problem similar to the problem caused by multi-homing 
that an aggregated prefix is divided into longer ones for being attracted?

Noel
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

Thx for your attention! :-)
Best Regards!