Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

From: Jon Crowcroft <[email-masked]>
Date: Sun, 01 Feb 2009 09:30:55 +0000

you can push info multiply redundently
(or cross-post:)
and you get reliability with a silly overhead

or you can push an update which is wrong and disconnect the entire
world, e.g.
http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html

so aside from the basic academic type scaling, has anyone done
this sort of disaster-prone analysis for LISP/ALT?

(i.e. human stupidity resilience, rather than security-to-prevent evil)

one is reminded of simily errors with DNS root databases and with 
BGP adverts...one woudn't want to design a system with
one-click take-down again

In missive <[email-masked]>, Christian Vogt 
typed:

 >>
 >>On Jan 28, 2009, Dino Farinacci wrote:
 >>
 >>> You cannot push around 10^10 entries and store them everywhere. [...]
 >>
 >>
 >>
 >>Dino -
 >>
 >>I think we should experimentally compare ALT with other mapping systems
 >>before we decide whether pull-based or push-based mapping systems are
 >>better.  Dismissing push-based mapping systems without corroborating
 >>data would be a bit premature in my opinion.
 >>
 >>In the absence of experimentation results, I would actually argue in
 >>favor of push-based mapping systems based on some analytical reasoning:
 >>Pull-based mapping systems have two important disadvantages compared to
 >>push-based mapping systems:
 >>
 >>- Performance penalty, i.e., additional propagation latencies for some
 >>   packets, and higher loss probabilities for packets that take a sub-
 >>   optimal path
 >>
 >>- Robustness penalty due to a new online dependency on components off
 >>   the actual transmission path.  (FWIW: All pull-based mapping systems
 >>   have this penalty.  Mapping requests must be routed via overlay
 >>   infrastructure because the direct route is unknown at that time.)
 >>
 >>Furthermore, I do not share your concerns regarding push-based mapping
 >>systems:  BGP is pushing routing data already today, and this works
 >>fine.  Any routing-scalability-related issues with BGP are not due to
 >>BGP being push-based; they are due to frequent updates and a high load
 >>for core routers.  Both of these issues would go away in an address
 >>indirection architecture (be it LISP, Ivip, APT, or Six/One Router),
 >>independent of whether you use a pull- or push-based mapping system.
 >>
 >>In conclusion:  The overlay approach of ALT is certainly an interesting
 >>idea.  But I think it would be premature to conclude that it is the only
 >>viable solution before we have more evidence to back this claim.
 >>
 >>- Christian
 >>
 >>
 >>PS:  I admit that I have never been really good in avoiding cross-
 >>posting.  But this is obviously my all-time negative record...
 >>
 >>
 >>
 >>_______________________________________________
 >>routing-discussion mailing list
 >>[email-masked]
 >>https://www.ietf.org/mailman/listinfo/routing-discussion

 cheers

   jon

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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Feb 2009 10:17:53 -0800

> data would be a bit premature in my opinion.

Agree.

>  infrastructure because the direct route is unknown at that time.)

Make note that LISP-ALT is a hybrid. It pushes EID-prefix  
announcements via eBGP over an alternate topology of GRE tunnels. And  
then ITRs pull the mappings by sending Map-Requests on this topology  
so ETRs (who are authoritative for the mappings) can return Map-Replies.

> fine.  Any routing-scalability-related issues with BGP are not due to

But the BGP RIB is order 10^5 and on average (there is lots of data on  
this) only 10% of that table is used in any given router.

> for core routers.  Both of these issues would go away in an address

Other reason you want to push is if all the nodes in the "push domain"  
need to use the information. If they don't it is a waste of memory and  
resources. BGP is used as a transport for routing information but each  
node uses that information.

Make note that NERD has been called a "push" mechanism. But it  
actually is requesting to receive *all mappings*.

Also, another point I want to make where I'll use the iPhone 2.0  
release as an example. In 2.0, they said they had "push email". Well  
from a user point of view, that means when you open your mail app, the  
email is sitting there ready to be read. If in the background, there  
was a periodic process to pull the email, then it still looks like push.

