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

[Dino Farinacci <[e-mail]>]

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

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

Right, but please document it.

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

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.

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

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