> 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.
There must have been a typo here. PubSub should absolutely be in the spec. I was referring to SMRs, it is the mechanisms that is slow and uses more network bandwidth than PubSub. > >> • (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. Well EIDs not registered could be a part of an EID-prefix that IS registered. So the best way to describe this is, if a destination IP address from a packet header is looked up, and a negative map-reply is returned, the ITR for sure knows the destination address IS NOT an EID. But the 2 bullets below cover all 3 situations (an EID destination, an EID not registered yet, and a non-EID). > 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. Good. That is the algorithm and it works. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
