Subject: Re: [lisp] uRPF as a possible solution

From: [email-masked] (Noel Chiappa)
Date: Mon, 25 Jul 2011 16:40:19 -0400 (EDT)

> From: Jeff Wheeler <[email-masked]>

    > in the case of the PITR is it can be responsible for less than the entire
    > destination address space; but an ITR could also be implemented that way.

I'm not so sure - a small/medium size site might have two ITRs (or a small
number of them), and in those cases responsbility for covering the address
space could be divided between them, but many smaller sites will only have one
(their exit router).

	Noel

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 25 Jul 2011 16:56:47 -0400

> space could be divided between them, but many smaller sites will only have one

I agree.  However, if the solution for ITR cache churn is to "Hail
Mary" the packets up to the native Internet (assuming native
connectivity for that Address Family is even available) then these
packets must find their way to an xTR that can handle the traffic, or
they will be dropped.  This must be the very powerful router (or
cluster) that some have mentioned -- but you have to be able to build
and sell it at practical size, power/heat properties, and price.

So saying this traffic can simply be forwarded natively and handled by
a PITR is not a solution unless there are practical PITRs with enough
capacity.  The fundamental problem of data-plane/FIB scaling remains
the same.  In addition, if there were no IPv6 connectivity available
to the ITR, it could not do native forwarding with hopes of reaching a
PITR.  It's a good thing IPv6 will probably be deployed everywhere
long before LISP is a practical concern, but this exemplifies the fact
that the current design of LISP may not be able to live up to its
promise of an all-purpose encapsulation scheme able to carry any
protocol within the outer-headers, without native support for that
protocol/AF to the site.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jul 2011 14:34:06 -0700

Just as a point of differentiation, LISP is trying
to do map-and-encaps over the wide area, whereas
IRON is doing it within a bounded organization with
native Internet routing over the wide area. So, LISP
is an "inter-site" map-and-encaps system where IRON
is an "intra-site" system (for some definition of
"site"). I think some of the issues being discussed
here are exacerbaed by that design departure.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 14:49:41 -0700

Guys, if you want to throw around solutions and brainstorm on the list, you need to be open minded. We are not proposing anything, we are discussing pros and cons of possible ways to solve problem. Do not take this as "how LISP solves the problem". We have lots of options, but understand how they cannot be perfect.

Hence, why they are not documented right now.

Dino

On Jul 25, 2011, at 1:56 PM, Jeff Wheeler wrote:

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