From nobody Sat Jan 28 11:02:06 2023 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2EC14CF05 for ; Sat, 28 Jan 2023 11:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtqAPBlNKmYu for ; Sat, 28 Jan 2023 11:02:01 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BECC14CEFE for ; Sat, 28 Jan 2023 11:02:01 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id me3so21758746ejb.7 for ; Sat, 28 Jan 2023 11:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XSEt/JkzlLg5lT/9X0/MSvbdWBe9u8bcLBSz0RS+GOc=; b=P+SDXL/b11t7A5xoQly3Yn6mNbRwrVOGH/a7+sgKl/e+VZsXrthRp76X1nWnWzk7Mp S1ib3L9k5tb4/hqvnm1oPqepxXxDxc832iozFMUiGFCrITNkUo6pfTpoEBcGdgwC57aU Q73VBKsztm+RT7DJoTb7/z2hSHmjL3mJBZ2MXMtl7S6EMvU5HV5pjikru7xIkNFgwJSR eQfbVbF+q2ymdC1SvpXiNuCR3utSl0+oFBKMeerin0QmbBpGHo+RXdBFpX7v2uzFy5l6 yyasZjrgSE0bxpPQEt6Zq1DQfUOJ1iPFPN3k1/3GqlsZ+rH1zg3B06B+W8vUlxUKIjrA YK1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XSEt/JkzlLg5lT/9X0/MSvbdWBe9u8bcLBSz0RS+GOc=; b=e5L6NsONo9aa4Tw8QfpFRBOnBT/o6sORTxBp+nMSkqVJ58oLn2UtsqjevHxcTOqipE EQ+Uptmx5iDd+c6NG5xyxbFqz88mlOSlJmpqDeppne8vm48ANjkiktjN1l0JuX5IFC+h isb6n/KWTSZhCxkTa918JI/7K8ZaAjlKUw5zGCO1sV95ckyFKaZBBCQY3G27q9m9VrLc l5ZDq7jK+Bggkamj8CGV7eGNZtZjlyxRMBqwU7v/tW609Jb5BoPT5Qne3Nkq1vzzigKQ Ad9JeF/vwt0m6pkTbL99lBC+ChFkvriyaBGI04nBMJzGSaubSu0M2WVI5jc/tckBcRwe 7xuA== X-Gm-Message-State: AO0yUKWNQfayR+r8ucMvcJTyi7fDV5WSFGumphcE4nwMkSXxREJSQoWr kdbhsebAogHHy2FkueoEwd4UqEvlOOu5gt7+UGE= X-Google-Smtp-Source: AK7set/ldq1RIZlSAXPP7oAfxHD9BEyIC/X/VoJuklJxEQsiQRCUVHloEa+cwyaBwZpd+0rAlXyZLxVxhAvs64Nlxwo= X-Received: by 2002:a17:906:e90:b0:878:79fb:5392 with SMTP id p16-20020a1709060e9000b0087879fb5392mr2273701ejf.6.1674932519824; Sat, 28 Jan 2023 11:01:59 -0800 (PST) MIME-Version: 1.0 References: <77DA03FA-6E1E-4452-ADA2-3883CF844334@getnexar.com> In-Reply-To: From: Padma Pillay-Esnault Date: Sat, 28 Jan 2023 11:01:47 -0800 Message-ID: To: "Alberto Rodriguez-Natal (natal)" Cc: "lisp@ietf.org" , Padma Pillay-Esnault Content-Type: multipart/alternative; boundary="000000000000ddf1ec05f3579dd0" Archived-At: Subject: Re: [lisp] Padma's feedback on PubSub -09 [was: Re: LISP PubSub to Proposed Standard?] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2023 19:02:05 -0000 --000000000000ddf1ec05f3579dd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alberto Thank you for addressing my comments. See below On Wed, Jan 18, 2023 at 11:44 PM Alberto Rodriguez-Natal (natal) < natal@cisco.com> wrote: > Hi Padma, > > > > Thanks again for the feedback! You=E2=80=99re making some good points. Pl= ease see > below for some comments inline with [AR]. > > > > *From: *lisp on behalf of Padma Pillay-Esnault < > padma.ietf@gmail.com> > *Date: *Thursday, January 5, 2023 at 8:29 AM > *To: *Alberto Rodriguez-Natal (natal) > *Cc: *lisp@ietf.org , Sharon Barkai 40getnexar.com@dmarc.ietf.org>, Jordi Pailliss=C3=A9 > *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 mayb= e > 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 thi= nk? > > > > 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=E2=80=99m 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, =E2=80=9Cthe least-specific prefix that both matches the original q= uery and > does not match any EID-Prefix known=E2=80=9D is computed and a subscripti= on 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 mor= e > explicit. Thanks for bringing this up! We=E2=80=99ll 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 update= s > on more-specific prefixes covered by the ones you=E2=80=99re subscribed t= o. 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=E2=80=99s true that th= e 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 message= s > 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 late= r > 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 =E2=80=9Ctemporary entry=E2=80=9D (as discussed above). Now, a perio= dic 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 registere= d > 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). H= ow > 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 fall= s > 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=C3=A9 > wrote: > > +1 > > Jordi > > El 8/12/22 a les 22:18, Prakash Jain (prakjain) ha escrit: > > +1 > > - Prakash > > > > =EF=BB=BFOn 12/8/22, 8:09 AM, "lisp on behalf of Sharon Barkai" < > lisp-bounces@ietf.org on behalf of sharon.barkai=3D > 40getnexar.com@dmarc.ietf.org> wrote: > > > > ++ > > > > --szb > > Cell: +972.53.2470068 > > WhatsApp: +1.650.492.0794 > > > > > On Dec 8, 2022, at 18:02, Dino Farinacci > wrote: > > > > > > > > >> > > >> Hi Luigi, all, > > >> > > >> I also think that it is reasonable to publish this spec as a > proposed standard. > > > > > > +1. > > > > > > Dino > > > _______________________________________________ > > > lisp mailing list > > > lisp@ietf.org > > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --000000000000ddf1ec05f3579dd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alberto

