Hi Alberto Thank you for addressing my comments. See below
On Wed, Jan 18, 2023 at 11:44 PM Alberto Rodriguez-Natal (natal) < [email protected]> wrote: > Hi Padma, > > > > Thanks again for the feedback! You’re making some good points. Please see > below for some comments inline with [AR]. > > > > *From: *lisp <[email protected]> on behalf of Padma Pillay-Esnault < > [email protected]> > *Date: *Thursday, January 5, 2023 at 8:29 AM > *To: *Alberto Rodriguez-Natal (natal) <[email protected]> > *Cc: *[email protected] <[email protected]>, Sharon Barkai <sharon.barkai= > [email protected]>, Jordi Paillissé <[email protected]> > *Subject: *Re: [lisp] LISP PubSub to Proposed Standard? > > Dear Alberto and authors > > > > Thank you for the good work on this doc. I fully support moving this > document as a proposed standard, however I have a few comments on the > document. See PPE below > > 1. Introduction > > <...> > > In general, when an ITR/RTR/PITR wants to be notified for mapping > > changes for a given EID-prefix, the following steps occur: > > > > (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. > > > > (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on > > the Map-Request and includes its xTR-ID and Site-ID. > > > > (3) The Map-Request is forwarded to one of the Map-Servers that the > > EID-prefix is registered to. > > > > (4) The Map-Server creates subscription state for the ITR/RTR/PITR > > on the EID-prefix. > > > > (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to > > acknowledge the successful subscription. > > > > (6) When there is a change in the mapping of the EID-Prefix, the > > Map-Server sends a Map-Notify message to each ITR/RTR/PITR in > > the subscription list. > > > > (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the > > received Map-Notify. > > > > This operation is repeated for all EID-prefixes for which ITR/RTR/ > > PITR want to be notified. The ITR/RTR/PITR can set the N-bit for > > several EID-prefixes within a single Map-Request. > > <...> > > PPE - This section relies on section 6.1 of rfc 9301 and gives as an > example the simplest use case. The concluding paragraph also gives the > impression that this is the only processing pub sub needs to do. Both the > section 6.1 and here do not address all the use cases. > > > > [AR] Yes, this is just a simple case to illustrate the idea and general > flow. The example certainly is not meant to be comprehensive. We can maybe > add a note to mention that this the simplest example and that the details > for this and other cases are found later in the document, what do you think? > > > > I suggest removing this from the introduction and instead clearly define > the scope and then define all the use cases as in a real deployment > scenario in section 3. See more about this below. > > > > [AR] I have no strong opinion about removing the simple example from the > intro. I’m leaning towards keeping it, as there seemed to be some consensus > around having an example (even if simple) in the intro. What others think? > PPE - no strong opinion about removing but we should add a note as you suggest to clarify > > > <...> > > 3. Deployment Assumptions > > > > The specification described in this document makes the following > > deployment assumptions: > > > > (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is > > assigned to each xTR. > > > > (2) Map-Servers are configured in proxy-reply mode, i.e., they are > > solicited to generate and send Map-Reply messages for the > > mappings they are serving. > > > > The distribution of xTR-IDs (and Site-IDs) are out of the scope of > > this document. > > <...> > > > > PPE - The section 3 is sparse and could define use cases in this section. In > a real life deployment, there may be a variety of use cases such as > > 1. an ITR/PITR/RTR joins an existing LISP network and subscribes to > specific existing EID prefixes updates (this is addressed in the intro) > > 2. an ITR/PITR/RTR joins "early" a growing LISP network and subscribes > to an EID prefix NOT YET present in the database ( covered by 8.4 in rfc > 9301? - more below) > > > > [AR] In this case PubSub follows the same logic defined in 9301. As in > 9301, “the least-specific prefix that both matches the original query and > does not match any EID-Prefix known” is computed and a subscription created > for this prefix. The creation of this subscription is kind of implicit in > the PubSub spec, and I agree with you that maybe we want to make this more > explicit. Thanks for bringing this up! We’ll clarify on -11. > PPE - Thanks for addressing this will help on clarity and readability. > > > 3. an ITR/PITR/RTR sends multiple requests where the range of prefix/len > is removed and readded are slightly different or overlapping, how do we > cover the use case of "holes"? > > > > [AR] Something to note is that in PubSub you get notifications for updates > on more-specific prefixes covered by the ones you’re subscribed to. This is > analogous to how in 9301 you would get more-specific records in a > Map-Reply. PubSub also sends notifications when a prefix is removed (and > subsequently, when a more-specific is removed). It’s true that the the > logic for handling more-specifics in PubSub was implicit in -09 but we > added some text in -10 to make it more explicit (Sec 6). Your question is > very valid, let us know if you feel the clarifications added in -10 help or > more clarifications are needed. > PPE- After reading -10 it addresses my comment > > > 4. scale - what if we have a large number of subscriptions - do we intend > them to be aggregated or rely on 5.5 in rfc 9301? > > > > [AR] As you point out, Section 5.5 of 9301 expects EID prefixes to be > aggregable to some extent. Since PubSub builds on top of 9301, the > assumptions should be not much different. > PPE- I suggest that you clarify these assumptions you are relying on 9301 because per your statement above "not much different" means it does not always do that. IMHO, it would improve on clarity. > The document would be much clearer if the processing expected for each of > these use cases were described explicitly. > > > > Consider, the pub sub mechanism is used to minimize the number of messages > exchanged and timing issues by using a triggered event solution. However, > it is unclear how it works for use case 2 when there is no existing EID > entry yet. Upon receiving a negative map reply should there be periodic > resend of SMR from the RTR/ITR/PITR? Or is the first SMR stored somewhere > on the Mapping System on a temporary entry and when the EID is added later > does it trigger the response? If the entry is temporary must the SMR > requestors renew their request- if so what periodicity? Can the two > behaviors coexist? > > > > [AR] Since PubSub follows 9301 logic, the current behavior would create > this “temporary entry” (as discussed above). Now, a periodic retry would be > very similar to what standard 9301 does without PubSub. If we want to > enable a retry model, we can introduce an optional configuration that > specifies that if a subscription request hits an EID prefix not registered > in the mapping-system, no PubSub operation takes place and a regular NMR is > returned from the MS (so we fall back to 9301 and thus retry behavior). How > does this sound? > PPE - yes this sound good to me. Please add it to -11. > > > If there is periodic resend until the EID entry is present then the pub > sub is still polling for an event rather than being event driven for the > first part of the process then the MS and requestors should have a > configuration that accounts for the polling or timing out of an entry. > > > > [AR] Yes, if we are to introduce this optional behavior where PubSub falls > back to standard 9301 on non-registered prefixes, we can specify that the > TTL to return in the negative map-reply could be configurable, which will > effectively control the polling/timeout intervals. > PPE- yes > > > As different implementations may have specific behaviors (e.g retry when > it receives a negative map reply or assumption a subscription is > preprovisioned) there is an implicit assumption both endpoints are acting > in a cooperative manner. Perhaps there is another deployment > assumption that the mapping system and the RTR/ITR/PITR have a > collaborative behavior (periodicity, polling mechanism, event trigger) by > config or default config. > > > > [AR] One implicit deployment assumption is that all devices involved > support rfc9301. By enabling the option of falling back to standard 9301 we > could achieve the behavior you suggest without additional machinery or > configuration, what do you think? > PPE - yes it would be great to make that explicit in the doc. > > > Thanks again for the review Padma, very good comments, hope the replies > help. > Thank again Alberto for this good doc. Looking forward to -11 Padma > > > Thanks! > > Alberto > > > > Thanks > > Padma > > > > > > > > [image: Image removed by sender.] > > > > On Fri, Dec 9, 2022 at 3:48 AM Jordi Paillissé <[email protected]> > wrote: > > +1 > > Jordi > > El 8/12/22 a les 22:18, Prakash Jain (prakjain) ha escrit: > > +1 > > - Prakash > > > > On 12/8/22, 8:09 AM, "lisp on behalf of Sharon Barkai" < > [email protected] on behalf of sharon.barkai= > [email protected]> wrote: > > > > ++ > > > > --szb > > Cell: +972.53.2470068 > > WhatsApp: +1.650.492.0794 > > > > > On Dec 8, 2022, at 18:02, Dino Farinacci <[email protected]> > wrote: > > > > > > > > >> > > >> Hi Luigi, all, > > >> > > >> I also think that it is reasonable to publish this spec as a > proposed standard. > > > > > > +1. > > > > > > Dino > > > _______________________________________________ > > > lisp mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
