Subject: [lisp] Discussing LISP deployment

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Aug 2009 07:06:56 -0400

Folks, both as a chair and individual participant I'm finding that my
lack of understanding of how LISP is being deployed is making it
impossible for me to reason about most if not all of the issues we're
discussing or that I'd like to bring up.  I don't think we're 100%
wedged on the UDP checksum issue based on understanding deployment,
although I do expect I won't be able to make any final consensus call
without understanding where LISP will be deployed.  For most
everything else, I am even more dependent on understanding deployment.

Darrel and I are trying to organize a discussion on this but are
blocked on getting some input from the ADs about IETF procedures.

I just wanted to let the WG know that I at least think this is going
to be a really important discussion and may block our work.

Here are examples of the sorts of questions I cannot answer.  Please
don't try to answer these one-at-a-time.  I think we really need an
organized discussion of how the entire thing all fits together; I'm
listing these as things I want to learn by the end, not as things that
I think can be answered separately.

* Why does LISP need to work through NATs
* Why does LISP need to run on high-end routers at sufficient speed that hardware concerns matter?
* Why does LISP need to run on low-end CPEs/home gateways?
* Where are the organizational boundaries between a MS and its clients
* Where are the organizational boundaries between the MR and its clients
* How far down the scale should LISP expect to be deployed?  Homes? 1-person businesses? 50? 100?
* How far up the scale should LISP expect to be deployed?
* How does an XTR get RLOC-side connectivity
** link type
** provisioning 
** Does the ISP know LISP is being used? Go along with it?
* Where does LISP run? CPE? PE? P? C?
* How much do we care about LISP over V4? V6?

Again, I don't think answering those questions singly would help.
Clearly we could say that LISP needs to run everywhere in the network,
on all equipment, from my house up through IBM and Oracle, for V4 and
V6, supporting everything from RFC 1149 through multiple 10G links in
a LAG.  However if we say that, we'll produce bad results because
evaluating tradeoffs will be impossible.  I also fully realize that
we'll probably not answer some of the questions I asked and have
incomplete answers for others.  Finally, I realize that real-world
deployment will take its own path.  What I'm trying to do is get our
operating assumptions about deployment so we can make hard choices in
the sort of sticky situations we find ourselves in with UDP.

It's my opinion that what we have in the specs right now has an
implied deployment model that is not self-consistent.  The tradeoffs
that are being made don't seem to fit together consistently.  However
rather than point out what I think are inconsistencies I'd rather
learn from the people who wrote that document what they were thinking
and then toss that around in a energetic but productive discussion
until we get what the WG is thinking out.  Then go back and make sure
the spec aligns with the WG.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 22 Aug 2009 09:53:29 -0700

I am going to answer them briefly one by one because the answers are  
very simple.

> * Why does LISP need to work through NATs

Because you want to multi-home at a residence of a branch office which  
uses private addresses.

> that hardware concerns matter?

Because a LISP site can be a data center with lots of high-bandwidth  
connectivity to the core network.

> * Why does LISP need to run on low-end CPEs/home gateways?

Same answer for the first questions.

> * Where are the organizational boundaries between a MS and its clients

We don't know yet, but the architecture is flexible enough to put it  
anywhere. Can be third-party, government, SPs, IXCs, clouds, cachers,  
DNS root server vendors, etc.

> * Where are the organizational boundaries between the MR and its  

Same as last answer but can be modeled similar to the DNS hierarchy.

> 1-person businesses? 50? 100?

Where low-cost multi-homing is desirable. I run it at my house and  
enjoy active-active multi-homing both for ingress and egress traffic  
flow.

> * How far up the scale should LISP expect to be deployed?

I don't understand the question. Can be interpreted many ways so I  
don't want to guess what you are asking.

> * How does an XTR get RLOC-side connectivity

The same way a CPE router does today.

> ** Does the ISP know LISP is being used? Go along with it?

No, unless it is providing/selling mapping services to the site. Or  
offering PTR services for its customers.

> * Where does LISP run? CPE? PE? P? C?

CPE for loc/id split reasons. But inter-domain TE is important among  
SPs so other level of LISP could be run. That is an ISP could deploy  
TE-ITRs and TE-ETRs. These would likely be P routers or routers that  
are used at peering points between SPs.

> * How much do we care about LISP over V4? V6?

Since the host stacks have good IPv6 support, I envision we could  
deploy IPv6 by using LISP at sites with IPv6 EIDs and have sites  
reachable via IPv4 locators. So v6-in-v4 would make this work.

And sine we what to scale the IPv4 Internet as we know it today, v4-in- 
v4 will obviously have to be supported.

Using IPv6 as an outer header depends on native IPv6 intermediate  
connectivity. I just say though, we have done a lot of work to make  
IPv6 work on the LISP test network. So it's not an either or sort of  
situation. LISP is helping both address-families routing architecture  
scale.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Aug 2009 14:02:53 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> I am going to answer them briefly one by one because the
    Dino> answers are very simple.

Dino, thanks for trying. Your answers were not as simple as you
thought they were: they were neither obviously correct nor
sufficiently clear that I understood them.  I could probably engage in
a rapid fire discussion that would leave us both frustrated, but I
think it would be better to wait until we can discuss something more
organized.  I do appreciate the response though.

Speaking only for myself; I'm definitely not trying to discourage
others from discussing.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 22 Aug 2009 11:11:41 -0700

> organized.  I do appreciate the response though.

Sure, no problem.

> Speaking only for myself; I'm definitely not trying to discourage

Discuss away.

Dino