> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