Thank you for add= ressing my comments. See below=C2=A0


On Wed, Jan 18, 2023 at = 11:44 PM Alberto Rodriguez-Natal (natal) <natal@cisco.com> wrote:

Hi Pad= ma,

=C2=A0

Thanks= again for the feedback! You=E2=80=99re making some good points. Please see= below for some comments inline with [AR].

=C2=A0<= /span>

From: lisp <lisp-bounces@ietf.org> on behalf of Padma P= illay-Esnault <padma.ietf@gmail.com>
Date: Thursday, January 5, 2023 at 8:29 AM
To: Alberto Rodriguez-Natal (natal) <natal=3D40cisco.com@dmarc.ietf.org&= gt;
Cc: lisp@ietf.org= <lisp@ietf.org>, Sharon Barkai <sharon.barkai=3D40getnexar.com@dmarc.ietf.org>, Jo= rdi Pailliss=C3=A9 <jordi.paillisse@upc.edu>
Subject: Re: [lisp] LISP PubSub to Proposed Standard?<= u>

Dear Alberto and authors

=C2=A0

Thank you for the good work on this doc. I fully support moving this = document as a proposed standard, =C2=A0however I have a few comments on the= document. See PPE below

1.=C2=A0 Introduction
<...>
=C2=A0=C2=A0 In general, when an ITR/RTR/PITR wants to be notified fo=
r mapping
=C2=A0=C2=A0 ch=
anges for a given EID-prefix, the following steps occur:
=C2=A0
=C2=A0=C2=A0 (1=
)=C2=A0 The ITR/RTR/PITR sends a Map-Request for that EID-prefix.=

=C2=A0
=C2=A0=C2=A0 (2=
)=C2=A0 The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Map-Request and includes its xTR-ID and Sit=
e-ID.
=C2=A0
=C2=A0=C2=A0 (3=
)=C2=A0 The Map-Request is forwarded to one of the Map-Servers that the
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 EID-prefix is registered to.
=C2=A0
=C2=A0=C2=A0 (4=
)=C2=A0 The Map-Server creates subscription state for the ITR/RTR/PITR
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 on the EID-prefix.
=C2=A0
=C2=A0=C2=A0 (5=
)=C2=A0 The Map-Server sends a Map-Notify to the ITR/RTR/PITR to<=
/u>
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 acknowledge the successful subscription.=

