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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
