On 1 Nov. 2013, at 07:33 , Dino Farinacci <[email protected]> wrote:
>> 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
>
> You are correct, but this box could be configured in way where the logic
> could change:
>
> Receive packet
> If EID-block strict configured
> If destination in EID-block, send query
> Else forward natively
> Else
> <do what Joel said above with no EID-block check>
> Endif
You can also do more complex thing. During the resolution delay (the time a
map-reply comes back) you can have different policies depending on the
destination.
For instance, if it is an EID block you can send toward a PITR or drop if you
think that PITR adds too much path stretch.
Or during the resolution delay of a non-EID block destination you forward
toward a PETR or just natively.
Luigi
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
