Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specification of LISP+ALT

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Dec 2009 12:51:39 -0500 (EST)

> From: David Meyer <[email-masked]>

    > On Wed, Dec 02, 2009 at 12:06:13PM -0500, Margaret Wasserman wrote:

    >> it is still true that if the ITR has an entry for the shorter prefix,
    >> it will never do a mapping lookup for the longer prefix, so it will
    >> never see the second answer with the different weights...

    > There are basically three mechanisms we've talked about to handle this
    > case (and the case Joel pointed out):
    >   - An xTR that changes its policy [0] can send SMRs
    >   - An ITR can use RLOC-probing to learn new mappings
    >   - or the TTL on the cache entry can time out and the ITR
    >     the ITR will send a map-request on the next packet

Perhaps I'm not understanding you, or I'm not understating Margaret, but it
seems to me that the mechanisms you mention don't solve Margaret's problem,
which is that if two mappings exist:

    >>>     a.b.c.d/n -> rloc.1
    >>>     a.b.c.d/m -> rloc.2
    >>>  where (n < m) && (rloc.1 !=3D rloc.2)

and the first mapping gets looked up and cached in an ITR, that ITR _will
never even ask for the second mapping_, since it thinks the mapping it
already has (the first one) satisfies any requests for mappings that might be
covered by the second entry.

The mechanisms you mention cover places where the existing cached mapping is
old/incorrect, and needs to be refreshed updated. However, assuming the first
mapping never changes, then none of the mechanisms you mention will ever do
anything - they will just reload the same first mapping.

However... her usage example (below) turned the light bulb on in my head as
to what the _real_ problem is (in abstract terms), and once I understood
that, the answer is 'simple'.

See following message for an extended muse on that subject.

	Noel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 2 Dec 2009 10:05:38 -0800

> covered by the second entry.

So to restate we have 3 ways for that ITR (usually an xTR) to not think
that the mapping it already has is valid.

The xTR may receive an ECM with the SMR bit set from the site who has
changed its policy.
The xTR mapping's TTL times out so th
The xTR happens to probe the remote site and learns that things have
changed.

> old/incorrect,

That's exactly the case we're talking about! :-)

 and needs to be refreshed updated. However, 
> assuming the first
> mapping never changes, 

The ITR has no idea if the existing mapping it has is valid or not!

then none of the mechanisms you 
> mention will ever do

Nope, they will go ask the ETR for an authoritative mapping whitch will
overwrite the ITR's existing mapping.

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Dec 2009 13:26:29 -0500

Darrel, I don't think that's quite the case we're talking about.

The overlapping prefix case is something like

I as an ETR want to express that 10.0.0.0/8 should go to RLOC set a
except for 10.1.0.0/16, which goes to RLOC set b.  This style of mapping
is the case where you have overlapping prefixes.

ZLisp at least will parse multiple records in a map reply, and will
accept any that dominate (are shorter than) the prefix it requested.
So, if an ETR sent back both map records above, it would accept both
mappings.

Other mechanisms we have for dealing with this case include:

1) "Don't do that." deaggregate if you are in that situation

2) If your data plane notices someone sending to a and you wish they
were sending to b, then SMR them in the control plane.  Then you can
give them a longer prefix when you get their map request.  Assuming that
a router who knows the mapping is for too short of a prefix gets a
packet, this "works" although it's kind of ugly.

3) Things mostly just work if the ITR happens to send a part of the
address space that has the long prefix.  I say mostly, because the spec
currently says that a shorter prefix replaces a longer one in the map
cache, so if you ever send to a part of the EID space that has the short
prefix, it will replace the long prefix you already have.  I think more
thought needs to be put into this section of the spec, and perhaps short
map replies should not replace longer prefix map replies that have
already been verified.

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 10:42:01 -0800

Sam,

> So, if an ETR sent back both map records above, it would accept both

	Since a (IPv4) map-request is sent for a /32 (inner DA in
	a ECM, outer DA if its on the ALT), everything returned
	will be equal-to or shorter than the requested EID
	prefix. So I don't understand what you exactly what you
	mean in the above paragraph. Can you give us a little
	more on what you're trying to say?

	Thanks,

	Dave

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Dec 2009 15:42:47 -0500

>>>>> "David" == David Meyer <[email-masked]> writes:

    David> 	Sam, I'm trying to understand what you mean in this
    David> paragraph:

    >> ZLisp at least will parse multiple records in a map reply, and
    >> will accept any that dominate (are shorter than) the prefix it
    >> requested.  So, if an ETR sent back both map records above, it
    >> would accept both mappings.

    David> 	Since a (IPv4) map-request is sent for a /32 (inner DA
    David> in a ECM, outer DA if its on the ALT), everything returned
    David> will be equal-to or shorter than the requested EID prefix. So
    David> I don't understand what you exactly what you mean in the
    David> above paragraph. Can you give us a little more on what you're
    David> trying to say?

It's not always true that a map request will be for a /32 or /128. A map
request record contains a prefix element. Our code does fill in the inner
destination address from this prefix, but when actually responding to a
map request, it uses the requested prefix in the map request record
*not* the inner DA.  When creating a new map cache entry we do use a /32
or /128.  However when sending a map request where we have a valid entry
(revalidation) we'll use the prefix from the cache entry.

For the first record in a map reply, we'll accept the map reply if:

* The reply prefix is the same as the requested prefix

* The reply prefix contains the requested prefix

For additional map records, we'll also accept the update if the reply
prefix is contained in the prefix of the first map record.

So, examples.
wef we ask for 10.0.0.1/32 and you reply with 11.0.0.0/8 (you didn't answer
the question we asked), we'll reject.

wef we ask for 10.0.0.0/8 and you reply with 10.0.0.0/16,we'll continue
using our existing entry until it expires and then time out.  When we next
ask the question we'll ask with a /32 and accept a /8 reply if that's the
response we get.  The fact that we reject the reply in this case is quite
possibly undesirable.

wef we ask for 10.0.0.1/32 and get a reply containing 10.0.0.0/8 and
10.1.0.0/16, we'll accept both.

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 13:33:59 -0800

> (revalidation) we'll use the prefix from the cache entry.

	Gotcha, thnx.

	Dave