Subject: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Oct 2017 09:55:52 -0700

Med/Christian, RFC6830 already supports multiple EID-records in both Map-Requests and Map-Replies (as well as Map-Notify messages). If you think it is not specified sufficiently, now is the time to add a better explanation to RFC6833bis.

Dino

---

From: <[email-masked]>
Date: Tue, 10 Oct 2017 05:54:51 +0000

Hi Dino, 

Thank you for the comment. 

There is a provision in RFC6830 to support multiple RLCOs/EIDS but without specifying the behavior. As you know, that RFC is crystal clear about that.

Yes, I do think it is time to specify that behavior in the bis document.

Section 3 of draft-boucadair-lisp-multiple-records is an example of what can be considered in the bis document.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : lisp [mailto:[email-masked]] De la part de Dino Farinacci
> Envoyé : lundi 9 octobre 2017 18:56
> À : [email-masked] list
> Objet : [lisp] Comments to draft-boucadair-lisp-multiple-records-00
> 
> Med/Christian, RFC6830 already supports multiple EID-records in both Map-
> Requests and Map-Replies (as well as Map-Notify messages). If you think it
> is not specified sufficiently, now is the time to add a better explanation
> to RFC6833bis.
> 
> Dino
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Oct 2017 10:22:10 -0700

> There is a provision in RFC6830 to support multiple RLCOs/EIDS but without specifying the behavior.

Right, I already said that.

> As you know, that RFC is crystal clear about that.

RFC6830 or your Internet Draft?

> Section 3 of draft-boucadair-lisp-multiple-records is an example of what can be considered in the bis document.

I’ll have a look at it. But what part of section 3? All the packet format descriptions are already in RFC6830. And you have this in section 3 which is semantically incorrect:

It is documented no where that a Map-Resolvers caching mappings. And if you are proposing that you need a lot more text to describe how mappings are kept up to date in the Map-Resolver. This is a major architectural change and really not sure you know the implications of it.

Map-Resolvers ONLY cache referral entries documented in the LISP-DDT RFC.

Also note, what if a Map-Request has both 10.1.1.1/32 and 10.1.0.0/16 encoded as EID records. And if the mapping system has registered 10.0.0.0/8, then does the Map-Reply contain two records to satisfy 10.1.1.1/32 AND 10.1.0.0/16, or just one EID record. And if so, how does the requestor know that the one reply record is associated with both request records or one doesn’t apply (or is not found in the mapping system).

As you can see there is a lot of text that would need to be written. Which I think is too late for RFC6833bis. That is why I asked you for text. I wanted to see how coarse versus detail your text would be and then have the WG judge if it should go in.

Then there is the practical aspect. What are you trying to accomplish with multiple EID-records in a Map-Request. Let’s start there.

Dino

---

From: <[email-masked]>
Date: Mon, 16 Oct 2017 07:34:49 +0000

Hi Dino,

Please see inline.

Cheers,
Med

De : Dino Farinacci [mailto:[email-masked]]
Envoyé : mardi 10 octobre 2017 19:22
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked] list
Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

Hi Dino,

RFC6830 or your Internet Draft?
[Med] I’m referring to RFC6830 which says the following :

   Record Count:  This is the number of records in this Map-Request
      message.  A record is comprised of the portion of the packet that
      is labeled 'Rec' above and occurs the number of times equal to
      Record Count.  For this version of the protocol, a receiver MUST
      accept and process Map-Requests that contain one or more records,
      but a sender MUST only send Map-Requests containing one record.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      Support for requesting multiple EIDs in a single Map-Request^
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      message will be specified in a future version of the protocol.^
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I’ll have a look at it. But what part of section 3? All the packet format descriptions are already in RFC6830.
[Med] The format needs to be updated for replies.

And you have this in section 3 which is semantically incorrect:

It is documented no where that a Map-Resolvers caching mappings. And if you are proposing that you need a lot more text to describe how mappings are kept up to date in the Map-Resolver. This is a major architectural change and really not sure you know the implications of it.
[Med] That single sentence is hiding the case where a single request from an xTR may be forked into multiple ones because target EIDs are not managed by the same servers. What is important in the text you quoted is that the xTR should be prepared to receive multiple replies for a single request. Two cases are to be considered:

-    Multiple records for the same EID that cannot be included in a single resply

-    Multiple replies; each for a given EID

[Med] This is fair.

Then there is the practical aspect. What are you trying to accomplish with multiple EID-records in a Map-Request. Let’s start there.
[Med] In addition to what motivated “RFC6830 already supports multiple EID-records in both Map-Requests and Map-Replies”, we are focusing on the following cases:

-    Fast recovery of popular EIDs in case of failures. One or very few requests will trigger the mapping retrieval.

-    Optimized subscription/notification exchanges

Dino

Thank you.

Cheers,
Med

