Thanks Dino,
I want to make sure I understand correctly. A couple of questions:
If the EID-prefix exists and there is a policy in the Map-Server to
have the requestor drop packets for the matching EID-prefix,
then a
Drop/Policy-Denied action is returned. If the EID-prefix exists
and
there is a authentication failure, then a Drop/Authentication-
failure action is returned. If either of these actions
result as a
temporary state in policy or authentication then a
Send-Map-Request
action with 1-minute TTL MAY be returned to allow the
reqeustor to
retry the Map-Request.
Could I not do the above even if the EID-prefix DID NOT EXIST? Or are we
restricting any application of policy only to LISP EID-prefixes, and not to
non-LISP prefixes?
The map-replies suggested in the new text would effectively be NMRs, correct?
i.e. Map-replies with empty locator sets and the ACT bits set.
If that is the intent, maybe we need to revise the definitions for NMR and ACT
as I think right now there is some inconsistency/contradiction:
a) NMR definition - Issued in response to queries only for EIDs that DO NOT
EXIST
b) ACT bits specification - for use in NMRs ONLY
c) New text describing how the ACT bits are used to specify forwarding behavior
for EIDs that DO EXIST
So NMRs are exclusive to non-existent or non-registered EIDs (a) and ACT bits
are exclusive to NMRs (b). Yet (c) implies that NMRs will be used for EIDs that
DO EXIST. So (c) contradicts (a).
Text for (a)
Negative Map-Reply: A LISP Map-Reply that contains an empty
Locator-Set. Returned in response to a Map-Request if the
destination EID does not exist in the mapping database.
Typically, this means that the "EID" being requested is an IP
address connected to a non-LISP site.
Text for (b)
ACT: This 3-bit field describes Negative Map-Reply actions. In any
other message type, these bits are set to 0 and ignored on
receipt. These bits are used only when the 'Locator Count' field
is set to 0. The action bits are encoded only in Map-Reply
messages. The actions defined are used by an ITR or PITR when a
destination EID matches a negative Map-Cache entry. Unassigned
values SHOULD cause a Map-Cache entry to be created, and when
packets match this negative cache entry, they will be dropped.
-v
On Mar 20, 2018, at 12:44 AM, Dino Farinacci
<farina...@gmail.com<mailto:farina...@gmail.com>> wrote:
On Mar 19, 2018, at 6:22 PM, Dino Farinacci
<farina...@gmail.com<mailto:farina...@gmail.com>> wrote:
Dear WG,
I did a quick review of rfc6833bis-08. Some comments/suggestions
Thanks Victor. See new update enclosed. Let us know if you are good with the
changes and the response below.
1. Section 5.8. Encapsulated Control Message Format. There is a reference to
LH, it is not spelled out anywhere. I assume this means Lisp Header.
It is a reference to the row in the diagram above:
<PastedGraphic-16.png>
Understood, but should we not spell out LISP Header somewhere rather than just
using LH without spelling it out anywhere?
I can change it. See new diff.
3. Section 8.3/8.4. The text is limited to recommending exclusively a Native
Forward action code. However the definition of the Map-reply message in section
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG
agrees I can suggest text that would generalize the recommended processing
behaviors described in 8.3 to allow the inclusion and use of the specified
actions in the case of NMRs.
Well the text below is correct and is explaining when a mapping entry DOES NOT
exist. For all other actions, they are sent for entries that DO EXIST in the
mapping database. And the reasons for sending the specific action type is
documented in the Map-Reply ACT field description:
I agree that the text is correct, but I am pointing out that is not sufficient.
If my policy is to drop traffic destined to an EID that is either not
registered or not configured in the Mapping DB, how would I instruct the EID to
drop the traffic? I would think I'd want to issue an NMR with action drop (4
or other). The spec currently doesn’t illustrate such actions. Text in 8.3 &
8.4 prescribes that the NMR for non-configured or non-registered EIDs will
always have an action of Native-Forward, but I need the action to be Drop (for
example).
In the definitions section, the NMRs are defined as responses to queries for
EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined
as exclusive to the NMRs (set to 0 in any other message). It is not clear to
me how these actions can apply to entries that DO EXIST?
-v
Okay, I added some text.
Dino
<rfcdiff.html>
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
