<just to be clear, still hatless, jsut trying to understand as a
participant>
It looks to me like Policy_Denied and Authentication-Failure are error
codes, not dispositions. They presumably go with the "Drop" action (as
is the defined behavior for any ACT which is not understood.
Given that the action is the same as Drop, it seems safe, but odd, to
use different action codes. Is there a difference in the action at the
receiver?
If there is no difference, would it not make sense to encode this
information in some other field? It seems to be for diagnositirc
purposes, not action.
Yours,
Joel
On 3/12/17 9:45 PM, Dino Farinacci wrote:
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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
