Re: [lisp] Reviewing the updated LISP docs

Dino Farinacci <farinacci@gmail.com> Fri, 08 February 2019 00:14 UTC

Return-Path: <farinacci@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 A05FB130ED0; Thu, 7 Feb 2019 16:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SZkfpUDlVA8a; Thu, 7 Feb 2019 16:14:51 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 BBC111274D0; Thu, 7 Feb 2019 16:14:51 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id w7so724692pgp.13; Thu, 07 Feb 2019 16:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kU5WD4vCkJpSLlAP+o6vIpY3wfJWN+bwF/64TNv+L78=; b=eLnC+U+fLo3pciDf9IYRVn46hkrlUUj2dlBygENsyoBOwBndlc2K9/c1G97il1bdUe zYT5pIBooTZ3ex8GxmS+AmCCdsyYZRCNZs9yl6P2/sf1t7AsTXzeeE8PSauaZzFkdM/z jzdBB+66F7iKt5g/D2Tmu6JLBzy5/OOCVJLof43xd5Nu53iKRZFIM+qG5CxLquAe1uCG O83pfAcHd8jlBu/79Md26kx6UYsvuAaEeDRBImqYB2blbyC7P10LUQZTWh4as57hvD3G 8/9WN/Jzg25o4YfkfyXmYMPr/nV4GM1hcUJ+a/8pa1MC5PvsAhn4Gj1jfXfGF3NSmQZB L1UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kU5WD4vCkJpSLlAP+o6vIpY3wfJWN+bwF/64TNv+L78=; b=rGl9C0L/0f1dzeQ/TlbenmaNBGFW1Mktay08RqXy2x40nLxmWEjAIpomOwNAVTBSzP UHS0dZoPaXExIN1LLBxoc6kWLZXIifmXI37z4q7RiPAFFWBQsiqg04ZRgZ8Bynay5OZI 6nTTbWfk38B7HagdIrA5QIN164ANvDzU7sFS/T3v6BeV397J3RciEbZ7KzmkW5dJAelf gPkx41/1K+bpI/If1rubC6g2auL75SDsTbi9dmoS4tZjy67ezHANZ4savDgL85hO8XuY mrRPxMVI1P9gFpThF2JNnVDpmzsIyGnD/yFnv7kY0g16Nn4ChB6IgJaClorTEMRYZehN 9kUw==
X-Gm-Message-State: AHQUAuZZjtxNpMrLy85fSC5yPyWhyY0VBQ9aOerEWRd4or7RMCs2Drtw KVtQENLfH565A30NbMaskbg=
X-Google-Smtp-Source: AHgI3IafElaCWlfzcpoGBmE+vwkM8kZyxCEEGNq1w4l4gc933yY/thMnM7pErJQWEUBd0V7groWAAA==
X-Received: by 2002:a62:6204:: with SMTP id w4mr19138014pfb.5.1549584891064; Thu, 07 Feb 2019 16:14:51 -0800 (PST)
Received: from ?IPv6:2601:646:9600:e494:a990:6197:dc91:5bad? ([2601:646:9600:e494:a990:6197:dc91:5bad]) by smtp.gmail.com with ESMTPSA id v89sm395336pfk.12.2019.02.07.16.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 16:14:50 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CABcZeBNhdiVmK4OdTvsR9nVwuRA4MH=ehSophzwQ+jQCV+3P3Q@mail.gmail.com>
Date: Thu, 07 Feb 2019 16:14:49 -0800
Cc: IESG <iesg@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <41F2EF71-BEBA-4205-893C-C0ED9A1CC462@gmail.com>
References: <CABcZeBNqxYv_42ETH9FmaswBgcwO6fL8+WsJq7ZuyJES520cRg@mail.gmail.com> <CABcZeBNhdiVmK4OdTvsR9nVwuRA4MH=ehSophzwQ+jQCV+3P3Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/dZBoGg7oQzyiyxJtxNovmNB15os>
Subject: Re: [lisp] Reviewing the updated LISP docs
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: Fri, 08 Feb 2019 00:14:54 -0000

Eric, just want to be clear on this one point. See below.

> > S 5.5.
> > >         is being mapped from a multicast destination EID.
> > >   
> > >   5.5.  EID-to-RLOC UDP Map-Reply Message
> > >   
> > >      A Map-Reply returns an EID-Prefix with a prefix length that is less
> > >      than or equal to the EID being requested.  The EID being requested is
> > 
> > How do I behave if I receive an EID-Prefix that is less than any of my
> > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix
> > length, I assume you mean the length fo the mask?
> 
> We had an extended back and forth on this. I still don't find the document
> very clear, and I'm not sure that this text is correct. Specifically,
> consider the following example, where the MS has two mappings:
> 
>    10/8 -> ETR1
>    10.0.1/24 -> ETR2
>    
> The Map-Request is for 10.1/16. In email, we agreed that you cannot return
> only the first mapping because that would implicitly over-claim. This means
> that you either supset one of your mappings or return both (I understood
> Dino to be saying you return both). However, the 10.0.1/24 mapping has
> a longer prefix than the requested one, so that would seem to violate this
> text.

With the above entries in the mapping system, a Map-Request fro 10.1.0.0/16 gets returned the 10.0.0.0/8 entry.

(1) A Map-Request for 10.0.1.1/32 returns only 10.0.1.0/24.
(2) A Map-Request for 10.2.2.2/32 returns both 10.0.0.0/8 and 10.0.1.0/24 (even though 10.2.2.2 is not more specific than 10.0.1.0/24).
(3) A Map-Request for 10.0.0.0/<8 (less than 8) returns an empty RLOC-set.

As I mentioned last night if a Map-Request matches an entry in the mapping system and the mapping system has more specifics for that matched prefix, then all more specifics are returned. The reason is for when 10.0.1.1/32 is looked up in the ITR/RTR map-cache the /24 ETR2 is used.

The mapping system does not know what the ITR has cached so it must return all more specifics. I hope this clears things up.

Dino