Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)

Albert Cabellos <albert.cabellos@gmail.com> Sun, 20 September 2020 21:58 UTC

Return-Path: <albert.cabellos@gmail.com>
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 992C03A0F09; Sun, 20 Sep 2020 14:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3wqpE35Z7Wh; Sun, 20 Sep 2020 14:58:37 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 D70263A0B5C; Sun, 20 Sep 2020 14:58:36 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id g4so11061843edk.0; Sun, 20 Sep 2020 14:58:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Hp7c2y8Lu3n3+HDAl1V4l3cGeTWch1yvxCwxgCrUnR8=; b=fBw6ZTH3n3v+XjMvOmHKkbkVssimj1aoSbt7S40l3NpPcj2PJRFES4vdWoCS/WOR08 +RTShwlrPDQpwOmWxzWWB5X3jI64UewKZLepDqZZZAIt6Ra9JF3X5u6o6zHKtpwRABUw jc/aCAo4jUdMt8mt11cNwlrtk5yk8HqyNyUpPctjEkxQGySsKiL+ZaByT0NDduob4NJm G/MxkF3ISgNp8cTLL8tfPbv0SAXZUyMjlzQy3aexpY3DUICByzHhfWmQuTbiETGMP/HT 5ByexpqDTtIPbqgz5ibiYI7KH7oEjYzkI+xLNKL06p2UpzZZXJe/gIZZHLoIwMHkY0RO lz2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Hp7c2y8Lu3n3+HDAl1V4l3cGeTWch1yvxCwxgCrUnR8=; b=qe3uS7Qi+aNaZaaWjbDDyttZdIpYyHptVoD2t05U1sxvAXYy1PUmeQ2PFkJwUrXC3d BzsxYtVEobwe0a3jNbwRk2QvBaGyYBvd76GLbPYq/0PQITvh0CjabrsnFvj7n4LRCMxW w3O9LQSI8XK97j50C1KEp/cgbWorcF8WuztjSgr8zq0FuPAz15JsdFjBUVvFNJf0ZYVT MLm6n3ybCLKkC5/Bv7CniTRKOCF4aSDMsS8kuRI4srbFFedHCgRxPL6og1vWfbZBh6nR MCew45aoI2iUTrpCXfDzAckxhNfEIOx3QCbjsJBAZCfL7e3wo8yyQBdul2S5cX4kVIMX HCLw==
X-Gm-Message-State: AOAM530HNH/2PFqXxfCPwSBuS9h5866vFN+USEQOi6uQJSijDiewn9Xa DdLNvCYVuKsagw3ZsbTq499lZbVhpq+vZfb9kMk=
X-Google-Smtp-Source: ABdhPJzenTNAlesKSDIcwMjJtv5v6JaAWr5HcsUZEZzE+X873GbyOOGfbMx2q6PLwuOuVbF8ru/RhCwPuMoSTBA4clw=
X-Received: by 2002:aa7:cb83:: with SMTP id r3mr48543263edt.35.1600639115213; Sun, 20 Sep 2020 14:58:35 -0700 (PDT)
MIME-Version: 1.0
References: <159407591285.9648.16019424277537020150@ietfa.amsl.com>
In-Reply-To: <159407591285.9648.16019424277537020150@ietfa.amsl.com>
From: Albert Cabellos <albert.cabellos@gmail.com>
Date: Sun, 20 Sep 2020 23:58:24 +0200
Message-ID: <CAGE_QezhP1M=7eRnsyYD_rSrR4yhHPJ+W7jet0rHyZcTgLik8Q@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/F6G-yqq0SijCYD-ScrUQ7sv6aLk>
Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)
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: Sun, 20 Sep 2020 21:58:39 -0000

Hi

I´ve posted -28 updating the text following your comments, please find
inline additional information:

https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/


On Tue, Jul 7, 2020 at 12:52 AM Martin Duke via Datatracker
<noreply@ietf.org> wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-lisp-rfc6833bis-27: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Two issues rise to DISCUSS level, IMO:
>
> Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they are
> unsolicited? If not, repeated Map-Registers could result in a storm of
> Map-Notifies.
>

6833bis specs that Map-Notifies are retransmitted when Map-Notify-Ack
are not received.

The behaviour of unsolicited Map-Notifies are NOT spec’ed in 6833bis,
this is specified in draft-ietf-lisp-pubsub

What 6833bis specs -per a review by Mirja- is that if an unsolicited
Map-Notify is sent, then it will follow the guidelines of RFC8085


> Sec 7.1. I very well may have missed something, but it doesn't look like the
> Map-Request is authenticated. So how can the ETR safely update its Map Cache
> based on the information in the Map-Reply?
>

The Map-Request is just a query to an EID, and as such it is not authenticated.
The Map-Reply carries the response to such query, an EID-to-RLOC
mapping. This query is authenticated.  The Map-Cache is updated based
on the received EID-to-RLOC mapping.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Sec. 5. Please clarify that the 576B and 1280B limits include the entire IP packet.

Changed, thanks.

>
> Sec 5.4. Does the "weight" refer to the percentage of packets or bytes?
>

This is already clarified (IMO): "Weight is encoded as a relative
weight of total unicast packets that match the mapping entry."

> Sec 5.5. The first sentence should suggest that the Map Reply could return multiple EID prefixes.

The first sentence reads “A Map-Reply returns an EID-Prefix with…”,
IMHO it is already clear. Thanks!

>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp