Subject: [lisp] Comments to draft-rodrigueznatal-lisp-ms-smr-00.txt

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Sep 2015 11:27:58 -0700

Hi guys, thanks for the draft. I have some comments. But to note, in private discussions, we have talked about a more general mechanism that is in another draft to be published. Thanks Alberto for contributing to both drafts.

For others on the list, the main difference is the use of Map-Notify versus SMRs as the means to inform an ITR or PITR a mapping entry has changed. In this draft SMRs are used so ITRs do not need any changes. However, RFC 6830 says that ETRs are the only ones to send SMRs.

The general design uses Map-Notify messages, because the mapping system typically sends Map-Notify messages (for the VM-mobility use-case and signal-free-multicast mechanism). But ITRs or PITRs that do not support signal-free-multicast or implement the VM-mobility use-case may not support them at this point in time.

In any event, we can discuss this at next WG meeting.

Here are my comments, your text comes first and is indented and my comments follow:

> 2.  Map Server extension
> 
>    This document enables MS to generate and send SMR messages towards
>    (P)ITRs.  SMRs originated in a MS follow the same format described in
>    [RFC6830].  Besides the fact that they are sent from a MS, there is
>    no difference between an SMR originated in an ETR and one originated
>    in a MS.
> 
>    When a MS generates an SMR, it uses as source-EID the EID-prefix it
>    wants the (P)ITR to send the SMR-invoked Map-Request for.  The EID
>    included in the EID-record field is the one belonging to the (P)ITR

EIDs don’t “belong” to PITRs. Typically, the ETR sends SMRs with an EID-record to the EID-preifx the ITR is encapsulating for. Since there are no configured database mappings on PITRs, you have to specifiy what actually is put in the EID-record. I suggest an AFI=0 or an EID-record count of 0.

>    the MS sends the SMR towards.  As source locator for the SMR message,
>    the MS uses one of its available locators.  This has implications in
>    the processing of the SMR at the (P)ITR as described in Section 4
> 
>    When the MS has to send an SMR is implementation specific.  However,
>    as specified in [RFC6830] and noted in Section 7, SMRs MUST be rate-
>    limited.  It must be noted as well that, as described in Section 3, a
>    MS that sends an SMR may not receive the SMR-invoked Map-Request that
>    the (P)ITR generates as response to the SMR.

So when a mapping changes, an ETR will register to more than one map-server. I did not see any text to indicate if more than one map-server will send an SMR to the (P)ITR. Are multiple messages sent? And does the ITR ignore subsequent messages or sends a SMR-invoked Map-Request for each SMR received? Note, this will add unnecessary messaging to the global system.

>    This document introduces no changes in the specification of (P)ITRs
>    and thus it is backwards compatible with legacy equipment only
>    compliant with [RFC6830].  However, since SMRs were designed to be
>    sent by ETRs, and legacy (P)ITRs expect to receive SMRs only from
>    ETRs, the implications of sending SMRs from a MS are discussed in
>    this section.

You need to indicate what PITR does with an SMR when the EID in the EID-record is not cached, or not configured.

Also, note, that a map-server may also be an RTR, so the RTR’s locator may be in the map-cache locator-set of an PITR or ITR. In that case, you need to explain if the SMR-invoked Map-Request should go directly to the RTR/MS system or via the mapping system (ie. via a Map-Resolver).

Note, the Map-Notify approach scales much better, because when the MS sends the Map-Notify the locator information is in the message. So, in a trusted system, the ITR need not send a x-invoked Map-Request. So it will scale much better. See draft-farinacci-lisp-signal-free-multicast for details on replication-list-entry changes (which is a locator-set merge change).

And could the authors please state your intentions on the temporary or permanent nature of this draft. I have heard that this is something proposed as a transition for SDN environments.

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 30 Sep 2015 12:38:42 +0200

Good comments Dino. See inline.

On Tue, Sep 29, 2015 at 8:27 PM, Dino Farinacci <[email-masked]> wrote:

> Hi guys, thanks for the draft. I have some comments. But to note, in
> private discussions, we have talked about a more general mechanism that is
> in another draft to be published. Thanks Alberto for contributing to both
> drafts.
>

