Re: [lisp] Please Review 6830bis and 6833bis

["Joel M. Halpern" <[e-mail]>]

Dino, I am missing something.
If, as we both seem to be saying, the "policy-denied" response can go 
with any of the existing actions, how is the receiver to know which is 
intended by the responder?

Yours,
Joel


On 3/12/17 9:19 PM, Dino Farinacci wrote:
>> <participant Given taht the only error code field we have in the
>> map reply is the ACT field, I see why you want values for ACT to
>> represent these meanings.
>
> Right. It can be used to give additional information about the
> mapping database lookup.
>
>> As a minor point, the two new replies need to specify what the
>> action should be for each of them.
>
> Sure, I can right that text. It is obvious but does need to be
> spec’ed. It means that the ITR/PITR will drop packets since there is
> no RLOC-set. And follow the typical map-cache maintenance procedures
> for refreshing entries.
>
>> The bigger problem is that it is not clear that "policy-denied"
>> always goes with one of the existing 4 actions.
>
> The “Action” field is a bit of instruction that the mapping database
> lookup system provides.
>
>> (I have trouble constructing a policy-denied:Send-Map_Request, but
>> I can see cases for the other three.)
>
> Here is an example:
>
> (1) Dino (an xTR) registers an EID. (2) The registration policy
> indicates that Joel (an xTR) can only talk to me on weekends. (3) On
> Monday an EID behind you requests to talk to an EID behind me. The
> mapping systems returns to Joel the RLOC-set “Dino” and you can encap
> to me. (4) If that EID is sending the the EID behind me tonight, the
> mapping system returns an empty RLOC-set with Action
> “policy-denied”. (5) You can cache this fact in your map-cache and
> obviously have no where to encap to since an RLOC-set was not
> returned.
>
> So, in a nutshell, this is a {source, destination} based access-list
> that is enforced in the mapping system versus implemented in the
> data-plane in the encapsulator.
>
>> In contrast, since in the authentication failure case the
>> responding ETR has no idea who the ITR is, "No-Action" seems the
>> right behavior.
>
> “No-Action” is a default action type when there is no other error
> reason to return. Hence the desire to return more specific reasons
> for lookup failure or instructions the ITR should do on lookup
> success.
>
> Dino
>
>
>