-----Message d'origine-----
De : lisp [mailto:[email-masked]] De la part de Dino Farinacci
Envoyé : lundi 9 octobre 2017 18:56
À : [email-masked]<mailto:[email-masked]> list
Objet : [lisp] Comments to draft-boucadair-lisp-multiple-records-00

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Oct 2017 06:08:14 -0700

>       but a sender MUST only send Map-Requests containing one record.

IMO the description is not sufficient to tell an implementation what to code. It is under specified. I’d love to consider removing the above but it needs specific/detailed text describing why and when multiple records are used in Map-Requests.

> [Med] The format needs to be updated for replies.

Not true. Map-Replies have multiple EID records. And I use them every day.  ;-)

> -    Multiple replies; each for a given EID

And how does the ITR know to wait for multiple replies? How does it know when all of them come in? This is more protocol machinery that needs to be spec’ed out. And I have not seen any of it in your bulk spec.

Dino

---

From: <[email-masked]>
Date: Wed, 18 Oct 2017 08:09:33 +0000

Hi Dino,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 16 octobre 2017 15:08
> IMO the description is not sufficient to tell an implementation what to
> code. It is under specified. I’d love to consider removing the above but
> it needs specific/detailed text describing why and when multiple records
> are used in Map-Requests.

[Med] As I said earlier, that text is only an example of a starting point. We can also start from what your implementation is already doing.

> 
> > I’ll have a look at it. But what part of section 3? All the packet
> format descriptions are already in RFC6830.
> > It is documented no where that a Map-Resolvers caching mappings. And if
> you are proposing that you need a lot more text to describe how mappings
> are kept up to date in the Map-Resolver. This is a major architectural
> change and really not sure you know the implications of it.
> > [Med] That single sentence is hiding the case where a single request
> from an xTR may be forked into multiple ones because target EIDs are not
> managed by the same servers. What is important in the text you quoted is
> that the xTR should be prepared to receive multiple replies for a single
> request. Two cases are to be considered:
> And how does the ITR know to wait for multiple replies?

[Med] This the role of M-bit in the response. That bit is an indication to wait for more replies associated with a single request. draft-boucadair-lisp-multiple-records states the following:

   In order to inform an ITR that subsequent Map-Reply messages will
   follow (or not) , a dedicated flag bit is defined for this purpose:
   it is called the M-bit (more-map-reply bit).

 How does it know
> when all of them come in? This is more protocol machinery that needs to be
> spec’ed out. And I have not seen any of it in your bulk spec.

[Med] Putting aside the use of TCP, the bulk specification defines a dedicated bit for this: 

   o  Set the M-bit for all Map-Bulk-Reply messages, except for the last
      one.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Oct 2017 06:20:41 -0700

What if we provided you with a more efficient feature. That is:

(1) The ITR sends a Map-Request for 0.0.0.0/0.
(2) But rather than the mapping system return a RLOC-set for 0.0.0.0/0 (which may or may not be registered), it returns all more specifics?
(3) The ITR would request a lookup-type of “return *all* more specifics” versus an longest or exact match lookup.

Here is my justification. And I made this comment to you a couple of years ago. If an ITR is going to provide a list of EIDs to lookup when it restarts, one has to ask how does it know which EIDs to request. If it has a list, that means there was some implementation capability to write a checkpoint or stateful file of entries. So when an ITR restarts, it has that list. 

Well, if it builds this checkpoint file, it could also store the RLOC-set, so it would have all the mappings, maybe out of date, but it could query the mapping system when the demand sees the need.

I have an implementation of this and when I brought this up a couple of years ago, I offered you to try it out.

But if one doesn’t want to go the checkpoint file route or have a protocol mechanism, the “lookup-type” functionality would be useful. Albert, Vina, and I have talked about creating a new LCAF type that is essentially “Lookup-Type LCAF” which requests “all-more-specific”, “more-specific”, “exact-match” lookup types.

Comments?

Dino

> On Oct 18, 2017, at 1:09 AM, [email-masked] wrote:
> 
> Hi Dino,
> 
> Please see inline. 
> 
> Cheers,
> Med
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 26 Oct 2017 11:28:56 +0200

Hi,

> On 10 Oct 2017, at 19:22, Dino Farinacci <[email-masked]> wrote:
> 

[snip]

> As you can see there is a lot of text that would need to be written. Which I think is too late for RFC6833bis.

Why late? Dino, as you mentioned in your previous mail if we want to provide specification for this use than now is the time.

Otherwise we have to state that the current specification does not provide anything about multiple records and hence they shouldn’t be used.

Up to the WG to decide whether or not is the time to do it.

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Oct 2017 09:47:34 -0700

> Why late? Dino, as you mentioned in your previous mail if we want to provide specification for this use than now is the time.

