Subject: Re: [lisp] Design discussion -06-(3) -> returnalloverlapping prefixes

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Jan 2010 17:04:48 -0500 (EST)

> From: Luigi Iannone <[email-masked]>

    >>>> ITRs could refuse to forward traffic from sources they are not
    >>>> supposed to handle, but the problem is 'how do they know what
    >>>> sources they are supposed to be handling'?

Well, you all may understand this, but I'm still sort of confused. :-) So let
me try this again. (Although, to be brutally honest, I have now forgotten what
the basic point was here! Was it something about DoS attacks, maybe?)

    > AFAIK the Cisco and the OpenLISP implementations do the check on the
    > ITRs.

Yes, _if_ your ITR is configured with the EID ranges it should
accept/process/encapsulate traffic for, for whatever reason it has that
configuration (perhaps it's also an ETR), then yes, you can do such a check.

However, I'm still not sure I understand why a box which is just an ITR
would _have_ to have such information configured - and if it is a
requirement, we need to document that in the spec at some point.

I mean, I can imagine an ITR which is only configured with 'this is the
local, non-LISP-encapsulated interface', 'this is the external,
LISP-encapsulated interface', along with appropriate initial configuration
(e.g. the address(es) of Map-Resolvers, etc). That configuration might
even be implicit, as it is with the small NAT/router boxes that are sold
today, which come wiht a 'WAN interface' port and 'LAN interface' ports.

    > Further, even if the ITRs are not authoritative in replying to
    > Map-Request

Umm, ITRs don't reply to Map-Requests?

    > they still have the knowledge, since they have to have an entry in
    > the LISP Database

Why/where does an ITR appear in any LISP database?

    > otherwise how would an ITR select which RLOC to use as a source RLOC?

A simple ITR would just use its WAN interface address as its RLOC, no?

Yes, more complicated configurations (e.g. an ITR supports a number of a
different sites, and has some reason to use different RLOCs for each site)
would need something more complicated, but that's just gratuitous
complexity...

	Noel

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 13 Jan 2010 09:59:37 +0100

Hi Noel,

> today, which come wiht a 'WAN interface' port and 'LAN interface' ports.

So, basically you are proposing that traffic coming from interface X is encapsulated (no matter what) by using a mapping in the cache (if it is the first packet then you query the mapping system).

Do I understand correctly?

Assuming this is what you mean, in the current spec there is not such a thing. Nowhere is written that you can use interfaces to decide whether to encap or not.

My understanding of the specs is that you use a mapping from the database to select the outgoing interface (RLOC).
There can be some routing issues, i.e. the source RLOC should be consistent with the outgoing interface if several interfaces/RLOC are available. But let's keep it simple

What if you have 2 EID-Prefix behind a single router with a single "local" interface and two RLOCs but for any reason you want that each EID-Prefix is sent out from different RLOCs?

Don't we need a mapping for that?

In OpenLISP we first check if a mapping is available in the database, if the source address is covered by a mapping in the database then the packet is suitable for encap.

Then we check the cache. Let's assume there is a mapping for the destination EID. We select an RLOC based on priority/weight.

We check then the routing table to see which is the outgoing interface for the selected destination RLOC and we check if the address (or one of the addresses)  of the selected outgoing interface is in the set of RLOCs of the mapping that has been found in the database. 
If everything is ok packet is encapsulated and sent.

Hope the procedure that I described is clear.

May be Dino can clarify if this is the intended behaviour or I misinterpreted something.

Ciao

Luigi 

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Jan 2010 22:34:37 -0800

> misinterpreted something.

You cannot do source interface based decisions. You want packets to  
come into a CPE router on an interface for both hosts that are  
addressed from EID space and from RLOC space.

The spec is written to allow this. Also, you want to allow this CPE  
router to route packets for all combinations of local traffic within a  
site:

(1) source-EID to destination-EID
(2) source-EID to destination-RLOC
(3) source-RLOC to destination-RLOC
(4) source-RLOC to destination-EID

Dino