Thanks Luigi, Padma, I have now submitted version -10 of the draft as Standard Track.
Thanks! Alberto From: Padma Pillay-Esnault <[email protected]> Date: Thursday, January 5, 2023 at 8:49 PM To: Luigi Iannone <[email protected]>, Alberto Rodriguez-Natal (natal) <[email protected]> Cc: [email protected] <[email protected]>, Padma Pillay-Esnault <[email protected]> Subject: Re: [lisp] Padma's feedback on PubSub -09 [was: Re: LISP PubSub to Proposed Standard?] see below On Thu, Jan 5, 2023 at 4:18 AM Luigi Iannone <[email protected]<mailto:[email protected]>> wrote: On 5 Jan 2023, at 12:16, Alberto Rodriguez-Natal (natal) <[email protected]<mailto:[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]<mailto:[email protected]>> on behalf of Padma Pillay-Esnault <[email protected]<mailto:[email protected]>> Date: Thursday, January 5, 2023 at 8:29 AM To: Alberto Rodriguez-Natal (natal) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Sharon Barkai <[email protected]<mailto:[email protected]>>, Jordi Paillissé <[email protected]<mailto:[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 Error! Filename not specified. On Fri, Dec 9, 2022 at 3:48 AM Jordi Paillissé <[email protected]<mailto:[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]<mailto:[email protected]> on behalf of > [email protected]<mailto:[email protected]>> > wrote: > > ++ > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > > > On Dec 8, 2022, at 18:02, Dino Farinacci > <[email protected]<mailto:[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]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
