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

Martin Duke <martin.h.duke@gmail.com> Wed, 28 October 2020 16:03 UTC

Return-Path: <martin.h.duke@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 40AE33A0BDB; Wed, 28 Oct 2020 09:03:31 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 yzhr6sTqMQbw; Wed, 28 Oct 2020 09:03:29 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 1D8D43A0997; Wed, 28 Oct 2020 09:03:17 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id a20so5106915ilk.13; Wed, 28 Oct 2020 09:03:17 -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; bh=MuZfscQ2NFHV4LjL/VgchtaykJp6CnPeVwexxrnP8sA=; b=u8y3X3sPWS03dv8AZst5M3UNNElAIZO2NwdKk6S2vKplS2+YvbFS0lxr9iyg0D5Qsn hXtMWL4vyRlY+NGtiDXEpMfMiEHRpW+ItdUOQtf70F8tSIwceKCORP+t7VfkvxP1ZYHM z+BLf92WYYwoB9niFGyY3pv43mnjgoFu8GAwqADiE6CZHsGUEAAoAOJvHIyCmAn5dxGF 46KgcjP88ZuZjyHlkk3Xa1/ycIV2zc+XoiEN6UBD2qv8XYpvU98nTino4to7igsijJfA /hiGaMpClAkaLQAkV2JoR+6Fy8K94Py4GQzrYjDKduy8t6HP8XLiNmhOWsbQ5MnRLNm2 I3LQ==
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; bh=MuZfscQ2NFHV4LjL/VgchtaykJp6CnPeVwexxrnP8sA=; b=UQ6ZF6HSM/GpL34Fqe2fqE8f2iAwTcT044udi512vZWLOafqZdWoP2023Xa692CL3n OmlUWdR1N2wd/D8pbpB/Qx5a9FOvhg1BJ/WJ671SXuawq6LhlewLi5/J/BGJ/FHgx3H7 lBSqBmwQgaeAxNQJ8rMja3WGyJsp9GOAZYzWT7/+4F6kFoyadL/Ic+bD1F/cMjQk04C/ ItLJK+8BzkOAGWEo9132Y2VWWLXtGSjXS7K+97HCNkoayHGNWNJxYmkE6C89Zyqj2AmB p0EYLlpPcd9ut65ZmWl5Hj+EsOux7eXWuMYaROpqSoQY5j28YM7SQo9dWmkCFZgDzoXM ysnQ==
X-Gm-Message-State: AOAM532CsNwD67dI+9/AZYmdtfwBpmRI1M6dXW6qEaszOdxWkGJmihrY YyAmHkt3lPtDZ+83ME4JwJAhbwZYQ6BBcHMO0UAIlnDe/nxYrA==
X-Google-Smtp-Source: ABdhPJwEXbbwpyjxMx8C2PEDnxSEeInYyRIgCzpWtFKOMncK98ECPdCcFRJSvlZTqSyunUYkhJ1gIs6hldQ2pbQvPF4=
X-Received: by 2002:a05:6e02:1388:: with SMTP id d8mr6314856ilo.272.1603900995227; Wed, 28 Oct 2020 09:03:15 -0700 (PDT)
MIME-Version: 1.0
References: <159407591285.9648.16019424277537020150@ietfa.amsl.com> <CAGE_QezhP1M=7eRnsyYD_rSrR4yhHPJ+W7jet0rHyZcTgLik8Q@mail.gmail.com>
In-Reply-To: <CAGE_QezhP1M=7eRnsyYD_rSrR4yhHPJ+W7jet0rHyZcTgLik8Q@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 28 Oct 2020 09:03:04 -0700
Message-ID: <CAM4esxSjH35TDDJ-xW=c_zhx24Lp5LxS-b4nzu3qMJMTwxzCUw@mail.gmail.com>
To: Albert Cabellos <albert.cabellos@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: multipart/alternative; boundary="00000000000013569e05b2bd4d6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/TXQ1rWyiMz-NKxjU4tJJahE_y5c>
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: Wed, 28 Oct 2020 16:03:39 -0000

Hi,

>
> > 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
>

If I parse your answer correctly, the answer to my question is 'no'. So in
the scenario where the Map-Notify is lost, both the Map-Register and the
Map-Notify are on retransmission timers. The most straightforward reading
of the text is that
- I respond to every Map-Register with a Map-Notify (if it requests it)
- For every Map-Notify I send, I start a retransmission timer.

Imagine a path where Map-Notifies are being consistently lost due to some
sort of temporary half-duplex outage. The packet schedule is thus:

0s: Map-Register
0+eps: Map-Notify #1 (Lost)
1s: Map-Register
1+eps: Map-Notify #2 (Lost)
3s: Map-Register
3+eps: Map-Notify #3 (Lost)
3+eps: Map-Notify (retransmission of #1, lost)
4+eps: Map-Notify (retransmission of #2, lost)
6+eps: Map-Notify (retransmission of #1, lost)
6+eps: Map-Notify (retransmission of #3, lost)
7s: Map-Register
7+eps: Map-Notify #4 (Lost)
7+eps: Map-Notify (retransmission of #2, lost)
9+eps: Map-Notify (retransmission of #1, lost)
9+eps: Map-Notify (retransmission of #3, lost)
10+eps: Map-Notify (retransmission of #4, lost)
10+eps: Map-Notify (retransmit #2, lost)
and so on.

This is not a great retransmission schedule. There are several ways out of
this. The most straightforward one, IMO, is to reset the Map-Notify
retransmission timer if a Map-Register retransmission arrives and triggers
a reply.

>
>
> > 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.
>
>
I see now that Sec 5.3 specifies that piggybacked information the Map
Request requires authentication, so I agree there is no issue here. It
might be useful to reiterate this in the 2nd paragraph of 7.1, but I will
remove this part of the DISCUSS.

Thanks for resolving the comments.