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

Benjamin Kaduk <kaduk@mit.edu> Tue, 31 December 2019 02:10 UTC

Return-Path: <kaduk@mit.edu>
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 6886C12008F; Mon, 30 Dec 2019 18:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 q2EkNr4u2gHx; Mon, 30 Dec 2019 18:10:33 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF30812002E; Mon, 30 Dec 2019 18:10:33 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBV2ASU3019786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Dec 2019 21:10:30 -0500
Date: Mon, 30 Dec 2019 18:10:27 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dino Farinacci <farinacci@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, lisp@ietf.org
Message-ID: <20191231021027.GQ35479@kduck.mit.edu>
References: <157774453448.4510.11290223681067982417.idtracker@ietfa.amsl.com> <284E65D4-9064-47AC-BACC-4DD64742B17D@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <284E65D4-9064-47AC-BACC-4DD64742B17D@gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/ffnIFn-UdEKV2PtHHl259W50TJU>
Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-28: (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: Tue, 31 Dec 2019 02:10:35 -0000

On Mon, Dec 30, 2019 at 03:03:35PM -0800, Dino Farinacci wrote:
> > Thank you for all the updates in the -28; we're making great progress!
> 
> Thanks Ben. Here are some brief answers.

Thanks Dino.

> > My ballot on the -26 included:
> > 
> > % The usage of the Instance ID does not seem to be adequately covered; from
> > % what I've been able to pick up so far it seems that both source and
> > % destination participants must agree on the meaning of an Instance ID, and
> > % the source and destination EIDs must be in the same Instance.  This does
> > % not seem like it is compatible with Internet scale, especially if there are
> > % only 24 usable bits of Instance ID.
> 
> The source and destination EIDs are scoped within an instance-ID. So all EIDs within a VPN (that is assigned a unique Instance-ID PER mapping system) are unique.
> 
> Note it is 2^^32 Instance-IDs PER mapping system. Where 2^^24 can be used by any one ITR.
> 
> > The -28 now says that the whole LISP deployment has to agree on the
> > meaning of Instance ID values (thank you!), but I'm still not entirely sure
> > if the source and destination EIDs need to belong to the same Instance.
> > If they do need to be in the same Instance, I think we should note that
> > (but if not, then the current text should be fine as-is).
> > My apologies if this was already covered and I just forgot.
> 
> Agree. We can add that. They must be part of the same instance-ID. Extra-netting where they can be part of different ones is in the draft-ietf-lisp-vpn draft that is not currently on standards track.

Great; that helps clear things up for me.

> > Section 10.1
> > 
> > Some side discussion: in some sense, the echo nonce functionality is the
> > most reliable method for determining reachability, and yet we say that it
> > MAY be overridden by other methods.
> > There's also some potential conflict between the "will set the E-bit and
> > N-bit for every packet it sends while in the echo-nonce-request state" and
> > the later text about echoing the peer's nonce when both ETR and ITR go into
> > the echo-nonce-request state at the same time, since if the E-bit and N-bit
> > are sent on literally every packet sent, then it's not possible to send packets
> > that echo the peer's nonce (which would just set the N-bit but not the E-bit,
> > if I understand correctly).
> > 
> >   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.
> > 
> > Is this only in RLOC-probe Map-Reply messages (and not generic, including
> > mapping-driven, Map-Reply messages)?   Specifically, my understanding was that
> 
> Yes.
> 
> > any Map-Reply could set the E-bit to indicate support for echo noncing, and so
> > there's not much point in us specifically qualifying that the E-bit is set in an
> > *RLOC-probe* Map-Reply (as opposed to just "a Map-Reply"). If this behavior
> > is specific to the RLOC-probe replies, I think that 6833bis needs
> > some clarification in Section 5.4.
> 
> Agree. Because even when a map-server proxy-replies, it knows if the ETR registered with Echo-Nonce capable. So the information can be conveyed from multiple sources.

I'm not sure if you're saying that we should s/RLOC-probe
Map-Reply/Map-Reply/ or make achange to 6833bis.  Sorry for being confused
:(

-Ben