Good comments Dino. See inline. On Tue, Sep 29, 2015 at 8:27 PM, Dino Farinacci <[email protected]> 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
