I understand the importance of experimenting. But I am having trouble
getting my head around the possible value we want to explore. Color me
naive and stubborn, but individually so.
Thinking about the ITR code path, if there is no block:
Receive packet
check cache for destination
failing cache match, query for destination.
And the ITR code path if there is a block:
Receive packet
check cache for destiantion
failing cache match, check for destination in EID block
If in EID block, query
If not in EID block, query
Now, if everything is in the EID block, I understand that the last step
above becomes "just send". But that appears to be a counter-factual
assumption.
Yours,
Joel
On 10/31/13 7:19 PM, Dino Farinacci wrote:
Actually, that use case is only helped by the EID block if you can
be sure that ALL the destination EIDs it will see will come from
the block.
I don't believe so. It could just an efficiency play for one versus
the other.
Which seems to be impossible to ensure in the general case. And
easy to achieve without an allocated block in many of the special
cases.
Well the EID could mean it is behind a NAT and that ITRs should
encapsulate to an RTR. Maybe one that is used by a default map-cache
entry or a distinguished key on the mapping database.
See there are sorts of things we could try. Again, "try" here means
experimentation.
Look how the pilot network was easier to debug since we had
153.16.0.0/16 generically donated by Andrew Partan and how cisco has
been renting 2610:d0::/32.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
