Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

Dino Farinacci <farinacci@gmail.com> Thu, 27 September 2018 21:06 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 6F415130DEA; Thu, 27 Sep 2018 14:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 DUo1A8QDn6Eo; Thu, 27 Sep 2018 14:06:16 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 AC98F12DD85; Thu, 27 Sep 2018 14:06:16 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id i4-v6so2210423pgq.9; Thu, 27 Sep 2018 14:06:16 -0700 (PDT)
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=cMjGyS0B2bUeorBTvmMbB6lVu0xVc/OyxQ8moK1uw4M=; b=ow43sBWxgJkkAQswcsa+RIiFAOUkZdf8VSfhydgW0b9yXmBHYZlPz1uERreWA1w6LR FDHCHMMI26lhdepPBq81JyG3otSfxdsYm5tjwITVT5mmm9mU7bEvR0wGjT9cCmrEEUhv OJCz7j+qeB55QcJJeecRmgoDT7yLytP7pkG1QXcKOg8ClsMyWZ90sp9t69U+Wj9BunuA odKNIpJDU6rMeiKI0ejrAAN51qp6Qotoby0rdOmU9n0dSkxYKJ1yd+2olaJDkbdlcRVH P6y+ALbwT94/X0gtXxAW/OqC+A2b84qkSWz7BosWNgZRGe0g2//5U0wILyQfRT7YLSu2 AZUQ==
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=cMjGyS0B2bUeorBTvmMbB6lVu0xVc/OyxQ8moK1uw4M=; b=StSCcSBCHwV0NESzY35qD9X7CjBFKqSA1eFFmDKjAgzJxDcVXEyYfv2zq4EQWakwmU JoX/EmWnMxFsi90hL5B0KHjMR0hfMYsDghGwgFtUnQ6gk8IXiUSbtJ1q6tk+Xy38S9el qrM+aD+PBiwHCQ7e+pVx1tuhJZbnIx3Vhyjq+/HSVcVbzKKo/7BecN3NIElIfpMEi6k3 QdccXUMuEYrN54XZArXS2uVQOShLAuwAgdELkqPOZv+cKutbEbwaOBOYv4xqTncVC0Lb L1QrTHAV3d/TeIRFj9Ud3A1yCIdYb8ENvQzjPn0GZoO3LJLxAGsdjjfFJW48Axq7EuLa yh6g==
X-Gm-Message-State: ABuFfoh7hOEydEVd02LPzn5dGp2APLHpuMnDgRqYsuomGZdwXcMQqoJk pHogymkkVwcFXqU0+1YsPzk=
X-Google-Smtp-Source: ACcGV61qL8RaijwuPn8dJmGtpg8QuboHZPnmNtTXq1W0JH5i9d1AGnfATg+rcvESBZpky2bzlF/mgw==
X-Received: by 2002:a17:902:3081:: with SMTP id v1-v6mr13064657plb.58.1538082376041; Thu, 27 Sep 2018 14:06:16 -0700 (PDT)
Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id f184-v6sm7677546pfc.88.2018.09.27.14.06.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:06:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com>
Date: Thu, 27 Sep 2018 14:06:13 -0700
Cc: The IESG <iesg@ietf.org>, lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7D10AA5-5518-46BA-AEDE-45CF55CC1968@gmail.com>
References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/fq1kTKt2S3cQXg7B-deVt6akWzY>
Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (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: Thu, 27 Sep 2018 21:06:19 -0000

Fixing the simple issues first. Clipping out the rest of the text.

> Is there anything different between an "EID-to-RLOC Map-Request" and just a
> "Map-Request"?  (Same question for "Map-Reply", too.)

No. But Map-Requests are used for lookups in the mapping system as well as for probing RLOCs for reachability.


> Section 3
> 
> nit: "An address family that pertains to the Data-Plane." is a sentence
> fragment.

Fixed.

> 
>   Ingress Tunnel Router (ITR):   An ITR is a router that resides in a
>      [...]
>      mapping lookup in the destination address field.  Note that this
>      destination RLOC MAY be an intermediate, proxy device that has
>      better knowledge of the EID-to-RLOC mapping closer to the
> 
> This doesn't seem like a 2119 MAY is necessary, but rather a statement of
> fact that may not be known to the encapsulating ITR.

Agree. Fixed.

> 
>      Specifically, when a service provider prepends a LISP header for
>      Traffic Engineering purposes, the router that does this is also
>      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
>      on the outer destination address (the originating ITR's supplied
>      RLOC) or the inner destination address (the originating host's
>      supplied EID).
> 
> I'm confused here, perhaps in multiple ways.  Are there now *two* LISP
> headers on the packet?  Is the "outer RLOC the ISP ITR uses" the source
> RLOC or the destination RLOC?

No, just one. When referring to “inner” and “outer”, we mean IP headers.

> 
>   Negative Mapping Entry:   A negative mapping entry, also known as a
>      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
>      is advertised or stored with no RLOCs.  That is, the Locator-Set
>      for the EID-to-RLOC entry is empty or has an encoded Locator count
>      of 0.
> 
> Is "empty" a distinct representation from "locator count of zero”?

Yes. Added text to make that more clear.

> Section 4
> 
>   An additional LISP header MAY be prepended to packets by a TE-ITR
>   when re-routing of the path for a packet is desired.  A potential
>   use-case for this would be an ISP router that needs to perform
>   Traffic Engineering for packets flowing through its network.  In such
>   a situation, termed "Recursive Tunneling", an ISP transit acts as an
>   additional ITR, and the RLOC it uses for the new prepended header
>   would be either a TE-ETR within the ISP (along an intra-ISP traffic
>   engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
>   engineered path, where an agreement to build such a path exists).
> 
> "the RLOC it uses for the new prepnded header", again, this is as the
> destination RLOC (vs. source RLOC)?

Fixed.

> Section 4.1
> 
>   o  Map-Replies are sent on the underlying routing system topology
>      using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol.
> 
> Just to check my understanding: is the "underlying routing system topology"
> the same as the "underlay”?

Yes.

> Is step (3) just describing more of what step (2) says is "not described in
> this example”?

I lost your reference. Is it to the previous bulleted set or the one starting with “Client host1 …”?

> 
> When doing ETR/PETR decapsulation:
> 
>   o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
>      the case of IPv6) SHOULD be copied from the outer-header 'Time to
>      Live' field, when the Time to Live value of the outer header is
>      less than the Time to Live value of the inner header.  Failing to
>      perform this check can cause the Time to Live of the inner header
>      to increment across encapsulation/decapsulation cycles.  This
>      check is also performed when doing initial encapsulation, when a
>      packet comes to an ITR or PITR destined for a LISP site.
> 
> Er, what is "this check" that is also performed for initial encapsulation?
> How are there multiple TTL values to compare?

