Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub

Luigi Iannone <ggx@gigix.net> Wed, 03 February 2021 15:18 UTC

Return-Path: <ggx@gigix.net>
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 9A3A93A093D for <lisp@ietfa.amsl.com>; Wed, 3 Feb 2021 07:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_qFcN4bizZ3 for <lisp@ietfa.amsl.com>; Wed, 3 Feb 2021 07:18:34 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C6C3A08E4 for <lisp@ietf.org>; Wed, 3 Feb 2021 07:18:33 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id l12so4846591wmq.2 for <lisp@ietf.org>; Wed, 03 Feb 2021 07:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iAagv6NWTSmIK/+JuSWzNZtuObGdFNf8PX+hUhjtpX4=; b=no4Q90rrRGSnpyoTgQwHVCHprVdIizUzR5n11yz6ElE9QkJSPijYvlof2NSdBnE7jR 8/kCxalO1V4xAog971mTcVh1ZLsez8xsYNOJVQRRgmSSltrEgF5Fex1UzUbPo2BOGar4 YhcekIpCEYMBA5Tb0QWR/5CZ3cRTnKF3AW2vVYnmT3zIWCBEf7Xa/C/aDOz8ZiCrBkFy KF0KNG6agYQ1D+WR5ql4yJPvLdFeLoLEqx3zr885ot6fwzECw4UUSyhNLuW6hKYGoi+c MK7VbOSy8ahpF1BPywqejDRugfOIB7S1pgMxopD/nD2j8pF8C2gPTIqQpdKzjMRlbYyw u14w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iAagv6NWTSmIK/+JuSWzNZtuObGdFNf8PX+hUhjtpX4=; b=Ip97imeIkiARXOutXW9vCPmWHddvRmfT7TLuoNQgSHYFvKSf8TrI5EVfvQ5qqw4wjE VH2szR8hSwtnynBRAFp203F6VWsn27a0DA/Y0x02JVfQ12hug6qma1fTFxOmTwZMfHo1 uSYwiql2/P1vbop2/avTvReGUUCOhmrushRoNkkotYCRYBuarsLtqrN4yB70Iu2dCyFQ QyDSdlP0vr2fW5uI2CLM/2eCCC5JhxbnupMteijyt6INzWPImn51y2c/4cxwR41hbDmR vUlBWJf2PkZbO3bAwE7vvrpgLFealT4YZKQrqvbiDBgKpZx3pq/aTv1lFpkdQuFuEzR/ 9lnw==
X-Gm-Message-State: AOAM531nU/D2j8c0ocsrs8eYZ2pOLqoxMfDCT7jTPGImKy7WWvEXGA5m AlBdN+4gKbWc5goR/wK3QKWH7KF0KzXazg==
X-Google-Smtp-Source: ABdhPJxqwnWygIzUTfDig7ihJJ0RYtUF43WhttpmmRigGHTIbPDzkX/eNC6DYaNKkxX/ztahxdOM1A==
X-Received: by 2002:a1c:7409:: with SMTP id p9mr2617934wmc.95.1612365511357; Wed, 03 Feb 2021 07:18:31 -0800 (PST)
Received: from ?IPv6:2a01:e0a:1ec:470:69a5:1821:fc12:2895? ([2a01:e0a:1ec:470:69a5:1821:fc12:2895]) by smtp.gmail.com with ESMTPSA id e16sm4109335wrp.24.2021.02.03.07.18.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 07:18:30 -0800 (PST)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <DBE8A84C-76AD-47DA-BC18-99F949A75D24@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3033A9A8-6DEE-4ED0-AE65-5E838716B5D9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Wed, 3 Feb 2021 16:18:29 +0100
In-Reply-To: <2DED786D-9FE8-45A9-9C51-E726B69D2FE8@cisco.com>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
To: "lisp@ietf.org list" <lisp@ietf.org>
References: <D1C7BD0C-30C6-4A14-82D4-FB7748F70EE5@gigix.net> <26AD53D1-BF1A-4812-98C6-B092C85409C3@cisco.com> <15144_1610977729_600591C1_15144_61_25_787AE7BB302AE849A7480A190F8B9330315BC1F4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9055BFF5-BAA6-4796-B42A-779F12B47D06@cisco.com> <1976_1610981428_6005A034_1976_310_5_787AE7BB302AE849A7480A190F8B9330315BC2EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63D309EF-96FB-4053-8A80-75A1AFCE4ADD@cisco.com> <2DED786D-9FE8-45A9-9C51-E726B69D2FE8@cisco.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/FYSDiW8W6_u2yreuR6uunzENnlw>
Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 15:18:37 -0000

Thanks Alberto,

BTW the WG LC ended last week and we received several emails in support of the document, which means that there is consensus to move the document forward.

Thanks to all those that replied and discussed the document.

Ciao

L.
 