To the people on the list, we hope to discuss the more general approach
with the WG on the next IETF. We are putting together a set of slides
covering the private discussions that Dino mentioned.

>
> In this draft SMRs are used so ITRs do not need any changes.

This is exactly the point that motivated this draft.

> In any event, we can discuss this at next WG meeting.

Absolutely. Personally, I'm looking forward to it.

>
> EIDs don’t “belong” to PITRs. Typically, the ETR sends SMRs with an
> EID-record to the EID-preifx the ITR is encapsulating for.

Better way to put it. I'll rephrase the sentence.

Since there are no configured database mappings on PITRs, you have to
> specifiy what actually is put in the EID-record. I suggest an AFI=0 or an
> EID-record count of 0.
>

That's a way to do it. Probably we'd need to do some interoperability test
to see how the different implementations react to this.

>
> So when a mapping changes, an ETR will register to more than one
> map-server. I did not see any text to indicate if more than one map-server
> will send an SMR to the (P)ITR. Are multiple messages sent?

The draft specifies that is up to the implementation to decide when (and
therefore how many) to send SMRs.

> And does the ITR ignore subsequent messages or sends a SMR-invoked
> Map-Request for each SMR received? Note, this will add unnecessary
> messaging to the global system.
>

Since the main point of the draft is to interoperate with legacy (P)ITRs,
it is assumed that (P)ITRs will operate according to their implementation
of RFC6830. Most likely they will send several SMR-invoked Map-Requests
before rate-limiting themselves.

>
> You need to indicate what PITR does with an SMR when the EID in the
> EID-record is not cached, or not configured.
>

Note that this will always be the case If we use AFI=0 in the EID-record
when sending SMRs to the PITRs as you proposed above. I'm unsure how
RFC6830 deals with the case of an SMR using an EID-record not configured
(both for ITRs and PITRs).

>
> Also, note, that a map-server may also be an RTR, so the RTR’s locator may
> be in the map-cache locator-set of an PITR or ITR. In that case, you need
> to explain if the SMR-invoked Map-Request should go directly to the RTR/MS
> system or via the mapping system (ie. via a Map-Resolver).
>

Well in that case we can say that is the RTR the one sending the SMR, not
the MS, and therefore there is no need for this draft :P. I believe that we
can add some text to clarify that case (and also the -rare- case of a
MS-ITR), although for me it is legacy RFC6830 operation.

>
> And could the authors please state your intentions on the temporary or
> permanent nature of this draft. I have heard that this is something
> proposed as a transition for SDN environments.
>

Speaking for myself only, I think that should be up to the WG to decide. I
personally believe that both drafts make sense since they target different
deployment cases (legacy vs upgraded).

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Sep 2015 08:36:46 -0700

> Since there are no configured database mappings on PITRs, you have to specifiy what actually is put in the EID-record. I suggest an AFI=0 or an EID-record count of 0.
> 
> That's a way to do it. Probably we'd need to do some interoperability test to see how the different implementations react to this.  

Well you need to state that int he draft. Because, as written, it assumes that PITRs own or belong to EIDs, which is conceptually wrong.

> So when a mapping changes, an ETR will register to more than one map-server. I did not see any text to indicate if more than one map-server will send an SMR to the (P)ITR. Are multiple messages sent? 
> 
> The draft specifies that is up to the implementation to decide when (and therefore how many) to send SMRs.

Yes, but you are introducing extra messaging that is not needed. This needs to be addressed in the draft. We don’t want to build non-scable solutions.

> And does the ITR ignore subsequent messages or sends a SMR-invoked Map-Request for each SMR received? Note, this will add unnecessary messaging to the global system.
> 
> Since the main point of the draft is to interoperate with legacy (P)ITRs, it is assumed that (P)ITRs will operate according to their implementation of RFC6830. Most likely they will send several SMR-invoked Map-Requests before rate-limiting themselves.  

We don’t want to build non-scable solutions. You have to address scalability issues in the draft.

You need to justify that there is an extra messaging cost to not modify the ITRs so the reviewers can evaluate if this solution is adequate.

