Subject: [lisp] Review 6833bis-08 - General and NMR

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Mon, 19 Mar 2018 14:18:03 +0000

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions

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.

2. Section 5.8. On page 27, there is a figure/header format showing the AD Type and Authentication Data Content, which is not referenced anywhere. Looks like it needs to be removed.

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.

   8.3.  Map-Server Processing
   Once a Map-Server has EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.
   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map-Server first checks to see if the destination EID
   matches a configured EID-Prefix.  If there is no match, the Map-
   Server returns a Negative Map-Reply with action code "Natively-
   Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
   received for a configured aggregate EID-Prefix for which no more-
   specific EID-Prefix exists; it indicates the presence of a non-LISP
   "hole" in the aggregate EID-Prefix.
   Next, the Map-Server checks to see if any ETRs have registered the
   matching EID-Prefix.  If none are found, then the Map-Server returns
   a Negative Map-Reply with action code "Natively-Forward" and a
   1-minute TTL.

   8.4 …

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
   table that covers the full EID space), it immediately returns a
   negative LISP Map-Reply, with action code "Natively-Forward" and a
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map-Resolver SHOULD return the least-specific
   prefix that both matches the original query and does not match any
   EID-Prefix known to exist in the LISP-capable infrastructure.

Regards,

-v

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Mon, 19 Mar 2018 14:25:48 +0000

These comments apply to version -09 of the document without any change.

-v

On Mar 19, 2018, at 2:18 PM, Victor Moreno (vimoreno) <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG,

   8.4 …

Regards,

-v

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2018 11:22:28 -0700

> 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.

> 2. Section 5.8. On page 27, there is a figure/header format showing the AD Type and Authentication Data Content, which is not referenced anywhere. Looks like it needs to be removed.

Nice find. When the text was moved from RFC6830, we mis-placed it in RFC6833.

> 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 s…

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:

  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.
      The current assigned values are:

      (0) No-Action:  The Map-Cache is kept alive, and no packet
          encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
          but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

      (3) Drop/No-Reason:  A packet that matches this Map-Cache entry is
          dropped.  An ICMP Destination Unreachable message SHOULD be
          sent.

      (4) Drop/Policy-Denied:  A packet that matches this Map-Cache
          entry is dropped.  The reason for the Drop action is that a
          Map-Request for the target-EID is being policy denied by
          either an xTR or the mapping system.

      (5) Drop/Authentication-Failure:  A packet that matches this Map-
          Cache entry is dropped.  The reason for the Drop action is
          that a Map-Request for the target-EID fails an authentication
          verification-check by either an xTR or the mapping system.

Thanks again,
Dino

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Mon, 19 Mar 2018 23:35:51 +0000

> On Mar 19, 2018, at 6:22 PM, Dino Farinacci <[email-masked]> wrote:
> 
>> Dear WG,
>> 

Understood, but should we not spell out LISP Header somewhere rather than just using LH without spelling it out anywhere?

> Nice find. When the text was moved from RFC6830, we mis-placed it in RFC6833.

Ack, good.

> 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 sen…

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

> <rfcdiff.html>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2018 17:44:31 -0700

> 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.

> 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…

Okay, I added some text.

Dino

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Tue, 20 Mar 2018 01:45:35 +0000

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)

-v

On Mar 20, 2018, at 12:44 AM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 19, 2018, at 6:22 PM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG,

-v

Okay, I added some text.

Dino

<rfcdiff.html>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Mar 2018 17:29:30 -0700

> 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? 

No, it would be either.

> 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.

The definition of a Negative Map-Reply is one with a empty RLOC-set. I will make that more clear in the definition and the description on how to return different actions.

> c) New text describing how the ACT bits are used to specify forwarding behavior for EIDs that DO EXIST

Agree 100%. See new diff file.

> 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).

No, not really. “Exist” is too general a term. We should say “not registered”. 

Let me know if new text is better.

Thanks,
Dino

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Wed, 21 Mar 2018 07:52:57 +0000

I think the new text is much better, unambiguous and addresses all concerns.

Thanks Dino,

-v

> On Mar 21, 2018, at 12:29 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Mar 2018 02:46:14 -0700

I will post at noon GMT if there are no objections.

Dino

> On Mar 21, 2018, at 12:52 AM, Victor Moreno (vimoreno) <[email-masked]> wrote:
>