> On 3 Feb 2021, at 04:18, Alberto Rodriguez-Natal (natal) <natal@cisco.com> wrote:
> 
> New version is up now.
>  
> Alberto
>  
> From: "Alberto Rodriguez-Natal (natal)" <natal@cisco.com>
> Date: Tuesday, January 19, 2021 at 12:51 PM
> To: Eliot Lear <lear@cisco.com>
> Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>om>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>rg>, "lisp@ietf.org list" <lisp@ietf.org>
> Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub
>  
> Hi Eliot,
>  
> Thanks for the feedback! As Med mentioned we have made a small clarifying edit in the text. Please find the diff attached.
>  
> I’ll wait a bit before sending the new version in case there are other small changes to make during the WGLC process.
>  
> Thanks!
> Alberto
>  
> From: lisp <lisp-bounces@ietf.org> on behalf of "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
> Date: Monday, January 18, 2021 at 6:51 AM
> To: Eliot Lear <lear@cisco.com>
> Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>rg>, "lisp@ietf.org list" <lisp@ietf.org>
> Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub
>  
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Eliot Lear [mailto:lear@cisco.com] 
> Envoyé : lundi 18 janvier 2021 14:57
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : Luigi Iannone <ggx@gigix.net>et>; lisp-chairs@ietf.org; lisp@ietf.org list <lisp@ietf.org>
> Objet : Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub
>  
> Hi Med,
>  
> Ok, I misread that text as the processing of an error condition.
>  
> [Med] We will consider tweaking that text for better clarity.
>  
>  This raises a few questions:
>  
> What happens if an xTR wants to *add* subscriptions?  Do they just do another map request with the N bit set on new EIDs?
>  
> [Med] Yes.
>  
> If that same request contains EIDs that had previously had the N bit set but no longer do? Does the ETR just process it as it would have previously and keep sending map updates for those EIDs or is that an error?
>  
> [Med] EIDs with N-bit unset will be handled as per the base LISP spec. Given that these EIDs used to have N-bit set, updates will still be notified till the TTL expires for these EIDs and then:
>  
>    When the TTL for the EID-record
>    expires, the EID-prefix is removed from the Map-Server's subscription
>    cache.  On EID-Record removal, the Map-Server notifies the
>    subscribers via a Map-Notify with TTL equal 0.
> Eliot
> 
> 
> 
> 
>> On 18 Jan 2021, at 14:48, mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> wrote:
>>  
>> Hi Eliot, all,
>>  
>> The procedure to unsubscribe is covered by the following:
>>  
>>    If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown
>>    Address), the Map-Server MUST remove the subscription state for that
>>    xTR-ID.
>>  
>> We discussed among the authors back in 2017 whether the procedure should allow to select the EIDs for which an ITR can unsubscribe, but the agreement was to keep the spec simple. Hence the above text.
>>  
>> Cheers,
>> Med
>>  
>> De : lisp [mailto:lisp-bounces@ietf.org <mailto:lisp-bounces@ietf.org>] De la part de Eliot Lear
>> Envoyé : lundi 18 janvier 2021 14:12
>> À : Luigi Iannone <ggx@gigix.net <mailto:ggx@gigix.net>>
>> Cc : lisp-chairs@ietf.org <mailto:lisp-chairs@ietf.org>; lisp@ietf.org <mailto:lisp@ietf.org> list <lisp@ietf.org <mailto:lisp@ietf.org>>
>> Objet : Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub
>>  
>> Just poking my nose in here, this is a cool draft. I say, go for it.  Depending on implementation, it may address the very problem I was attempting to solve with NERD: that first dropped packet.
>>  
>> I have one small suggestion and a question:
>>  
>> The suggestion:
>>  
>> It would be useful to discuss what statistics should be kept when experimenting.  Specifically: number of subscribes (prior to or after the first time one saw an EID), the number of map updates over time (I’m betting there’s a lot of stability out there, but that’s just me), number of subscribers.
>>  
>> The question:
>>  
>> How would an xTR UNsubscribe from mapping notifications?  I would imagine this would amount to a new map request that clears the N bit for appropriate EID-Records?
>>  
>> Eliot
>>  
>>  
>> 
>> 
>> 
>> 
>> 
>>> On 13 Jan 2021, at 08:19, Luigi Iannone <ggx@gigix.net <mailto:ggx@gigix.net>> wrote:
>>>  
>>> Hi All,
>>>  
>>> The authors of  draft-ietf-lisp-pubsub submitted a new version addressing the issues raised during SECDIR review.
>>> The document seems mature and stable and authors are asking for formal WG Last Call.
>>>  
>>> This email open the usual two weeks Working Group Last Call, to end January 28th, 2021.
>>>  
>>> Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
>>> If you have objections, please state your reasons why, and explain what it would take to address your concerns.
>>>  
>>> NOTE: silence IS NOT consensus!
>>>  
>>> Thanks
>>> 
>>> Luigi & Joel
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org <mailto:lisp@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
>>  
>> _________________________________________________________________________________________________________________________
>>  
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
> 
>  
> _________________________________________________________________________________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.