> • (Dino): Elaborate on the update mechanisms/message types ( legacy > LISP or pub-sub preferred??). > (Authors): A shorter TTL would be a simple measure to allow update in non > pub-sub (Standard/Legacy LISP) mode. With pub-sub, N-bit would be set in a > Map-Request, then Map-Notify messages would be sent to subscribed ITRs as per > the PubSub specification. With pub-sub, later option could be preferred as it > would be faster.
I don't believe we should have a non PubSub option. Its what we have now to update xTRs map-caches. Its slow and we can do better. Since we have PubSub in a mature state, we should have this design depend on it fully. > • (Padma): Elaborate of how pETR map-reply would be installed/used at > ITR (so that no forwarding inefficiencies to send every packet to pxTR) > (Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs > destinations (for both “EIDs not registered with the Mapping System, or > simply are not known" as mentioned in the draft) since more specific entries > would already be present for known overlay subnets/EID-block-range at ITR to > generate map-request. EIDs not registered are not non-EIDs. Destinations that are unknown are non-EIDs. Your parantetical comment is misleading. What we agreed on was this: (1) Define an EID-block. Destinations that match this block are map-requested. (2) Destinations not in an EID-block are non-EIDs and are encapsulated to the pETR. How do you implement this, really simple: (1) You have a default map-cache entry with RLOCs of the pETRs. Once you determine their RLOCs, the ITR installs the default map-cache entry. So non-EID destinations will match this entry. (2) You put the EID-block as an EID-prefix, at configuraiton time, static in the map-cache, that when matched, sends a map-request. So EID destinatinos will match this entry. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
