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

Dino Farinacci <farinacci@gmail.com> Thu, 27 September 2018 21:12 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 867DA131050; Thu, 27 Sep 2018 14:12:45 -0700 (PDT)
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 dfC0F6CF1ehQ; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 C8C3D130E09; Thu, 27 Sep 2018 14:12:43 -0700 (PDT)
Received: by mail-pf1-x443.google.com 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; d=gmail.com; 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; 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=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 [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id x24-v6sm5327428pfh.67.2018.09.27.14.12.42 (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 <farinacci@gmail.com>
In-Reply-To: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com>
Date: Thu, 27 Sep 2018 14:12:41 -0700
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF66FEDC-EA23-4F4B-BD18-186C6627CD46@gmail.com>
References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/njrsoM3pGAxL6kmwtKXzpjtfEMk>
Subject: Re: [lisp] Eric Rescorla'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: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.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.

Thanks,
Dino