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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