The point here is begging a single question:

     1) Should all the mappings in the universe be in an ITR?

     2) Should only the mappings for sites the ITR is currently  
talking to be in the ITR?

This is the important matter. Decide on that then we can talk about  
how to get the mappings where they need to be.

> viable solution before we have more evidence to back this claim.

Why do you think a conclusion is being made. I haven't made any.

Anyways, this is a good discussion and glad we have moved passed the  
definition of an EID.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 01 Feb 2009 13:45:26 -0500

I don't think those are the only two alternatives.  For example, 
something like the APT idea where the full mappings are shipped to a set 
of devices such that such a full set is near to and on the query path of 
any leaf is an alternative worth examining.

 From a design perspective therefore, I would tend to look for a system 
where a device can be sent unsolicited mappings, can choose to keep 
them, and can issue a query via an overlay to resolve mappings it does 
not have.
While one could argue that this complicates the protocol, it is an 
unneeded complication only if we are very sure we know what the right 
answer is for information distribution.  It is admittedly more complex 
than just using BGP to carry EIDs.  Are we sufficiently sure?

It then becomes an operational decision whether the mappings are in any 
given leaf, in some intermediate devices, or in just the originating 
leaves.  (While the decision on the alternatives can not be made wholly 
independently by all the branches of the overlay tree, there is room for 
flexibility.)

Yours,
Joel

>> Dino -
...
>     2) Should only the mappings for sites the ITR is currently talking 
> to be in the ITR?
> 
> This is the important matter. Decide on that then we can talk about how 
> to get the mappings where they need to be.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Feb 2009 12:05:56 -0800

> something like the APT idea where the full mappings are shipped to a  
> set of devices such that such a full set is near to and on the query  
> path of any leaf is an alternative worth examining.

We have stated before that LISP-ALT routers could cache mappings. This  
can help with Map-Request latency. And if the mappings are cached do  
to seeing Map-Replies or because they are pushed with some other  
protocol, then so be it.

> From a design perspective therefore, I would tend to look for a  
> system where a device can be sent unsolicited mappings, can choose  
> to keep them, and can issue a query via an overlay to resolve  
> mappings it does not have.

They would have to be signed.

> unneeded complication only if we are very sure we know what the  
> right answer is for information distribution.  It is admittedly more  
> complex than just using BGP to carry EIDs.  Are we sufficiently sure?

Agree.

> It then becomes an operational decision whether the mappings are in  
> any given leaf, in some intermediate devices, or in just the  
> originating leaves.  (While the decision on the alternatives can not  
> be made wholly independently by all the branches of the overlay  
> tree, there is room for flexibility.)

Right, but is a state/latency tradeoff.

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 02 Feb 2009 10:07:35 +0800

Hi Joel,

> I don't think those are the only two alternatives.  For 
> example, something like the APT idea where the full mappings 
> are shipped to a set of devices such that such a full set is 
> near to and on the query path of any leaf is an alternative 
> worth examining.

That's just the basic idea of VA (Virtual Aggregation, see
http://tools.ietf.org/html/draft-francis-idr-intra-va-01, and
http://tools.ietf.org/html/draft-xu-idr-tunnel-00). And we are now doing
some updates to simplify VA mechanism and will submit new versions soon.

>  From a design perspective therefore, I would tend to look 
> for a system where a device can be sent unsolicited mappings, 
> can choose to keep them, and can issue a query via an overlay 
> to resolve mappings it does not have.

In VA, the mappings (EID prefixes associated with RLOCs)are advertised
through currrent BGP connections. The RLOC information can be carried by a
new BGP attribute, e.g. a special extended community. VA routers will
install the mappings selectively into their routing tables according to
whether or not they are the APRs(Aggregate Point Router) for those mappings.
In this way, the full mappings are distributed among a set of APRs. The
overlay composed of a set of APRs can not only be used for mapping
request/reponse, but also be used for transferring data packets when the ITR
has no mapping entry for these packets in its cache.

