Re: [lisp] LCAF

> 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

> 
> Sorry for a basic question,
> Joel
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp