Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP]

From: [email-masked] (Noel Chiappa)
Date: Mon, 2 Apr 2007 09:31:39 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > What is the difference between (a) using LISP between two PI sites over
    > some piece of ISP locator space and (b) a PPVPN between those two sites?

If those two sites are only talking to each other, then at a high level
(ignoring protocol details), not much.

The point, of course, is that LISP is supposed to allow those two sites to
talk, not just to each other, but to the rest of the network - something you
couldn't accomplish with PPVPN's without N^2 of them.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 02 Apr 2007 06:42:07 -0700

Noel,

> couldn't accomplish with PPVPN's without N^2 of them.

"N^2 of them". What are these "N^2" ?

Yakov.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 2 Apr 2007 08:10:26 -0700

>From: Yakov Rekhter [mailto:[email-masked]] 

If the ISPs place the tunnel end points at their customers' premises,
like the PE-CE boundary of L3VPN, then there are indeed N**2 tunnels and
the approach will not scale, IMO. 

If the ISPs place the tunnel end points at their own boundary with other
ISPs, and aggregate the traffic of their customers to that boundary,
then the number is a function of the number of ISPs -- ISP**2.

However, I expect the ISPs to form confederations to provide
differentiated service distinctions to support L3VPN services, in
addition to supporting LISP (i.e., many different services will be
provided). In this case, the number of tunnels is a function of the
number of ISP confederations, which is Confederation**2.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Apr 2007 10:15:45 -0700

> the approach will not scale, IMO.

There are not N^2 tunnels. In fact, the term "tunnel" might be too  
strong a term  because it can convey some static nature of using this  
mechanism.

In LISP, you can view the tunneling part simply as a "encapsulation"  
which requires no control-plane state.

The state and size used for the "EID-cache" is only for the aggregate  
flows that are flowing through the ITR. It is very much on-demand.

I really believe the model will have to be 3-way hybrid, that is:

o You push the aggregateable allocation prefixes to high-level entities.
o Those *can* be pushed to ITRs, which store such mappings *only* in
   control-plane memory. Or the ITRs can do a lower-latency request/ 
reply
   transaction to the higher-level entities.
o The forwarding cache contains EID-prefix to RLOC encapsulation  
mappings
   for on demand destinations.

And for Ross's concern, when you match the "default route" in the  
ITR, that means the destination is global (or outside of your site),  
so you then do either another table lookup in the EID-cache, or you  
put the EID-prefixes in the same FIB so longest match finds them  
before the default route.

Dino