Subject: Re: [lisp] Addition to RFC6833bis for xTR-ID in Map-Request message

From: <[email-masked]>
Date: Tue, 3 Oct 2017 06:01:07 +0000

Hi Dino, all,

I do strongly support that pub/sub feature is also possible in LISP.

Overloading Map-Request is one way to proceed, but there is also an alternate approach to define a dedicate method for the subscription/notification purposes (e.g., https://tools.ietf.org/html/draft-boucadair-lisp-subscribe-05).

I suggest that the WG examines both approaches.

Cheers,
Med

De : lisp [mailto:[email-masked]] De la part de Dino Farinacci
Envoyé : vendredi 29 septembre 2017 00:24
À : [email-masked] list
Objet : [lisp] Addition to RFC6833bis for xTR-ID in Map-Request message

This is based on the discussion that Alberto raised on the list. Here is the proposed change. We made the
text consistent with how the xTR-ID is spec’ed and referenced in the Map-Register message.

Here is a change description:

Dino

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Oct 2017 16:03:47 -0700

> I do strongly support that pub/sub feature is also possible in LISP.

Thanks for the response Med. I think it can be introduced quite easily with the right machinery.

> Overloading Map-Request is one way to proceed, but there is also an alternate approach to define a dedicate method for the subscription/notification purposes (e.g., https://tools.ietf.org/html/draf…

I read your original draft and I just finished reading your -05 draft. Here are my concerns with your design:

(1) Your draft covers a lot more issues then just getting notifications for RLOC-set changes (pubsub functionality). So the scope needs to be narrowed IMO.

(2) You indicate for Map-Resolver redirect to use a Map-Subscribe message. That doesn’t sound like a pubsub capability.

(3) The Map-Subscribe has all the same fields (and in different order) than a Map-Request, that means a new parser and code needs to be written and debugged when existing implementations could easily process a new S-bit in a Map-Request message.

(4) An ITR would have to send two message when its data-plane gets a cache miss. A Map-Request to get a Map-Reply to populate its map-cache and a Map-Subscribe to request for notifications. And then it would have to process a Map-Subscribe-Ack and Map-Reply separately.

(5) As for (4) what if the Map-Subscribe-Ack comes back but the Map-Reply is lost? The ITR has subscription state but can’t do any forwarding. What if the Map-Reply is returned and the Map-Subscribe-Ack is lost, then the ITR has forwarding state but no notification state. What if the RLOC-set changes during the retransmission of the Map-Subscribe-Ack?

(6) You put the Map-Subscribe functionality in the Map-Resolver. Well when an RLOC-set changes for a registered entry in a Map-Server how does it know which Map-Resolver to inform about the change? And Map-Resolvers today do not cache mapping entries. So there are a lot of mechanical issues you have not worked out.

(7) I belive the spec is mis-named in a major way. You are talking about ITR bulk transfer and cache re-population when an ITR reboots. This spec has nothing to do with pubsub.

Now as for draft-rodrigueznatal-lisp-pubsub-00 design:

(1) The reason putting subscription requests in the Map-Request is because both cache population and requesting for notifications come together and are ack’ed together.

(2) The reason for subscription requests in the Map-Request is so subscriptions can go to the map-servers. The nodes that first know when an RLOC-set changes. So we can do fast converging notifications.

(3) Using Map-Requests allows map-resolvers and ddt-nodes to NOT change. That has huge deployment advantagese. With this design only ITRs that want the functionality and map-servers that provide the functionality need to change. And both new and old ITRs/map-servers can interoperate.

(4) Using Map-Replies for acknowledgements allows for both cache population and subscription-acks to be signed by the map-server. That is, they can be authenticated.

(5) The implementation can be done fairly easily and we can deploy quickly. This has been confirmed by at least 3 developers.

So back to the simple change for RFC6833bis. Irrespective of pubsub, knowing the xTR-ID on Map-Requests have advantages to identify the ITR when it moves around (when the RLOCs change).

If there are no other objections, I’d like to publish this the change tomorrow?

Dino

---

From: <[email-masked]>
Date: Thu, 5 Oct 2017 14:29:33 +0000

Hi Dino, 

Please see inline some clarifications, FWIW. 

Cheers,
Med

> -----Message d'origine-----
> De : Dino Farinacci [mailto:[email-masked]]
> Envoyé : jeudi 5 octobre 2017 01:04
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked] list; Stefano Secci; JACQUENET Christian IMT/OLN
> Objet : Re: [lisp] Addition to RFC6833bis for xTR-ID in Map-Request
> message
> 
> > Hi Dino, all,
> >
> > Overloading Map-Request is one way to proceed, but there is also an
> alternate approach to define a dedicate method for the
> subscription/notification purposes (e.g.,
> https://tools.ietf.org/html/draft-boucadair-lisp-subscribe-05).
> 
> (1) Your draft covers a lot more issues then just getting notifications
> for RLOC-set changes (pubsub functionality). So the scope needs to be
> narrowed IMO.
> 
> (2) You indicate for Map-Resolver redirect to use a Map-Subscribe message.
> That doesn’t sound like a pubsub capability.

[Med] I may not look like a pubsub capability, but this is a consequence of requiring the Map-Resolvers to maintain state for notification purposes. Maintaining those state may include some extra load on those servers. The redirect functionally allows to redirect ITRs to an alternate server that will service them. This is done automatically at the mapping system side.   

> 
> (3) The Map-Subscribe has all the same fields (and in different order)
> than a Map-Request, that means a new parser and code needs to be written
> and debugged when existing implementations could easily process a new S-
> bit in a Map-Request message.

[Med] New code will be required anyway for supporting the new functionality.  

> 
> (4) An ITR would have to send two message when its data-plane gets a cache
> miss.

[Med] No. It will send only the subscribe message with I-bit set. This single message will be sufficient to immediately retrieve all the mappings that are matching the filters in the Map-Resolver for this particular ITR. This optimization is not supported with the modifier Map-Request.

 A Map-Request to get a Map-Reply to populate its map-cache and a
> Map-Subscribe to request for notifications. 

[Med] No. Please see above. 

And then it would have to
> process a Map-Subscribe-Ack and Map-Reply separately.
> 
> (5) As for (4) what if the Map-Subscribe-Ack comes back but the Map-Reply
> is lost?

[Med] I guess you are referring to the case where I-bit is set in the Map-Subscribe. A way to detect lost Map-Reply is to convey in the Map-Subscribe-Ack the number of entries that will be retrieved. The ITR can check based on that information. 

 The ITR has subscription state but can’t do any forwarding. What
> if the Map-Reply is returned and the Map-Subscribe-Ack is lost, then the
> ITR has forwarding state but no notification state.

[Med] The ITR will retransmit Map-Subscribe in this case. 

 What if the RLOC-set
> changes during the retransmission of the Map-Subscribe-Ack?

[Med] Implicit Map-Replies will be sent immediately to the ITR.  

> 
> (6) You put the Map-Subscribe functionality in the Map-Resolver. Well when
> an RLOC-set changes for a registered entry in a Map-Server how does it
> know which Map-Resolver to inform about the change?

[Med] The draft puts it in the Map-Resolver, but having a dedicated method allows for more flexibility to define for example servers that will manage subscription and notifications. 

 And Map-Resolvers
> today do not cache mapping entries. So there are a lot of mechanical
> issues you have not worked out.

[Med] This is valid for all sub/pub proposals, IMHO.

> 
> (7) I belive the spec is mis-named in a major way. You are talking about
> ITR bulk transfer and cache re-population when an ITR reboots. This spec
> has nothing to do with pubsub.

[Med] Bulk transfer is not defined in this draft. It is a useful functionality to allow for the retrieval of many mapping using TCP. The ITR informs the subscription server whether it support bulk transfer or not. Based on that criteria, notifications will be sent using individual Map-Reply messages or using the bulk transfer procedure. 

> (1) The reason putting subscription requests in the Map-Request is because
> both cache population and requesting for notifications come together and
> are ack’ed together.
> 
> (2) The reason for subscription requests in the Map-Request is so
> subscriptions can go to the map-servers. The nodes that first know when an
> RLOC-set changes. So we can do fast converging notifications.
> 
> (3) Using Map-Requests allows map-resolvers and ddt-nodes to NOT change.
> That has huge deployment advantagese. With this design only ITRs that want
> the functionality and map-servers that provide the functionality need to
> change. And both new and old ITRs/map-servers can interoperate.
> 
> (4) Using Map-Replies for acknowledgements allows for both cache
> population and subscription-acks to be signed by the map-server. That is,
> they can be authenticated.
> 
> (5) The implementation can be done fairly easily and we can deploy
> quickly. This has been confirmed by at least 3 developers.
> 
> So back to the simple change for RFC6833bis. Irrespective of pubsub,
> knowing the xTR-ID on Map-Requests have advantages to identify the ITR
> when it moves around (when the RLOCs change).
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Oct 2017 09:51:01 -0700

See responses below. I cut out text that I didn’t need to respond to.

> [Med] I may not look like a pubsub capability, but this is a consequence of requiring the Map-Resolvers to maintain state for notification purposes. Maintaining those state may include some extra l…

You can load-split by using several sets of anycast map-resolvers. So you have two levels of spread.

> [Med] New code will be required anyway for supporting the new functionality.  

But you require it in all LISP nodes.

Do you agree the draft-rodrigueznatal-lisp-pubsub-00 is a simpler and more effective way to introduce pubsub functionality.

FYI for others on the list, we have asked Med and Christian to be co-authors on draft-rodrigueznatal-lisp-pubsub-00. It would be good for you two to deploy pubsub to verify the design.

Do you have time to do this? There should be two implementations available soon.

Dino