My point is, we may not be able to justify a real use-case for Map-Requesting multiple EID-records. But to ask for all records that are more specific then a a prefix you request makes sense to solve the use-case, I think Med wants to solve. That is reloading your map-cache on an ITR when it restarts.

I made a suggestion but haven’t received any feedback on it yet.

> Otherwise we have to state that the current specification does not provide anything about multiple records and hence they shouldn’t be used.

The specification does specify that you can put multiple EIDs in a Map-Request, it just doesn’t say why you should. And we need to have a well defined use-case before we can write any meaningful text.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 27 Oct 2017 10:30:23 +0200

> On 26 Oct 2017, at 18:47, Dino Farinacci <[email-masked]> wrote:
> 
> The specification does specify that you can put multiple EIDs in a Map-Request, it just doesn’t say why you should.

Does it clear state what the ETR has to do when it receives a Map-Request with multiple EIDs?

L.

> And we need to have a well defined use-case before we can write any meaningful text.
>

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 13:54:59 +0000

Hi Dino, 

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 19 octobre 2017 15:21
> (2) But rather than the mapping system return a RLOC-set for 0.0.0.0/0
> (which may or may not be registered), it returns all more specifics?

[Med] I like this one, but I'd like also to let the ITR encloses specific EIDs in the same request. 

> Here is my justification. And I made this comment to you a couple of years
> ago. If an ITR is going to provide a list of EIDs to lookup when it
> restarts, one has to ask how does it know which EIDs to request. If it has
> a list, that means there was some implementation capability to write a
> checkpoint or stateful file of entries. So when an ITR restarts, it has
> that list.

[Med] What we have investigated is to configure the ITR upon reboot with popular prefixes (without even requiring persistent storage of the EIDs list). We had designed a YANG module which is meant to populate a policy table on the ITR so that popular EIDs can be retrieved immediately after state loss/reboot. The purpose was to avoid the first packet loss issue. An excerpt of the tree model is provided below.  

====================
module: ietf-ms-policy-table
   +--rw ms-pt-config
   |  +--rw description?      string
   |  +--rw rfc6724-enable?   boolean
   |  +--rw ms-pt-list
   |     +--rw ms-pt-entry* [id]
   |        +--rw id              uint32
   |        +--rw Name?           string
   |        +--rw Description?    string
   |        +--rw eid             eid-id
   |        +--rw map-resolver    inet:ip-address
   |        +--rw priority?       uint32
   |        +--rw status?         enumeration
   |        +--rw validity-date?   yang:date-and-time
====== 

> 
> Well, if it builds this checkpoint file, it could also store the RLOC-set,
> so it would have all the mappings, maybe out of date, but it could query
> the mapping system when the demand sees the need.

[Med] Actually, we wanted to avoid waiting for a packet to show up for creating mappings for popular EIDs in a LISP domain. 

> But if one doesn’t want to go the checkpoint file route or have a protocol
> mechanism, the “lookup-type” functionality would be useful. Albert, Vina,
> and I have talked about creating a new LCAF type that is essentially
> “Lookup-Type LCAF” which requests “all-more-specific”, “more-specific”,
> “exact-match” lookup types.
> 
> Comments?
> 
> Dino
> 
> >>> Section 3 of draft-boucadair-lisp-multiple-records is an example of
> what
> >> can be considered in the bis document.
> >>
> > [Med] As I said earlier, that text is only an example of a starting
> point. We can also start from what your implementation is already doing.
> >
> >>
> >> Not true. Map-Replies have multiple EID records. And I use them every
> day.
> >> ;-)
> >>
> > [Med] This the role of M-bit in the response. That bit is an indication
> to wait for more replies associated with a single request. draft-
> boucadair-lisp-multiple-records states the following:
> >

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Oct 2017 10:49:15 -0700

> Does it clear state what the ETR has to do when it receives a Map-Request with multiple EIDs?

This is what the Record Count field says in RFC6833bis in "4.2.  Map-Request Message Format" section:

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Oct 2017 17:15:52 -0700

> [Med] I like this one, but I'd like also to let the ITR encloses specific EIDs in the same request. 

Yes, that would be supported based on the existing text. This mechanism would have the lookup type per EID-record. So you could put 2 EIDs in a Map-Request where one would be a “return all more specifics” and the other “exact match”.

> [Med] What we have investigated is to configure the ITR upon reboot with popular prefixes (without even requiring persistent storage of the EIDs list). We had designed a YANG module which is meant to populate a policy table on the 

So there is a feature in LISP where you can put “send-map-request” action entries in the map-cache. And when the ITR boots you can go ask for them.

> ITR so that popular EIDs can be retrieved immediately after state loss/reboot. The purpose was to avoid the first packet loss issue. An excerpt of the tree model is provided below.  

Like I said before, if the ITR implementation would cache in a checkpoint file the entries that have been used, you have your list when you reboot. That is another mechanism.

Right, it is a “request to push”.

Dino