Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

Sharon <> Fri, 05 February 2021 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 365203A0D63; Fri, 5 Feb 2021 04:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z_p_Uh72AVkK; Fri, 5 Feb 2021 04:31:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BECCE3A0D62; Fri, 5 Feb 2021 04:31:08 -0800 (PST)
Received: by with SMTP id u14so5763239wmq.4; Fri, 05 Feb 2021 04:31:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=1OFSI938VI2fLtUY6GP0Fj5WD6Sa5AvkcgmDnlZsDng=; b=lZIy5PSj+FB1tV2yTJwFLupikat02o9pfJ/urGQRlbnFk/ETGgYDHri2Vv9bxnjD8G X9U2pgcg6i+Xved1te4TIrmoeyRoX3KfxQ9DV7wHbUyNeNMDJqrJnkAJY7kBp2qC0tNx i7tsb7I7eKHmGdETzmNpwhsqqg/pXDPEOAYbkFEU0keOU05fHxTifau90Efi/LP3U0c4 5cPWRHMELBqNYepg2sU8iC3xQ1Gecmsl4ViOZCKxvwZMPNraWSazgjWdM7qe+piQSS3W HbOzvXmk/Q12P8JX5AC6Kxh6hqjTD8I8g3GPeYtKA5RFAZSkpkqowuLRq5WzWxA/3ts2 JJrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=1OFSI938VI2fLtUY6GP0Fj5WD6Sa5AvkcgmDnlZsDng=; b=Dv1DnaMQCdHL6mff9IDp/hjqQUG4nODxUyWNcG9RQPR65u0qbLURFtkv7AGaNegCQy v/Lxuslh38AdEgqV6ty4XQbgtFCd/oWfNoGH+AG7BvnXmMwK/RyuSkq9/3m/SYREeEwA hbGU+eig3btpLr7mB+hXJDhtjr0wjg9iirlqgJqHtsIg/x8FAz98L/2ASzqQZVs1BAZv T6LfXhyILhWux05HGSgZFOkfualTx6g1CDEDfre1M7WxAIrKKuOx1LLXkAQhOtWuKw2x h0qQCVRhWm3C7l0hhzBwHbqNLlFFWk5b0ATPYIJxw64kmKr3XzD23J37/sDCaygMIxh1 oGlQ==
X-Gm-Message-State: AOAM532Lr9hvSgtJVeCp+Pzw4+4MHmxSvgHoqMzRDkgg8sDqOanW4c+3 vRfmBJ1txRKGEaKKcYfOmnNVDFKDuw==
X-Google-Smtp-Source: ABdhPJzVTddQV/IbFvKeqRPDCezLipPAqs1BfwJu/Rxm6t/PmgnltbiV5lqX+iiYGmKA6tJmH2PDKQ==
X-Received: by 2002:a1c:3587:: with SMTP id c129mr3421251wma.76.1612528266823; Fri, 05 Feb 2021 04:31:06 -0800 (PST)
Received: from ?IPv6:2a02:14c:338:8200:9082:925e:6ebd:1c64? ([2a02:14c:338:8200:9082:925e:6ebd:1c64]) by with ESMTPSA id b7sm13365869wrs.50.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Feb 2021 04:31:06 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-E5E7E8AC-8AF0-4CE2-B27B-2D6D30CDE55C
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Sharon <>
In-Reply-To: <>
Date: Fri, 5 Feb 2021 14:31:05 +0200
Cc: Luigi Iannone <>, " list" <>,
Message-Id: <>
References: <>
To: =?utf-8?Q?Albert_L=C3=B3pez?= <>
X-Mailer: iPhone Mail (18C66)
Archived-At: <>
Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
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: Fri, 05 Feb 2021 12:31:11 -0000

Thank you Albert. These are very good comments. See inline:

Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Feb 5, 2021, at 12:26, Albert López <> wrote:
> Hi all,
> After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.
> Some comments and questions that I have when reading the document are the following ones:
> In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them. 

I will add more text on the nexagon header. In principle these are:

Type: we specify two types only here
kv, kv, kv... basic and default use
v, k, k, k .. for large area with same value
proprietary extensions add more types

Gzip: is a flag if the k,v where zipped.
In close by tiles the compression is high


Pair count: how many kv are we sending,
in kv kv or v kkk form 

> "EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers.

We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers.

> "EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients.
> Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?

Yes clients can repeat AAA procedure and are supposed to renew AAA.
> I think that more references need to be added to the document like the DIAMETER RFC.

Will add
> I hope these comments could help to improve the document.

They do. I will clarify the language and send update as soon as all inputs are in.
Thank you for devoting the time and attention. 

> Best regards
> Albert López
>> On 3/2/21 16:25, Luigi Iannone wrote:
>> Hi All,
>> The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
>> No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.
>> This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.
>> Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
>> If you have objections, please state your reasons why, and explain what it would take to address your concerns.
>> NOTE: silence IS NOT consensus!
>> Thanks
>> Luigi & Joel
>> _______________________________________________
>> lisp mailing list
> _______________________________________________
> lisp mailing list