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

[<[e-mail]>]

Hi Dino, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dino Farinacci [mailto:[e-mail]]
> Envoyé : jeudi 19 octobre 2017 15:21
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail] list
> Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00
> 
> 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.
> 

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

> 
> 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, [e-mail] wrote:
> >
> > Hi Dino,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Dino Farinacci [mailto:[e-mail]]
> >> Envoyé : lundi 16 octobre 2017 15:08
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : [e-mail] list
> >> Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00
> >>
> >>> 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.^
> >>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>
> >>> 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.
> >>
> >> 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.
> >>> [Med] The format needs to be updated for replies.
> >>
> >> Not true. Map-Replies have multiple EID records. And I use them every
> day.
> >> ;-)
> >>
> >>> 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
> >>
> >> 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.
> >
> >>
> >> Dino
> >