> Note that this will always be the case If we use AFI=0 in the EID-record when sending SMRs to the PITRs as you proposed above. I'm unsure how RFC6830 deals with the case of an SMR using an EID-record not configured (both for ITRs and PITRs).

Right, but please document it.

> Well in that case we can say that is the RTR the one sending the SMR, not the MS, and therefore there is no need for this draft :P. I believe that we can add some text to clarify that case (and also the -rare- case of a MS-ITR), although for me it is legacy RFC6830 operation. 

Well no, the RTR is not associated with the destination EID. It’s the map-server that really knows about the locator-set change. The point is, that a locator-set comparison as you state should be removed. It is not adding value IMO.

> Speaking for myself only, I think that should be up to the WG to decide. I personally believe that both drafts make sense since they target different deployment cases (legacy vs upgraded).

Well I believe the Map-Notify draft can solve both cases, so I don’t know why 2 solutions are needed. So that is my opinion for the record.

Dino

---

From: Fabio Maino <[email-masked]>
Date: Wed, 30 Sep 2015 12:39:32 -0700

Hi Dino,
thanks for your replay.

The main goal of this draft is to document what is implemented in ODL 
(https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture), 
with the hope that comments and feedback will help us improve that 
solution, and facilitate interoperability.

The driving requirement (as stated upfront in the abstract) is 
interoperability with EXISTING xTRs, as specified in RFC 6830.

The reason for that requirement  is that, willing or not, we have to 
deal with those xTRs for at least another couple of years (and then 
some...). We want to deploy SDN/LISP solutions today, or LISP will just 
become irrelevant in the architecture of programmable overlays.

I will try to make the best use of all the comments sent, but in my 
opinion the comments that belong to this thread (as most of those that 
you include below) are those that help improve the solution within the 
constraints of that requirement.

I believe there's a broader conversation that needs to happen at the WG 
level, that is how to augment LISP (xTR+MS/MR+Protocol) with 
publish/subscribe extensions (and possibly more) to address the SDN use 
case. As you mention we started that conversation within a small group, 
and looking at the Boucadair draft there are other people that are 
looking into similar problems.

I think Alberto is putting together a set of slides to summarize the 
conversation we had and some observations on 
draft-boucadair-lisp-subscribe that may help the working group to kick 
off a discussion on this topic. I suggest we use that thread, and maybe 
some time in Japan, to make progress on that work that is done under 
much broader assumptions than this draft (and would make for a great 
working item in the new charter).

Thanks,
Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Sep 2015 13:36:40 -0700

> Hi Dino,
> thanks for your replay.
> 
> The main goal of this draft is to document what is implemented in ODL (https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture), with the hope that comments and feedback will help us improve that solution, and facilitate interoperability.

The draft does not say that.

If that is the goal to document ODL behavior, can you please state that in the document. And indicate that this solution may not be a permanent one but a draft that simply documents an implementation behavior?

> The driving requirement (as stated upfront in the abstract) is interoperability with EXISTING xTRs, as specified in RFC 6830.

But more to the point for SDN environments, where with SDN, there are multiple ways to skin a cat, where ODL is one such way of doing SDN.

Thanks,
Dino

---

From: Fabio Maino <[email-masked]>
Date: Wed, 30 Sep 2015 15:36:33 -0700

Hi Dino,
the draft says, right in the abstract, that:  "This extension is 
intended to be used in some SDN deployments that use LISP as a 
southbound protocol with (P)ITRs that are compliant with [RFC6830 
<https://tools.ietf.org/html/rfc6830>]." I don't think we need to 
qualify that any further. It clearly states what the scope is without 
the need to enumerate implementations (that I believe would be quite 
unusual for a draft).

This is a draft marked as experimental  contributed to the LISP WG as 
part of the conversation on pub-sub. I honestly don't know what the WG 
will decide to do with it. I observe that the authors are not proposing 
this draft as a WG item.

If the WG will ever decide to have a WG draft on pub-sub, I hope there 
will be a section talking about interoperability with xTRs that are 
RFC6830 compliant. This draft may, or may not, help writing that section.

Thanks,
Fabio