Subject: [lisp] LCAF

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Sep 2013 03:51:00 -0400

I was reminded in recent discussion that the LCAF AFI is allowed both 
for RLOCs and for EIDs.

For RLOCs, I have raised the concern that when an ETR injects RLOCs 
using various LCAFs, it has no way to know whether the receiving ITRs 
will be able to understand the LCAF.  For some cases, this is actually a 
benefit.  But particularly if the structure within the LCAF gets more 
diverse, it seems to get difficult.  I do see the argument for 
flexibility here.

But then my naive participant head exploded when I tried to apply this 
to an EID.  Are all mapping systems required to handle all LCAFs?  At 
first, this seems reasonable.  As long as you are just doing pure prefix 
matching, it is just a variable length "address".

But then we see things which have internal mask lengths.  Or might need 
prefixing on multiple fields.  Or might have even more complex match 
criteria.

If the mapping system can always treat and LCAF EID as a prefix-matched 
bit string, I get it.  But if not, how is this supposed to work?

Sorry for a basic question,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Sep 2013 09:48:06 -0700

> I was reminded in recent discussion that the LCAF AFI is allowed both for RLOCs and for EIDs.
> 
> For RLOCs, I have raised the concern that when an ETR injects RLOCs using various LCAFs, it has no way to know whether the receiving ITRs will be able to understand the LCAF.  For some cases, this is actually a benefit.  But particularly if the structure within the LCAF gets more diverse, it seems to get difficult.  I do see the argument for flexibility here.

Right, agree.

> But then my naive participant head exploded when I tried to apply this to an EID.  Are all mapping systems required to handle all LCAFs?  At first, this seems reasonable.  As long as you are just doing pure prefix matching, it is just a variable length "address".

It can be worse Joel. It can be a non-contiguous address. 

> But then we see things which have internal mask lengths.  Or might need prefixing on multiple fields.  Or might have even more complex match criteria.

Right. Think of an extended-EID being just a prefix-tuple like a (S-prefix, G-prefix) entry. Or a flow entry that could look like this (S-prefix, D-prefix, sport=1024-65535, dport=*).

The pilot network today supports an instance-ID prefix or an (instance-ID, EID-prefix). The LISP-RE authors and the signal-less multicast stuff I have presented would require (S-prefix, G-prefix).

> If the mapping system can always treat and LCAF EID as a prefix-matched bit string, I get it.  But if not, how is this supposed to work?

I think it can work, but my gut is that it has to be treated as a n-tuple entity, rather than a string of bits. And if the n-tuple can be configured, then you could include < n elements in the n-tuple to delegate to child referrals.

I am wondering if the DHT advocates on this list believe that DHTs make this simpler (or even harder).

Dino

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