The cost per EID-record is 12 bytes plus size of the EID address and for an RLOC-record is 12 bytes plus size of the RLOC address. This assumes you use AFI=2. Not what the draft is proposing.
Dino # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | Record TTL | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | Locator Count | EID mask-len | ACT |A|I| Reserved | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # |SigCnt | Map Version Number | EID-AFI | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | EID-prefix ... | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # /| Priority | Weight | M Priority | M Weight | # L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # o | Unused Flags |L|p|R| Loc-AFI | # c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # \| Locator | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > On Mar 5, 2018, at 6:23 PM, Tom Herbert <[email protected]> wrote: > > On Mon, Mar 5, 2018 at 5:00 PM, Dino Farinacci <[email protected]> wrote: >>> Looking at the map-reply message format, I am concerned about its >>> size. By my count, it's 40 bytes to provide one record with one >>> locator where record and locator are 8 bytes. If we need to scale a >>> system to billions of nodes this overhead could be an issue even if >>> it's the control plane. Is there any plan to have a compressed version >>> of this. For instance ,if there is only one RLOC returned wouldn't the >>> priorities and weights be useless? >> >> My comment about this spec is that you really don’t need a LCAF format to >> format the addresses. You can use AFI=2 and use IPv6 format. That will >> reduce the size. >> >> But if you start compressing out fields, reality will set in and new >> features will be added and you’ll be back where we started. You want to >> multi-home, don’t you? > > There are a bunch of reserved and unused flag bits in the message > format. One could define flag-fields to make the messages extensible > and variable length (without resorting to TLVs!). > > Tom _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
