see below On Thu, Jan 5, 2023 at 4:18 AM Luigi Iannone <[email protected]> wrote:
> > > On 5 Jan 2023, at 12:16, Alberto Rodriguez-Natal (natal) <natal= > [email protected]> wrote: > > > > Hi Padma, > > > > Thanks a lot for your feedback! Let me spin out a new thread to better > address your comments. > > > > We were about to submit version -10 of the document addressing (hopefully) > all the feedback received so far (which has been significant). If it is > fine with you, I’ll still proceed with submitting version -10 (today or > tomorrow, likely) in its current form. Then we can discuss your latest > feedback here and any potential changes coming from the discussion can go > into -11, sounds good? > > > Also, given that there seems to be support for moving the document to > Standards Track, I’ll submit version -10 as Standards already, hoping this > is fine. > > > Hi Alberto, > > Yes, it is fine. Pad an and myself already discussed about it and we agree > that the WG is OK to move this document to PS. > > Ciao > > L. > > > > > > > Regarding your feedback below, I think you’re making some good questions. > Let me put together some text to address your comments. I’ll get back to > you shortly. > > PPE - looking forward and thanks! Padma > > > Thanks! > > Alberto > > > > *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. > > > > 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. > > > > <...> > > 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) > > 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"? > > 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? > > > > 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? > > > > 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. > > > > 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. > > > > 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 > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