“This check” is outer-header-TTL is < the inner-header-TTL.

>   o  The inner-header 'Differentiated Services Code Point' (DSCP) field
>      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
>      copied from the outer-header DSCP field ('Traffic Class' field, in
>      the case of IPv6) to the inner-header.
> 
> nit: the first "inner-header" seems like an editing remnant?

Fixed. This text has changed so many times, it’s not a surprise it became confusing.

> 
> Section 7.1
> 
> How is this stateless if it invovles knowledge about the routers between
> the ITR and all possible ETRs (i.e., a set that could change over time)?

The ITR does not keep state about underlay routers between it and the ETR.

> Section 8
> 
> This 32-bit vs 24-bit thing is pretty hokey for a standards-track
> specification (yes, I know that LISP-DDT is not standards track at the
> moment).

It is actually useful to allow more instance-IDs but not waste extra bits in the encapsulation header.

> Section 9
> 
>   Alternatively, RLOC information MAY be gleaned from received tunneled
> 
> What is this an alternative to?  The list of four options above?

Doing a mapping system lookup to get an RLOC-set.

>   packets or EID-to-RLOC Map-Request messages.  A "gleaned" Map-Cache
>   entry, one learned from the source RLOC of a received encapsulated
>   packet, is only stored and used for a few seconds, pending
>   verification.  Verification is performed by sending a Map-Request to
>   the source EID (the inner-header IP source address) of the received
>   encapsulated packet.
> 
> The source EID is some random end system, right?  So this relys on some
> magic in the ETR to detect that there's a Map-Request and reply directly
> instead of passing it on to the EID that won't know what to do with it?

Not following your description.

> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and
> might benefit from an explicit section reference to the other document.

Done.

> 
> Section 10
> 
> What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, but it
> is not marked as well-known at
> https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is
> probably in order.

It is defined in the xTR definition.

> Section 10.1
> 
>   Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
>   be implementing both ITR and ETR functionality for the echo nonce
>   mechanism to operate.
> 
> Perhaps they could be given actual names so as to disambiguate which steps
> are performed with ITR vs. ETR role?

They are. An ITR is an encapsulator. An ETR is a decapsulator. This is defined in the definition section. When the functions are co-located, they refer to an xTR, also in the definition section.
> 
>   The echo-nonce algorithm is bilateral.  That is, if one side sets the
>   E-bit and the other side is not enabled for echo-noncing, then the
>   echoing of the nonce does not occur and the requesting side may
>   erroneously consider the Locator unreachable.  An ITR SHOULD only set
>   the E-bit in an encapsulated data packet when it knows the ETR is
>   enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
>   probe Map-Reply message.
> 
> Why is this even optional?  If it was mandatory to use, then there would
> not be a question.  But at least clarify that the "this" that is conveyed
> is whether the peer supports the echo-nonce algorithm.  (Also, subject to
> downgrade.)

Because it has cost implications in a hardware implementation.

> Section 18
> 
>   o  Data-Plane gleaning for creating map-cache entries has been made
>      optional.  If any ITR implementations depend or assume the remote
>      ETR is gleaning should not do so.
> 
> nit: this is ungrammatical; "they should not" or "Any ITR implementations
> that depend on or assume that" would fix it.

Fixed. Thanks.

> Section 19.1
> 
> Presumably IANA also updated the reference column to point to this
> document?

Yes, from my perspective.

Thanks,
Dino