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

Albert López <alopez@ac.upc.edu> Tue, 09 February 2021 06:50 UTC

Return-Path: <alopez@ac.upc.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 982B63A119B; Mon, 8 Feb 2021 22:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o0iztpNI107; Mon, 8 Feb 2021 22:50:07 -0800 (PST)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 72EBD3A1199; Mon, 8 Feb 2021 22:50:06 -0800 (PST)
Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 1196o3A5011878; Tue, 9 Feb 2021 07:50:03 +0100
Received: from [10.8.0.14] (gw-5-vpn.ac.upc.es [147.83.30.82]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 1EEF4276; Tue, 9 Feb 2021 07:49:58 +0100 (CET)
To: Sharon Barkai <sharon.barkai@getnexar.com>
Cc: Sharon <sbarkai@gmail.com>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
References: <122a75a5-1a95-dcdb-8ab3-e957f1d13975@ac.upc.edu> <5721B1C9-D7D4-4C4E-832F-2280C05693A6@getnexar.com>
From: =?UTF-8?Q?Albert_L=c3=b3pez?= <alopez@ac.upc.edu>
Message-ID: <202e1b6b-b8eb-d841-c687-309f32fc5343@ac.upc.edu>
Date: Tue, 9 Feb 2021 07:49:53 +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: <5721B1C9-D7D4-4C4E-832F-2280C05693A6@getnexar.com>
Content-Type: multipart/alternative; boundary="------------68DC38941C7A83DF9C792112"
Content-Language: ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/3iXWX59_y7tZO5DmXv9cm19I3mg>
Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
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, 09 Feb 2021 06:50:12 -0000

Thanks for your explanations. Now it is more clear to me.

Best regards

Albert

On 8/2/21 13:44, Sharon Barkai wrote:
> Thanks Albert for pointing out these possible confusion points. 
> Answering inline ..
> But first would like to clarify the exact subset of LISP we leverage 
> for the Nexagon mobility network.
>
> 1. The MobilityClients and H3Services use the LISP XTR network over 
> tunnels to mitigate multi-access-provider multi-edge-provider 
> challenges such as NAT or multi-tenancy in clusters or edge device OS.
>
> The simplest choice is to use data-path LISP tunnels:
> -ClientXTR
> -ServerXTR
> But these do not participate in the mapping control plane.
>
>               Mapping System
>                     /                \
> sXTR=RTR1 :::::::::: RTR2=cXTR
>
> 2. Nexagon is a mobility geospatial pub-sub network, road-segments are 
> abstracted to EIDH3Services which are administratively provisioned 
> based on load/availability to RTRs and the mapping system accordingly. 
> Their global RLOC is their RTR (RTRs in multi homing).
>
> Clients subscribe to these geospatial feed using MLD and SignalFree 
> Mcast, which means their RTRs subscribe for them to (s,g) feeds. Their 
> RTRs are assigned by AAA. The AAA provisioning is done both at the 
> client and the RTR. The RTR does mcast replication to to all the 
> clients it is homing and that have MLD subscribed through them to 
> (s,g) or (location, theme) mcast feeds.
>
> After they subscribe, some of the clients may also publish geospatial 
> detections, depending on their EID credentials (rw/ro). When they do 
> the RTR RLOC of the H3Service (this time as dest EID) is gleaned into 
> the map-cache of the client RTR - which is subscribed to that 
> H3EIDService as a feed (source).
>
> Clients may NOT talk to each-other or learn each other's EIDs. The 
> Nexagon network overlay is strictly brokered.
>
> If the above computes, welcome any suggestion that prevents reading 
> the draft differently.
>
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
>
>> On Feb 8, 2021, at 12:05, Albert López <alopez@ac.upc.edu> wrote:
>>
>> 
>> Hi Sharon,
>>
>> Thanks for your clarifications. I have some questions inline.
>>
>> On 5/2/21 13:31, Sharon wrote:
>>> Thank you Albert. These are very good comments. See inline:
>>>
>>> --szb
>>> Cell: +972.53.2470068
>>> WhatsApp: +1.650.492.0794
>>>
>>>> On Feb 5, 2021, at 12:26, Albert López <alopez@ac.upc.edu> 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
>>>
>>> Reserved:
>>>
>>> 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.
>> So, if I understood correctly, the serverXTR is registering its EID 
>> (H3.r9) to the mapping system using the RLOC of its associated RTR.
>
> Right
>
>> This process is done through Encap Map-Register of the serverXTR 
>> through the RTR or It is the serverXTR who is sending directly a 
>> Map-Register to the mapping system?
>
> Provisioned
>
>>   How does the RTR knows the the real RLOC of the serverXTR? is 
>> statically configured? or is learned through an Encap Map-Register?
>
> Through gleaning the feed from the server it signal-free subscribed to
>
>>>
>>> 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.
>>
>> If no registration process exists of the MobilityClients' EID, how 
>> does the edgeRTR knows the MobilityClient's RLOC that should be used 
>> to send the multicast packets? (Specially if a change of RLOC is 
>> produced)
>>
>
> The clientXTR and its RTR are co-providioned.
> The client must MLD report to a channel to ensure
> - its RTR signal-free registers
> - its RTR replicates to it
>>
>> Best regards
>>
>> Albert
>>
>>>>
>>>> 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@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp