Hi Dino, Thanks for the reply! More inline.
> On Apr 18, 2016, at 8:36 PM, Dino Farinacci <[email protected]> wrote: > >> I would take Florin¹s point one step further: IID has become a critical >> part of an EID, as also obvious from the DDT draft. Even today, when there >> is no IID LCAF on wire, we are assuming an IID exists, and the value is 0. >> An alternative is to just consider adding it as part of the EID record (in >> LISP messages), instead of having it as an LCAF. > > Well the EID-record in a Map-Request looks like this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Reserved | EID mask-len | EID-Prefix-AFI | > Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | EID-Prefix ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > And a EID-record in a Map-Reply, Map-Register, and Map-Notify looks like this: > > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Record TTL | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > R | Locator Count | EID mask-len | ACT |A| Reserved | > e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > c | Rsvd | Map-Version Number | EID-Prefix-AFI | > o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > r | EID-Prefix | > d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | /| Priority | Weight | M Priority | M Weight | > | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | o | Unused Flags |L|p|R| Loc-AFI | > | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | \| Locator | > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So finding 24-bits in reserved fields is not only costly, not available and > doesn’t allow future single bit allocations, not to mention the huge complex > compatibility problem we would have, I wouldn’t suggest going this route. > > So one should ask, for an EID lookup, or a lookup key, what else would you > want to accompany the EID with? If it is going to be a multi-tuple lookup, > you are going to need an AFI-List Type encoding anyways. I guess you mean this as a fallback mechanism. IMHO this is optional, deployment dependent. > But for the typical lookup of (<iid>, <eid>) and (<iid, <seid>, <group-eid>) > the Instance-ID > Type works for the former and the Multicast-Info Type works for the later. > > So I would like to hear why you would use a nested LCAF for an (<iid>, <eid>) > lookup? MAC and Source/Dest would be straight forward examples but I think this holds for Types 4, 6 and 14 as well. That is, all types where tenant separation would make sense. Probably it’s not something we’d want for LCAFs meant to be used as RLOCs. At first sight, this seemed to be a simple improvement that could simplify control plane message processing. But you’re right in that backwards compatibility or support for all useful LCAF combinations make implementing the needed changes rather difficult. Thanks, Florin > > Dino > > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