> While one could argue that this complicates the protocol, it 
> is an unneeded complication only if we are very sure we know 
> what the right answer is for information distribution.  It is 
> admittedly more complex than just using BGP to carry EIDs.  
> Are we sufficiently sure?

In VA, extended communities are used for conveying the RLOCs, and BGP
computation behavior remain unchanged. So this will not complicate the
protocol too much.
 
Xiaohu

> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Scott Brim <[email-masked]>
Date: Mon, 2 Feb 2009 12:04:31 -0500

Excerpts from Christian Vogt on Sat, Jan 31, 2009 11:49:46AM -0800:
> I think we should experimentally compare ALT with other mapping
> systems before we decide whether pull-based or push-based mapping
> systems are better.  Dismissing push-based mapping systems without
> corroborating data would be a bit premature in my opinion.

I don't believe push-based mapping systems have been dismissed.  They
are still a valid option, and one that could be pursued at any time.
Some of us made an initial evaluation that pull-based systems are
better, but with experience that might change, and it can.  

Push-based and pull-based systems can coexist as long as their
protocols aren't too constrained.  A push-based system can act as a
representative for the sites it serves and inject mapping information
for them into a pull-based system, and so on.  

APT default mappers are something like hybridization points between
push and pull, but there are control messages which bypass them, so
the parallel isn't really exact.

>   infrastructure because the direct route is unknown at that time.)

And a push-based system is either very "chatty" or its state is
decoupled from operational reality.  With a pull-based system you can
have the authoritative sources of information be directly coupled to
the operational liveness of the ETRs -- they can be the ETRs
themselves.  You can get this with a push-based system but only at the
cost of a lot of messages sent without actually knowing if the
information will be used.

A push-based system has extra equipment, and administration, as well.
They all do.

But this is all initial evaluation.  

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 2 Feb 2009 12:06:03 -0500

> this sort of disaster-prone analysis for LISP/ALT?

There is a concern about misconfiguration.  Certainly you want at
least doublechecking, and possibly signatures.

---

From: Scott Brim <[email-masked]>
Date: Mon, 2 Feb 2009 13:42:47 -0500

Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500:
> > According to your email to Robin, LISP/ALT currently makes the following
> > tradeoff:  Portability of EID prefixes is limited geographically in
> > order to curb path stretch along the ALT topology to the maximum that
> > can happen within a geographical region.
> >
> > That's possible, of course.  The cost is that networks scattered over
> > different parts of the world, such as those of enterprises with global
> > presence, cannot use a continuous address space internally -- even if
> > they all attach to the same provider.
> 
> cant they? I thought one of the nice things about the loc/id split was
> I could number my internals out of whatever I wanted, spread over
> creation and the attachment points were the only things that required
> aggregation, no?

Sure, but if one of your sites is in New Zealand, and has a prefix
where the physical ALT hierarchy is optimized for sites in Europe, a
source in New Zealand trying to contact your site would see more delay
during the Map-Request/Reply exchange, even though it they are in the
same town.  However, Map-Request/Reply exchanges don't happen very
often, and the delay will be low (round trip across the Internet).
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Feb 2009 10:55:43 -0800

> creation and the attachment points were the only things that required

Yes you can.

Dino

---

From: David Meyer <[email-masked]>
Date: Mon, 2 Feb 2009 12:31:16 -0800

> often, and the delay will be low (round trip across the Internet).

	Or not at all if you're not the first folks communicating
	between the sites.

	Dave

---

From: Scott Brim <[email-masked]>
Date: Mon, 2 Feb 2009 16:09:13 -0500

Excerpts from Brian E Carpenter on Tue, Feb 03, 2009 09:51:26AM +1300:
> 1. Large companies with their own international networks will
> surely never adopt a solution which doesn't allow them to have
> a straightforward, consistent and 100% internally managed
> addressing plan.
> 
> 2. They also won't adopt a solution in which local customers
> experience world-crossing delays for accessing local sites.
> They will use DNS tricks, redirects, CDNs, and overlay routing
> to get round this.
> 
> It's to be hoped that loc/id solutions such as LISP will be viewed
> as a help in this game rather than as a new enemy.