=C2=A0
=C2=A0=C2=A0 (6=
)=C2=A0 When there is a change in the mapping of the EID-Prefix, the=

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Map-Server sends a Map-Notify message to each I=
TR/RTR/PITR in
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 the subscription list.

=C2=A0


=C2=A0=C2=A0 (7=
)=C2=A0 Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the<=
u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 received Map-Notify.


=C2=A0


=C2=A0=C2=A0 Th=
is operation is repeated for all EID-prefixes for which ITR/RTR/<=
/u>


=C2=A0=C2=A0 PI=
TR want to be notified.=C2=A0 The ITR/RTR/PITR can set the N-bit for=



=C2=A0=C2=A0 se=
veral EID-prefixes within a single Map-Request.


<...>

PPE - =C2=A0This section relies on section 6.1 of rfc 9301 and gives = as an example the simplest use case. The concluding paragraph also gives th= e 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.

=C2=A0

[AR] Y= es, 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 not= e to mention that this the simplest example and that the details for this and other cases are found later in t= he document, what do you think?

=C2=A0<= /span>

I suggest removing this from the introduction and instead clearly def= ine the scope and then define all the use cases as in a real deployment sce= nario in section 3. See more about this below.

=C2=A0

[AR] I= have no strong opinion about removing the simple example from the intro. I= =E2=80=99m 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 remo= ving but we should add a note as you suggest to clarify

=C2=A0<= /span>

<...>

3.=C2=A0 Deployment Assumptions
=C2=A0
=C2=A0=C2=A0 Th=
e specification described in this document makes the following
=C2=A0=C2=A0 de=
ployment assumptions:
=C2=A0
=C2=A0=C2=A0 (1=
)=C2=A0 A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 assigned to each xTR.

=C2=A0


=C2=A0=C2=A0 (2=
)=C2=A0 Map-Servers are configured in proxy-reply mode, i.e., they are


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 solicited to generate and send Map-Reply messag=
es for the


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 mappings they are serving.=



=C2=A0


=C2=A0=C2=A0 Th=
e distribution of xTR-IDs (and Site-IDs) are out of the scope of<=
/u>


=C2=A0=C2=A0 th=
is document.

<...>

=C2=A0

PPE -=C2=A0The section 3 is sparse and could define use cases in this= section.= =C2=A0=C2=A0In a real life deployment, there may be a variety of use cases such as=C2=A0

1. an ITR/PITR/RTR joins an existing LISP network and subscribes to s= pecific existing EID prefixes updates (this is addressed in the intro)

2. an ITR/PITR/RTR=C2=A0=C2=A0joins "early" a growing LISP net= work and subscribes to an EID prefix NOT YET present in the database ( cove= red by 8.4 in rfc 9301? - more below)=C2=A0

=C2=A0

[AR] I= n this case PubSub follows the same logic defined in 9301. As in 9301, =E2= =80=9Cthe least-specific prefix that both matches the original query and do= es not match any EID-Prefix known=E2=80=9D is computed and a subscription created for this prefix. The creation of this subscript= ion 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=E2=80= =99ll clarify on -11.

<= /blockquote>

PPE - Thanks for addressing this will help = on clarity and readability.=C2=A0

=C2=A0

3. an ITR/PITR/RTR=C2=A0sends multiple requests where the range of pr= efix/len is removed and readded are slightly=C2=A0different or overlapping,= how do we cover=C2=A0the use case of "holes"?=C2=A0

=C2=A0

[AR] S= omething to note is that in PubSub you get notifications for updates on mor= e-specific prefixes covered by the ones you=E2=80=99re 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 r= emoved (and subsequently, when a more-specific is removed). It=E2=80=99s tr= ue 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
=C2=A0=

=C2=A0

4. scale - what if we have a large number of subscriptions - do we in= tend them to be aggregated or rely on 5.5 in rfc 9301?=

=C2=A0

[AR] A= s 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.=C2=A0

=

PPE- I suggest that you clarify thes= e assumptions you are relying on 9301 because per your statement above &quo= t;not much different" means it does not always do that. IMHO, it would= improve on clarity.
=C2=A0=

The document would be much clearer if the processing expected for eac= h of these use cases were described explicitly.

=C2=A0

