Hi Dino, Thanks for the reply, follow-up clarification inline (PJ>>>),
On 1/10/23, 3:24 PM, "Dino Farinacci" <[email protected] <mailto:[email protected]>> wrote: > • (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. PJ>>> As per current draft, both options are available, however we are open to discuss and conclude it either way for the best solution. Would like to hear if any other opinion on this. > • (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. PJ>>> Ok, will clarify. Parenthetical comment is the text from the draft for the EIDs not registered to the mapping system which can be encapsulated to pETRs (implementation can still choose what to encapsulate at ITR), its not the definition of 'non-EIDs'. 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. PJ>>> Correct. Thanks, Prakash _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