As John Z pointed out, the company has a lot of control over how this
is done.  With coordination between xTRs (in the case of ALT), the
Map-Request can go to a "near" one and the Map-Reply can carry a
specific answer.  Or not.  Complexity can be pushed outside, or be
placed in the company's edge (control only), or brought all the way in
to internal routing.  You choose your trade-off points.
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: John Zwiebel <[email-masked]>
Date: Mon, 2 Feb 2009 11:09:13 -1000

> 	Or not at all if you're not the first folks communicating

As dino said, you can.

Let's say the site was using 10/8

The xTR in Europe would advertise 10/8 into the ALT.
The xTR in NZ would advertise 10/8 into the ALT

If you're in NZ, your map-request would be routed over the ALT to  
that xTR
If you're in Europe, your map-request would be routed over the ALT to  
that xTR.

If it is desired, the EID owner can modify the RLOC advertisements so  
that
encapsulated data packets will go to the RLOC he wants them to.

If you want to move the EID-prefix to a different geographical  
location, (NZ to Timbuctu)
withdraw the route from NZ and start advertising it from Timbuctu.   
Yes the RLOC
will change.  The ALT hierarchy doesn't change.

---

From: David Meyer <[email-masked]>
Date: Mon, 2 Feb 2009 13:17:10 -0800

> A couple of points on this.
> 
  
	No doubt.

> They will use DNS tricks, redirects, CDNs, and overlay routing

	Again, no doubt.

> as a help in this game rather than as a new enemy.

	One would hope so.

	Dave

---

From: Robin Whittle <[email-masked]>
Date: Tue, 03 Feb 2009 13:18:14 +1100

Some of this discussion about the merits of LISP-ALT and of other
schemes is only happening on the RRG list and so is not on the other
lists crossposted in this reply.

  http://www.irtf.org/pipermail/rrg/

Hi Brian,

> a straightforward, consistent and 100% internally managed

I agree.  In my view, this means they want and need portable address
space.  I think placing "portable" anywhere near "address" in a
sentence makes some peoples' teeth itch, including especially
yourself!  But I think this is what networks want and need: stable
public address space they retain for year after year, and can use via
any ISP, ideally being able to split it up very finely between
multiple ISPs and to change which ISP they use it with - quickly and
with little cost to themselves or other people.

The core-edge separation schemes LISP, APT and Ivip all provide
portable address space, like PI space, but not handled directly by
BGP, not obtained in necessarily big chunks and probably obtained
from some company or other organisation, rather than directly from an
RIR.

Also, this new kind of space (I call it Scalable PI space) can be
sliced up much more finely by the scheme's mapping system, down to
the individual IP address, compared to the administrative limits
placed on BGP's finesse, such as /24 for IPv4.  (Ivip only goes to
/64 resolution for IPv6.)  This space will have initial and ongoing
costs, but it won't involve BGP expertise, BGP routers, being an AS etc.

> They will use DNS tricks, redirects, CDNs, and overlay routing

I agree.  This rules out the use of a core-edge separation scheme
with a global query server system (LISP-CONS, LISP-ALT and TRRP).
There are ways of caching the mapping closer to ITRs, but this raises
problems.

> as a help in this game rather than as a new enemy.

I tend to think that HIP is a real locator ID separation system.  I
don't think of LISP, APT or Ivip in these terms.

I think "Core edge separation scheme" is a better general term for
LISP, APT, Ivip and TRRP.  (Maybe RANGER too.)

But I agree - if LISP-ALT only provides a global query server system
and if it became "The Routing Scaling Solution" for solving the
routing scaling problem, then I think many people would consider the
delays and fragility of a global query server system sufficient
reason not to adopt the scheme.  Yet, in order to solve the routing
scaling problem, we need pretty much all end-user networks, large and
small (who want multihoming, portability etc.) to adopt the one scheme.

  - Robin

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 2 Feb 2009 22:22:21 -0500

> lists crossposted in this reply.

Can people please stop posting this discussion to 4 lists.

Regards
Marshall