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

Dino Farinacci <> Thu, 27 September 2018 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867DA131050; Thu, 27 Sep 2018 14:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dfC0F6CF1ehQ; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8C3D130E09; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
Received: by with SMTP id a23-v6so2729298pfi.12; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WRqmSUihWFIvqJYqvVgmzdgjIP1CqpRQka098+Qufic=; b=fSJ9YtBvZ8taCLBnaShpvThfln6t8Mn1LrKTDeFoc0lbYWd4AwI9gam9kgYoENZfyK Jin8mMncddETg/FPpAIv5vq6SrEAugCAEdDxdUfCjzhjycnAzIzvbeAJaBwHYKq42eGs M0t6YJk8eNOWcfxJ1JpSw/9lB/0Hnes747VhOcYvRhkFmuC+Jrz7VRyngmWWARdi63PQ dGVMulGAFKIStH+SpuwUneUl2J/ZBtDUGwBcQBplHlYwEjyA4E6SsfW8BmO2IGebvARu d9GHsBLSsQnH+9347pMhyRWt4/KMsaa45GSZ1EtXo6IdkSZZCIRZ3cG5TONfG+gvO61q KoLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WRqmSUihWFIvqJYqvVgmzdgjIP1CqpRQka098+Qufic=; b=PnXuLAIytQVQQFjh6uOadIGT+ejQplQ81B2SAGL4RI2W+N/Wk7IU11XSzONz8+nUuM vNxv1UKgUWFvNPQ3Opml/vfdyXc51yFlwJn6qITsJ8bp7SJmozcWdcnjkCy+NrPA0hOH JW5+DuQkz9zRwQ+Cd1kMZoziIuHb1Wog3kA7jAIQzp6XmVQ64Uu46l4QsjuAT2AKtHAj KCTbNhZ3cDstuBrcxpvcaGgv3uLUHG4MnOHkVaaBTn6hm/+3PudnlacJhk7tVqSVOrT2 sALMbELohUSed+aJMJJ5ODHGLjSAjWwvHxcswNCyBetbcS76eJIJHIG8sVqBHPIgXh+4 N12g==
X-Gm-Message-State: ABuFfoiP+Fu/UWu5PhD1Fq/xvs6AKLSNyQgae5nzrwyhMUCwI6fIstlq WDCkMXD/aa4P4Z7flPw5qJI=
X-Google-Smtp-Source: ACcGV61p5KM5VTyuTMWQUJpvi5aG52ch/Kq/9WuEN6ngb3ZmfKj2S+o/yJQ0B8DqJ1+kHwooukJV2A==
X-Received: by 2002:a65:5188:: with SMTP id h8-v6mr11896235pgq.288.1538082763295; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x24-v6sm5327428pfh.67.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:12:42 -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 <>
In-Reply-To: <>
Date: Thu, 27 Sep 2018 14:12:41 -0700
Cc: The IESG <>,, Luigi Iannone <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2018 21:12:49 -0000

Doing the same as I did with Ben’s email. Fixing the simple stuff first. The simple changes (editorial) will be submitted in -21.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> S 5.3.
>>        header.
>>     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
> This should probably be a MUST because there are other protocols that
> assume that TTLs get decremented.

Agree, changed. It was SHOULD a long time ago because some hardware couldn’t support this. Technology has moved on.

> S 7.1.
>>     destination site.  The two fragments are reassembled at the
>>     destination host into the single IP datagram that was originated by
>>     the source host.  Note that reassembly can happen at the ETR if the
>>     encapsulated packet was fragmented at or after the ITR.
>>     This behavior MAY be performed by the ITR only when the source host
> Nit: I think you want to say MUST be, assuming you mean that you can
> perform it only if….

Agree. Same issue as my last comment.

> S 7.2.
>>     2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
>>         with the DF bit set to 1, exceeds what the core network can
>>         deliver, one of the intermediate routers on the path will send an
>>         ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/
>>         Fragmentation-Needed to the ITR, respectively.  The ITR will
>>         parse the ICMP message to determine which Locator is affected by
> What if you are in an environment where ICMP is blocked?

You lose. There are mechanisms (un-documented) for the control-plane to detect this on its own. 

> S 9.
>>        outside of the subset list if it determines that the subset list
>>        is unreachable (unless RLOCs are set to a Priority of 255).  Some
>>        sharing of control exists: the server-side determines the
>>        destination RLOC list and load distribution while the client-side
>>        has the option of using alternatives to this list if RLOCs in the
>>        list are unreachable.
> How would you obtain alternative RLOCs?

You can use a PETR that is configurable. But we didn’t want to document interworking mechanisms here.

> S 10.
>>         also acting as an ITR and has traffic to return to the original
>>         ITR site, it can use this status information to help select an
>>         RLOC.
>>     2.  When an ETR receives an encapsulated packet from an ITR, the
>>         source RLOC from the outer header of the packet is likely up.
> What does "is likely up" mean?

Changed to “reachable”. Thanks.