> <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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
