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