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

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

> From: Dino Farinacci <[email-masked]>

    > In an ITR-only system, we need the database-mapping command to know
    > which packets are candidates for encapsulation

I suspect that that is, in part, because you're working with an
operational model where your xTRs are immersed in a sea of 'normal'
Internet around them, and the LISP 'backbone' is totally virtual. I.e.
there is no such thing as '_the_ interface to the LISP backbone'.

I am really hoping that we soon get to the point where there really _is_ a
'LISP backbone', on which the only routes that circulate at for RLOCs,
etc. But I digress...

    > The ITRs also use the "database-mapping" command for setting
    > locator-status-bits for packets they encapsulate.

Yeah, that I can understand - although presumably they have to have some
mechanism to monitor their neighbour xTRs so they can make sure the
Locator-Status-bits are filled in with good, up-to-date, info.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Jan 2010 17:19:17 -0500

I thought we could use the appropriate negative response from the ALT to 
determine that there was no such EID, and therefore the ITR would know 
to send the packet(s) normally for that destination address from then 
on?  (This does mean that packets to the regular Internet incur a higher 
probability of needing a query, unless we can somehow generate negative 
blocks (which we can't in the current format, as the negative has no 
block as I udnerstand it.)

Thanks,
Joel

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

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 12 Jan 2010 15:09:20 -0800

> on?  (

Yes.

This does mean that packets to the regular Internet 
> incur a higher 
> blocks 

No higher than positive entries...

>(which we can't in the current format, as the negative has no 

The negative block is infered by the 'holes' in the alt routing table.