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

Albert López <> Fri, 05 February 2021 10:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D9F63A0B93; Fri, 5 Feb 2021 02:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j45h20i8ZERe; Fri, 5 Feb 2021 02:26:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6090D3A0B91; Fri, 5 Feb 2021 02:26:42 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id 115AQaOR006278; Fri, 5 Feb 2021 11:26:36 +0100
Received: from [] ( []) by (Postfix) with ESMTPSA id D08C2132; Fri, 5 Feb 2021 11:26:30 +0100 (CET)
To: Luigi Iannone <>, " list" <>
References: <>
From: =?UTF-8?Q?Albert_L=c3=b3pez?= <>
Message-ID: <>
Date: Fri, 5 Feb 2021 11:26:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FB45B4863263C9278CE01180"
Content-Language: en-AU
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 10:26:48 -0000

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.

"/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?

"/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?

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?

I think that more references need to be added to the document like the 

I hope these comments could help to improve the document.

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