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

[Dino Farinacci <[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?

I don’t think it does. Let’s look at each existing action:

>   (0) No-Action

This action code comes with a RLOC-set and tells an ITR to encapsulate to RLOCs in the RLOC-set. This is certainly not denying anything.

>   (1) Natively-Forward

This is an action code that tells the ITR that the EID it requested is not in the mapping system and could be a non-EID and the address is routable in the underlay. This is certainly not denying anything.

>   (2) Send-Map-Request

This action code could be returned when overlapping EID-prefixes are registered to the mapping system. This is an instruction from the Map-Replier (either from an ETR or a map-server) that a longest match lookup that matches this entry should invoke a Map-Request.

>   (3) Drop

This action code is telling the ITR to drop packets, but has no specific reason for doing so.

The two new action codes I am proposing (and if others think there could be more, please suggest them):

(4) Policy-Denied

An access-list violation is denied and the requestor must not get the RLOC-set due to the policy configured in the ETR or Map-Server.

(5) Authentication-Failure

Whatever authentication mechanism that is being used, the verifier has decided the Map-Requester cannot get access to the registered database-mapping.

I believe, based on how I describe it above, they are all discrete.

Dino