Consider, the pub sub mechanism is used to minimize the number of mes= sages exchanged and timing issues by using a triggered=C2=A0event solution.= However, it is unclear how it works for use case 2=C2=A0=C2=A0when there is no existing EID entry yet.=C2=A0 Upon rec= eiving a negative map reply should there=C2=A0be periodic resend of SMR fro= m the RTR/ITR/PITR? Or is the first SMR stored somewhere on the Mapping Sys= tem on a temporary entry and when the EID is added later does it trigger the r= esponse? If the entry is temporary must the SMR requestors renew their requ= est- if so what periodicity? Can the two behaviors coexist?

=C2=A0

[AR] S= ince PubSub follows 9301 logic, the current behavior would create this =E2= =80=9Ctemporary entry=E2=80=9D (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 c= onfiguration that specifies that if a subscription request hits an EID pref= ix not registered in the mapping-system, no PubSub operation takes place an= d a regular NMR is returned from the MS (so we fall back to 9301 and thus retry behavior). How does this so= und?

=
PPE - yes this sound good to me. Please add it to -11.=C2=A0=

=C2=A0<= u>

If there is periodic resend until the EID entry is present then the= =C2=A0pub sub is still polling for an=C2=A0event rather than being event dr= iven for the first part of the process then the MS and requestors should have a configuration that accounts for the pollin= g or timing out of an entry.=C2=A0

=C2=A0<= /span>

[AR] Y= es, if we are to introduce this optional behavior where PubSub falls back t= o 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 interv= als.

=
PPE- yes=C2=A0

=C2=A0

As different=C2=A0implementations may have specific behaviors (e.g re= try when it receives a negative map reply or assumption a subscription is p= reprovisioned) there is an implicit assumption both endpoints are acting in a cooperative manner.=C2=A0 Perhaps there is = another deployment assumption=C2=A0that the mapping system and the RTR/ITR/= PITR have a collaborative behavior (periodicity, polling mechanism, event t= rigger) by config or default config.

=C2=A0<= /span>

[AR] O= ne implicit deployment assumption is that all devices involved support rfc9= 301. By enabling the option of falling back to standard 9301 we could achie= ve 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=C2=A0doc.=C2=A0

=C2=A0

Thanks= again for the review Padma, very good comments, hope the replies help.


Thank again Alberto for this good doc. Looking forward to -11
<= div>
Padma=C2=A0

=C2=A0

Thanks= !

Albert= o

=C2=A0

Thanks

Padma

=C2=A0

=C2=A0

=C2=A0

3D"Image

=C2=A0

On Fri, Dec 9, 2022 at 3:48 AM Jordi Pailliss=C3=A9 <jordi.paillisse@upc.edu> wrote:

+1

Jordi

El 8/12/22 a les 22:18, Prakash Jain (prakjain) ha escrit:
> +1
> - Prakash
>
> =EF=BB=BFOn 12/8/22, 8:09 AM, "lisp on behalf of Sharon Barkai&qu= ot; <<= span style=3D"font-size:11pt">lisp-bounces@ietf.org on behalf of sharon.barkai=3D40getnexar.com@dmarc.ietf.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 ++
>
>=C2=A0 =C2=A0 =C2=A0 --szb
>=C2=A0 =C2=A0 =C2=A0 Cell: +972.53.2470068
>=C2=A0 =C2=A0 =C2=A0 WhatsApp: +1.650.492.0794
>
>=C2=A0 =C2=A0 =C2=A0 > On Dec 8, 2022, at 18:02, Dino Farinacci <= farinacci@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Hi Luigi, all,
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> I also think that it is reasonable to pub= lish this spec as a proposed standard.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > +1.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Dino
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > lisp mailing list
>=C2=A0 =C2=A0 =C2=A0 > lisp@ietf.org
>=C2=A0 =C2=A0 =C2=A0 > https://w= ww.ietf.org/mailman/listinfo/lisp=
>
>=C2=A0 =C2=A0 =C2=A0 _______________________________________________ >=C2=A0 =C2=A0 =C2=A0 lisp mailing list
>=C2=A0 =C2=A0 =C2=A0 lisp@ietf.org
>=C2=A0 =C2=A0 =C2=A0 https://www.ie= tf.org/mailman/listinfo/lisp
>

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/l= isp

--000000000000ddf1ec05f3579dd0--