> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
