Subject: [lisp] LCAF question

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 15 Sep 2013 11:17:52 -0400

It seems to me that there are three related technical problems or 
general concerns.

1) We need to be clear about which LCAFs can be used as EIDs, which as 
RLOC, and which as both.

2) We need to be clear about how the mapping system is to support any 
given LCAF as an EID.  For Example, if one prohibits the IID mask length 
then an IID + Address LCAF can be be supported by the mapping system as 
a simple prefix.  But, if we have to match on both IID prefixes and 
Address prefixes then this requires more support from the mapping system.
2a) Specifically, for any LCAF on which there can be multiple partial 
matches we have to specify what "longest match" means.  Does longer IID 
trump longer Address?

3) If we have LCAFs for EIDs which need support from the mapping system 
then the EID needs to know what LCAFs the mapping system supports.  It 
seems likely that special-purpose cases will use separate mapping 
systems tied to separate authorities.  But how will the ETR that is 
registering or the ITR that is asking know which mapping system supports 
which set?  Configuration seems a VERY bad answer.

Note that this is separate from the question of whether an ETR using a 
complex LCAF RLOC can reasonably expect the ITR to understand it.

Comments, opinions, or rotten tomatoes?

Yours,
Joel M. Halpern

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 15 Sep 2013 21:13:33 +0200

On Sun, Sep 15, 2013 at 5:17 PM, Joel M. Halpern <[email-masked]> wrote:
<snip>
> 1) We need to be clear about which LCAFs can be used as EIDs, which as RLOC,
> and which as both.

If we're not clear it will lead to confusing later on, or no
deployment because no one know what todo. Another scenario are that we
get issue to get different vendors to talk with each other.... and
some more issues.
All in all, either should all LCAF work for all cases, or some
indicator, or some sort of table to indicate what can work where.

<snip>
> complex LCAF RLOC can reasonably expect the ITR to understand it.

Either way we need a clear understanding of how LCAF are to be
understood by different part of the systems.

> Comments, opinions, or rotten tomatoes?

what about onions?;)

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Sep 2013 10:41:19 -0700

> It seems to me that there are three related technical problems or general concerns.
> 
> 1) We need to be clear about which LCAFs can be used as EIDs, which as RLOC, and which as both.

That is made clear in the LCAF draft but the companion document should provide detail as to why.

> 2) We need to be clear about how the mapping system is to support any given LCAF as an EID.  For Example, if one prohibits the IID mask length then an IID + Address LCAF can be be supported by the mapping system as a simple prefix.  But, if we have to match on both IID prefixes and Address prefixes then this requires more support from the mapping system.

An IID mask-length is only implemented by the nodes that do LISP-DDT. Because they are delegating ranges of the instance-ID space to child DDT-nodes (including a DDT-node enabled map-server). So the xTRs don't need to worry about this.

> 2a) Specifically, for any LCAF on which there can be multiple partial matches we have to specify what "longest match" means.  Does longer IID trump longer Address?

We have found cases where something like an IID is a bit-extension of an address so you can do longest match when you concatenate the instance-ID and the power-of-2 EID-prefix. We have found cases where an ordering is necessary such as in a Multicast Info Type that can be encoded as (S-prefix, G-prefix) as well as an Application Data Type that can be encoded with all of (S-prefix, D-prefix, sport-range, dport-range).

> 3) If we have LCAFs for EIDs which need support from the mapping system then the EID needs to know what LCAFs the mapping system supports.  It seems likely that special-purpose cases will use separate mapping systems tied to separate authorities.  But how will the ETR that is registering or the ITR that is asking know which mapping system supports which set?  Configuration seems a VERY bad answer.

Well we do have this flexible message that xTRs send to a mapping system called Info-Request and Info-Reply. So it could ask.

> Note that this is separate from the question of whether an ETR using a complex LCAF RLOC can reasonably expect the ITR to understand it.
> 

So from public opinion and many private email exchanges, I am getting the impression that the simple encoding of the Capabilities Type may not be useful enough and that the more complex combinations are dependent on the feature being implemented.

So I would like to leave the Capabilities Type LCAF out of the -03 so we can have more discussion. 

Any objections if I publish what I posted last week. Here is the latest diff.

Dino

> 
> Yours,
> Joel M. Halpern
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Sep 2013 09:15:26 +0300

Hi Dino,

> So I would like to leave the Capabilities Type LCAF out of the -03 so we can have more discussion. 

Agree,
Sander]