[lisp] AD Review of draft-ietf-lisp-nexagon-19

[Alvaro Retana <[e-mail]>]

Dear authors/shepherd/chairs:

First of all, this is an exciting application! Thank you for the work
you've put into it so far!


However, I am concerned about this document as a product of the WG and
potential IETF RFC. To summarize, it goes beyond describing how LISP
can be used to *trying* to specify a complete system, but it falls
short in attempting to do too many things at once. As a result, the
descriptions are confusing, the specifications are incomplete, the
text is inconsistent, etc.

I put detailed comments inline (see below), but I first want to list
high-level issues:

(1) The operation of LISP in the Nexagon system is straightforward; the most
    "complex" part is using the RTRs, but even that is as specified in
    rfc6830bis. However, the document combines the use of LISP with H3-related
    concepts and even application-layer operations. The result is a confusing
    description where the reader has to make a lot of assumptions because the
    terminology is not adequately referenced or used inconsistently. There is
    no Normative reference to the H3 work, and new terms and assumptions are
    constantly introduced. The straightforward LISP-related description is
    unnecessarily made complex by trying to explain the domain-specific
    operation at the same time.

    It caught my attention that only rfc6830bis is used as a reference. It is
    clear that only the LISP data plane (and not the control plane) is used
    between the MobilityClients and the EdgeRTRs, but it looks like the control
    plane is used elsewhere. The point of which parts of LISP are used has to
    be explicit.


(2) The document attempts to document/specify the operation of the whole system
    (beyond the use of LISP). As a result, the document includes assumptions
    and incomplete technology specifications outside the WG's control: H3-
    related deployment assumptions, use of DNS/AAA (with unspecified
    extensions), sharing of reputation information between components, etc.
    Also, LISP-related assumptions are made without proper specification,
    including the encryption of the data plane, the use of MLDv2 in rfc8378,
    etc.

    As mentioned in the detailed comments below, I find all these topics
    underspecified.


(3) Was this work discussed in the ipwave (IP Wireless Access in Vehicular
    Environments) WG? They are chartered for "use-cases where IP is well-
    suited...to establish direct and secure connectivity between a vehicle and
    other vehicles or stationary systems."  The fit may not be exact but
    related. I saw the discussion on the list [1] and agree that the goals are
    different; nonetheless, it would have been good to share.

    ipwave's Problem Statement and Use Cases document [2] may be a good
    reference for some use cases and other references -- leaving this document
    to highlight the differences. Note that LISP is mentioned as a possibility,
    and the H3-LISP solution may generally fit the "Vehicular Network
    Architecture for V2I and V2V" from Figure 1.

    [1] https://mailarchive.ietf.org/arch/msg/its/WXt2d-FefiZ_iOcBsLgATKLDvVw
    [2] https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking


(4) [For the Chairs.] How does this work fit into the WG's charter? Even if the
    WG is not chartered to produce use-case-type documents, we may be able to
    convince the IESG that this is a draft worth publishing as an IETF RFC (if
    the topic comes up). However, as mentioned before, the document goes
    significantly beyond a LISP use case.


(5) [For the Shepherd/Chairs.]  There are 8 authors listed on the front page.
    The recommended number is 5 (rfc7322). Please work with the authors to
    reduce this number - others can be mentioned as Contributors or in the
    acknowledgment section. Otherwise, please provide a strong justification.



If this document progresses as the product of the WG, its scope will
need to be significantly narrower. So, I'm inclined to return the
document to the WG.

I suspect we might need to talk live about my comments and
expectations. Feel free to find some time in my calendar:
https://doodle.com/mm/alvaroretana/book-a-time

Thanks!

Alvaro.





[Line numbers from idnits.]

1	LISP Working Group                                             S. Barkai
2	Internet-Draft                                         B. Fernandez-Ruiz
3	Intended status: Informational                                  R. Tamir
4	Expires: January 1, 2022                                      Nexar Inc.
5	                                                      A. Rodriguez-Natal
6	                                                                F. Maino
7	                                                           Cisco Systems
8	                                                    A. Cabellos-Aparicio
9	                                                   J. Paillisse Vilanova
10	                                       Technical University of Catalonia
11	                                                            D. Farinacci
12	                                                             lispers.net

[major] The recommended number of authors in the front page is 5.
Please work with the Shepherd/Chairs to reduce the current list.



...
15	        Network-Hexagons: H3-LISP GeoState & Mobility Network
16	                    draft-ietf-lisp-nexagon-19

[minor] Some places use "H3LISP" (instead of "H3-LISP").  Please be consistent.



18	Abstract

20	   This document specifies the use of H3 and LISP for Geolocation
21	   Services. Geolocation Services utilize geospatial data for:
22	   Fresh HDMaps, Intelligent Driving, Cruise and Parking assists.
23	   Geospatial utilization is delivered using in-network compute for
24	   brokered verification, curation, and localization of data, using:

26	   - EID addressable geospatial-tiles abstraction of road-segments.
27	   - EID Interface for detections and uploads to the tile-contexts.
28	   - EID Routing-Sharing hazards, blockages, parking, road-inventory.
29	   - EID themed multicast channels per tile to subscribed clients.

[minor] Please expand terms on first use: H3, LISP, HDMaps, ...


[minor] s/specifies/describes
This is intended to be an Informational document.


[major] H3 is mentioned here and concepts are used throughout the
document.  However, there is no Normative reference offered for the
reader to understand the background.

https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/


[major] "...LISP for Geolocation Services"

The information carried between the clients/servers is independent of
LISP.  And how the EIDs are assigned to the clients are also not in
scope of LISP.  IOW, the system uses geolocation, but LISP itself
doesn't.  I'm making this comment because the use/transmission of
geolocation is going to require significant justification and privacy
considerations.  See rfc6973.


[major] The Abstract should provide a glimpse into what this document is about.

None of the services listed are even mentioned later in the document.
The use of "in-network compute for brokered verification..." is also
not covered anywhere.


[minor] Expand EID on first use.


[major] EID is an Endpoint ID.  I can imagine something that is "EID
addressable", but I'm having a very hard time associating the other
descriptions.  The list sounds like great marketing... <sigh>



...
76	1.  Introduction

[] This section starts with a summary of LISP, but quickly goes into
an application-specific description that may not be needed...and may
raise more questions than it answers.  Some of the text I would even
label as "great for marketing"... :-(



78	  The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis]
79	  splits IP addresses in two different namespaces, Endpoint Identifiers
80	  (EIDs) and Routing Locators (RLOCs). LISP uses map-and-encap approach
81	  (1) a Mapping System (distributed database) that stores and resolves
82	  EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) encapsulating
83	   and decapsulating data packets based on content of those mappings.

[minor] s/uses map-and-encap approach (1)/uses a map-and-encap
approach that relies on (1)



85	  H3 (https://h3geo.org)is a geospatial indexing system using hexagonal
86	  grid that can be subdivided into finer and finer hexagonal grids,
87	  combining the benefits of a hexagonal grid with hierarchy.
88	  H3 supports sixteen resolutions. Each finer resolution has cells with
89	  1/7 the area of the coarser resolution. Hexagons cannot be perfectly
90	  subdivided into seven hexagons, so the finer cells are approximately
91	  contained within a parent cell. Each cell is identified by 64bit HID.

[major] Pointing to the H3 website is not enough.  A stable reference
to where the technology is defined is needed.  References should be in
the References section.


[nit] s/(https://h3geo.org)is/(https://h3geo.org) is


[nit] s/by 64bit/by a 64-bit

Please be consistent on how 64-bit is written.  Besides 64bit and
64-bit, the document also uses "64 bit".


[minor] Expand HID.



93	  The Berkeley Deep Drive (BDD) (https://bdd-data.berkeley.edu) Industry
94	  Consortium investigates computer vision technologies for automotive
95	  applications and for taxonomy of published automotive classification.

[major] The next paragraph mentions that "these standards are
combined".  Does that include BDD standards?  If so, then we'll need a
stable reference to where that is specified.


[major] There's a reference later to a "BDD state"...which I guess is
related to the registries defined in the IANA section.  Am I guessing
correctly?  A quick scan of the BDD site didn't give me an indication
of how they would use the information in the registries.   ??



97	  These standards are combined to create an in-network state reflecting
98	  condition of each hexagonal tile (~1sqm) in every road. The mobility
99	  H3-LISP network maps & encapsulates traffic between client endpoint
100	  identifiers (EID) and addressable geospatial contexts (H3-HID=>EID).

[nit] s/condition/the condition


[nit] s/mobility H3-LISP network/H3-LISP mobility network


[minor] Figure 2 uses "H3-LISP Mobility Network" to identify the
network between the EdgeRTRs.  The description above seems to cover
much more, from the MobilityClients to the H3Services.   Please use
terminology consistently.


[?] I'm not sure what "H3-HID=>EID" means.



102	  The H3-LISP mobility network bridges timing and location gaps between
103	  production and consumption of information by clients of mobility data:
104	   o information producers: vision, sensory, LIADR, AI applications
105	   o information consumers: driving-apps, map-apps, command & control

[] "bridges timing and location gaps"

Wow!  Great marketing!

Please focus on the technical description.  Note that the "H3-LISP
mobility network" transports data -- this reference seems to be
talking about the overall system.  Again, please define terms and use
them consistently.  This is one of the cases where the LISP-specific
use (transport data) and the domain-specific applicaiton (H3) are
combined into an inconsistent application.



107	  This is achieved by putting the physical world on a shared addressable
108	  geospatial context-grid of road-segments represented at the edge.
109	  Geospatial state sharing is done using this brokered-network of tile
110	  representation, an indirection which solves key issues in v2v
111	  information sharing. For example multiple vision perspectives, geo
112	  privacy, cyber security. These challenges arise when clients are
113	  asked to communicate directly when they do not really need to.
114	  A communication pattern which causes complexity and exposures.

[-] "putting the physical world"

I'm sure this can be made more specific.  Perhaps by pointing at the
H3 specifications.


[minor] Expand v2v on first use.  In most literature I see this as "V2V".


[major] "solves key issues...geo privacy, cyber security."

This is a bold claim and wide claim -- I hope the Security
Considerations back it up.  Perhaps, instead of making blanket claims,
focus on the advantages of this solution -- not with respect to others
(because you'll need to back that up too).



116	  In non brokered v2v models, for a situation observable by some end
117	  points, it is unclear if the need-to-know end-points will receive:
118	  i. consistent, ii. conflicting, iii. multiple, or iv. no indications.
119	  As an example, when a vehicle experiences a sudden highway slow-down,
120	  sees brake lights or senses an accelerometer slowdown, there is no
121	  clear way for it to share this data with vehicles 20-30sec away.
122	  Or, when a vehicle crosses an intersection, observing opposite-lane
123	  obstruction such as: construction, double-park, commercial loading,
124	  garbage truck, or stopped school-bus.. there is no clear way for it
125	  to alert approachers from another direction as it drives away.

[nit] s/or stopped school-bus../or a stopped school-bus,


[major] "unclear if the need-to-know end-points will receive"

I didn't see any text about how this system, or LISP, can guarantee
that either.  Specifically, beyond general mapping, there's no
indication in LISP of the characteristics (need-to-know, or not) of
the receivers.



127	  Geospatial context indirection helps communicate advanced vision and
128	  radar annotations. As these are evolving technologies, relaying road
129	  enumerations using peer-to-peer poses interoperability challenges.

[-] Again, focus on this solution, not others.  "communicate advanced
vision and radar annotations"



131	  These peer-to-peer limitations are inherent yet unnecessary, in most
132	  situations vehicles are not really proper peers. They happen to be in
133	  the same place at the same time. H3-LISP mobility network solves the
134	  limitations of direct vehicle-to-vehicle communication by brokering
135	  exchanges using addressable geospatial context. Bridging timing,
136	  security, privacy, and interoperability gaps between endpoints.
137	  Brokering is achieved by clients communicating via context,
138	  addressable tiles which aggregated and relay data using H3 EIDs.

[-] "peer-to-peer limitations"

Again, focus on this solution, not others.


[-] "Bridging timing, security, privacy, and interoperability gaps
between endpoints."   ...


[major] From a LISP point-of-view, are "H3 EIDs" different than EIDs?
This was used above: "H3-HID=>EID" -- what is the relationship?  The
use of the terminology is not consistent.



...
146	  To summarize the H3-LISP mobility solution principles are:

148	  (1) Problem Partition: 64bit H3.r15 ID road-tiles for detections

[major] "H3.r15 ID" -- what is this?  We need a Normative reference.


[minor] For "detections" of what?



149	  (2) Enumerated State: 64bit values of tile condition representation

[major] "tile condition" is not mentioned anywhere else.  What is it?
If it is a "solution principle" it must be important.



150	  (3) Grouping: EID per H3.r9 geo-context for its H3.r15 road-tiles

[major] "H3.r9 geo-context for its H3.r15 road-tiles"

The H3-related terminology needs to be defined/explained somewhere.  A
Normative reference would be ideal.



151	  (4) Group Channels: H3.r9 EIDs mcast address for geo-state updates

[minor] Please use "multicast", or expand the abbreviation on first use.


[minor] I'm not sure about this phrase: "H3.r9 EIDs mcast address".
It sounds as if the EIDs send multicast, but the EID is just an ID and
then there's the "address" part.   Please reword.



152	  (5) Scale: EID addressable contexts distributed on edge servers
153	  (6) Overlay: tunneled-network routes the mobility-network traffic

[nit] "mobility-network" is used here, but in other parts "Mobility
Network" is used instead, both capitalized and not.  Please be
consistent.



154	  (7) Signal-free: overlay is used to map-register for mcast channels

[major] "Signal-free"

If there is a registration, it doesn't sound like "signal free".
Also, are you referring to a Map-Register message or something else?
It seems a little strange that "map-register" is used as a verb.



155	  (8) Layering: overlay tunnels used between clients and geo-contexts

[nit] "Overlay" and "Layering" sound redundant.


[minor] "between clients and geo-contexts"

Terminology.  "geo-contexts" is used above as "H3.r9 geo-context".
Are these the "edge servers" mentioned above?  There are multiple ways
to apparently refer to the same things. :-(



156	  (9) Access: client/server XTRs tunnel traffic to-from the LISP RTRs

[minor] Do these two last bullets (8 and 9) talk about the same
tunnels?  Are the clients the xTRs?  There seems to be some
terminology overlap/overloading of terminology.



157	  (10) Control: RTRs register-resolve H3 EIDs and mcast subscriptions

[minor] "register-resolve" is used as a verb, but I'm guessing that
you're implying the use of Map-Register/MapRequest messages.



159	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
160	  |                        H3 Hexagon ID Key                      |
161	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
162	  |                      H3 Hexagon State-Value                   |
163	  |---------------------------------------------------------------|

165	  Figure 1: 64 bit H3 ID, 64 bit compiled state value

[major] Where is this specified?  The packet formats in §5 are different.



167	  Each H3.r9 hexagon is an EID context with corresponding H3 hexagon ID.
168	  Bound to that context is a LISP xTR specified to encapsulate packets
169	  to and from EID context and LISP Edge. Edge RTRs are used to re
170	  -tunnel packets from clients to services. Each service is also a
171	  multicast source for updating clients on the state of the H3.r15
172	  tiles, aggregated by the EID addressable geospatial context.

[major] What is an "EID context"?  It is used here twice, but not defined.


[-] Peeking ahead to Figure 2, I am able to guess what you mean in the
descriptions...but the reader shouldn't be expected to guess.



174	2. Definition of Terms

176	  H3ServiceEID: Is an addressable aggregation of H3.r15 tiles.
177	     It functions as geospatial data association context for filtering,
178	     verifying, localizing, and propagating vehicles data uploads.
179	     It is a designated destination for physical world annotations,
180	     and an (s,g) source of multicast themed update channels.
181	     H3ServiceEID is itself an H3 hexagon, large enough to provide
182	     geo-spatial compute context, but not too large as to over-burden
183	     subscribers with too much information. For Mobility Network it is
184	     H3.r9. It has a light-weight LISP protocol stack to tunnel packets
185	     aka ServerXTR. The EID is an IPv6 EID that contains the H3 64-bit
186	     address numbering scheme.

[major] "addressable aggregation of H3.r15 tiles"

But "H3.r15 tiles" are not defined anywhere.


[?] "designated destination for physical world annotations"   No idea
what this means in the context of lisp. :-(


[nit] s/(s,g)/(S,G)/g


[major] "(s,g) source of multicast themed update channels"

I guess you mean that the EID serves as the source for group-specific
multicast traffic.  The use of "(s,g) source" and "multicast themed"
doesn't make that guess straight forward.  BTW, "updates" of what/to
what?


[major] "H3.r9" are not defined.


[major] "H3 hexagon" is not defined anywhere.


[major] I started reading this definition (and making comments --
above) thinking that the "H3ServiceEID" is an EID.  But the text takes
me through "an addressable aggregation of H3.r15 tiles", "an H3
hexagon" (of just the right size), "H3.r9"...to something with a
"light-weight LISP protocol stack"...and finally back to "IPv6 EID".
Needless to say, this definition is confusing.


[major] "IPv6 EID that contains the H3 64-bit address numbering scheme"

How?  I guess the lower 64 bits...but that is just a guess.



188	  ServerXTR: Is a data-plane only LISP protocol stack implementation, it
189	     co-exists with H3ServiceEID process. When the server roams, the xTR
190	     is with it. ServerXTR encaps & decaps packets to/from EdgeRTRs.

[major] "data-plane only LISP protocol stack implementation"

How are mappings learned by the servers?


[major] Now the H3ServiceEID is a "process"...


[?] If I understand correctly, the ServerXTR is an xTR on a server...right?


[major] "When the server roams, the xTR is with it."

So...there's no xTR function if the server is not roaming?  I assume
that that the services in this tile need the xTR functionality all the
time.  Why isn't that the case?  Or am I reading too much into the
statement and it is being used just to make the point that the xTR
function is attached to the server?


[minor] I realize that "encaps & decaps" are common terms, but please
expand on firs use.  BTW, "encaps & decaps" is also used later as
"encaps/decaps" -- please use only one form.



192	  MobilityClient: Is a roaming application that may be a part of an
193	     automobile, part of a navigation application, part of municipal,
194	     state or federal government command and control application, or a
195	     street view consumer application. It has a light-weight LISP
196	     data-plane stack to tunnel packets, aka ClientXTR.

[major] "MobilityClient...aka ClientXTR."

Is a MobilityClient an xTR?

Maybe describe in general lisp terms: xTR, EID, and then introduce the
function (server, client) by illustrating in a figure...  Is this a
use case or a specification??

Also confusing...  Can there be more than one MobilityClient in a
vehicle?  For example, in the navigation app and maybe a different
system on the car?  If so, will each MobileClient have a separate xTR
function?



198	  MobilityClient EID: Is the IPv6 EID used by the Mobility Clients
199	     to source packets. The destination of such packets are only
200	     H3ServiceEIDs. The EID format is opaque and is assigned as
201	     part of the MobilityClient mobility-network authorization.

[minor] Just an observation that "Mobility Client", "MobilityClient"
(without "EID" attached to it), and even "Mobility-Client" are used
throughout the document.  Please take a look to assure consistency.


[minor] Also, "MobilityClient EID" and "MobilityClientEID" are used.


[?] "EID format is opaque"

It's an IPv6 address, right?  Is there anything relevant to lisp about
the format?


[major] "EID...is assigned as part of the MobilityClient
mobility-network authorization."

Where is the "mobility-network authorization" specified?  I later read
about the AAA mechanism...maybe put a forward reference to that and be
consistent in the names -- this is the only time in the document that
this name is used.


[?] rfc6830bis uses terms like client-side and server-side to refer to
specific things.  Are those terms related to the terminology used
here?



203	  ClientXTR: Is a data-plane only LISP protocol stack implementation
204	     co-located with the Mobility Client application. It encaps/
205	     decaps packets from/to applications to/from EdgeRTRs.

[minor] "encaps/decaps" is written above as "encaps & decaps" --
please use only one form.



207	  EdgeRTR: Is the core scale and structure of the LISP mobility network.
208	     EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID mcast
209	     registration. EdgeRTRs aggregate MobilityClients/H3Services using
210	     tunnels to facilitate hosting-providers and mobile-providers for
211	     accessing the mobility network.  EdgeRTRs decapsulate packets
212	     from ClientXTRs, ServerXTRs and re-encaps packets to the clients
213	     and servers tunnels. EdgeRTRs glean H3ServiceEIDs/MobilityClient
214	     EIDs when they decapsulates packets. EdgeRTRs store H3ServiceEIDs
215	     and RLOCs of where the H3ServiceEID is currently reachable from
216	     the map-cache. These mappings are registered to the LISP mapping.
217	     These mappings may be provisioned when H3Services are assigned
218	     EdgeRTRs. EdgeRTRs do not register MobilityClients' EIDs.
219	     Enterprises may provide their own EdgeRTRs to protect geo-privacy.

[minor] "Is the core scale and structure of the LISP mobility network."

As part of a definition that doesn't tell me much...


[minor] "EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID"

Did you mean "MobilityClient EID"?  Or maybe "MobilityClientEID"...


[major] "proxy...mcast registration"

I found something about registration (as related to multicast) in
rfc8378.  Is that what you mean?  Please add a reference.

But I found nothing about RTRs acting as a proxy.  ??


[major] I'm assuming that the "LISP mapping" is a reference to
rfc6833bis, right?  Please add a Normative reference.


[-]

   EdgeRTRs decapsulate packets from ClientXTRs, ServerXTRs and
   re-encaps packets to the clients and servers tunnels. EdgeRTRs
   glean H3ServiceEIDs/MobilityClient EIDs when they decapsulates
   packets. EdgeRTRs store H3ServiceEIDs and RLOCs of where the
   H3ServiceEID is currently reachable from the map-cache. These
   mappings are registered to the LISP mapping.

This description is a paraphrasing of what an RTR does, but it sounds
inaccurate and loose...


[major] "Enterprises may provide their own EdgeRTRs to protect geo-privacy."

I put some comments about security and privacy in the Security
Considerations section below.  In general, most of the related
concerns should have been addressed in the base specs.

In this case, EdgeRTRs are present on both sides of the mobility
network.  Are you referring to enterprises providing EdgeRTRs for both
sides?  What are the effects of a partial deployment?



221	                          ___                                  ___
222	   H3ServiceEIDs   ___  /     \           H3ServiceEIDs ___  /     \
223	            ___  /     | H3.r9 |                 ___  /     | H3.r9 |
224	          /     | H3.r9 \ ___ /                /     | H3.r9 \ ___ /
225	         | H3.r9 \ ___ /  sXTR                | H3.r9 \ ___ /  sXTR
226	          \ ___ /  sXTR    |                   \ ___ /  sXTR     |
227	            sXTR    |      |                     sXTR     |      |
228	             |      |      |                      |       |      |
229	             |      |      |                      |       |      |
230	             + -  - + - - EdgeRTR           EdgeRTR - + - + - -  +
231	                             ||  (   (   ((  ||
232	                          (                        )
233	                        (      Network Hexagons      )
234	                      (            H3-LISP              )
235	                        (      Mobility Network       )
236	                          ((                        )
237	                            ||  ((   (())   ()  ||
238	                            ||                  ||
239	                = = = = = = =                     = = = = = = =
240	               ||                                             ||
241	            EdgeRTR                                         EdgeRTR
242	           ..    ..                                      ..      ..
243	          ..       ..                                  ..          ..
244	  ((((|))))    ((((|))))                         ((((|))))    ((((|))))
245	     /|\    RAN   /|\                               /|\    RAN   /|\
246	      ..                                                          ..
247	      ..                                                          ..
248	      ..          Road tiled by 1 sqm H3.r15 ID-Ed Geo-States     ..
249	      ..                                                          ..
250	      ..                  ___    ___    ___                       ..
251	      ..  ............. /     \/     \/     \ << cXTR::MobilityClientB
252	      .. - - - - - - -  H3.r15  H3.r15 H3.r15 - - - - - - - - - - - -
253	      MobilityClientA::cXTR >> \ ___ /\ ___ / .......................

255	  Figure 2: H3.r15 state representation, H3.r9 state aggregation

[major] H3.r15 and H3.r9 are not properly defined in this document to
be able to interpret what the state may mean.



257	Figure 2 above describes the following entities:
258	  - MobilityClientA sees MobilityClientB future, and, vice versa

[major] They see the future?  I'm sure there's a different
interpretation, but I'm not sure what.

Looking at the figure for a long time I finally saw the arrows (">>"
and "<<"), which I guess indicate directional movement.  The one line
description is not enough for the reader to decipher what you mean.
This is one place where more context on H3 would be useful.



259	  - Clients: share information using addressable state routed by LISP

[nit] s/Clients/MobilityClients (?)
I know that this doesn't make the phrase fit in one line, but please
use consistent terminology.


[major] "addressable state routed by LISP"

LISP doesn't route.  In this part of the network just the LISP data
plane is used.



260	  - ClientXTR (cXTR): encapsulates over access network to EdgeRTR

[major] It also decapsulates traffic in the opposite direction.
Consider describing the "life of a packet" in each direction.



261	  - ServerXTR (sXTR): encapsulates over cloud network to EdgeRTR

[major] Same comment about decapsulation.


[minor] The "cloud network" is not shown in the figure.  The fact that
the services may be provided in the cloud is probably not relevant to
the figure, but may be relevant to the description of the system.



262	  - H3-LISP Mobility: overlay which spans cXTRs to sXTRs

[major] I assume that you're referring to the "H3-LISP Mobility
Network".  If so, it connects the EdgeRTRs, not the cXTRs and sXTRs.
At this point the traffic has been re-encapsulated.



263	  - Uploads: routed to appropriate tile by the LISP network

[?] I don't see "uploads" in the picture.  Maybe this is related to
the "life of a packet"...or the application itself.


[major] "routed to appropriate tile by the LISP network"

Again, LISP is not routing, just delivering the information to the
destination address -- IOW, there's no knowledge of the "appropriate
tile" -- and no explanation in the document about the relationship
between sourced data and "appropriate" destinations.



264	  - EdgeRTRs: perform multicast replication to edges and then cXTRs

[-] I guess "uploads" referred to the MobilityClient to server
direction.  Now you're talking about the "downward" direction.


[minor] "replication to edges"

Do you mean other EdgeRTRs?  Terminology consistency...



265	  - Clients: receive tile-by-tile geo-state updates via the multicast

[-] This last bullet describes the information carried, while most of
the other bullets talked about network functions.  It would be good to
separate those.


[nit] s/via the multicast/via multicast



267	3.  Deployment Assumptions

269	   The specification described in this document makes the following
270	   deployment assumptions:

272	   (1) Unique 64-bit HID is associated with each H3 geo-spatial tile
273	   (2) MobilityClients and H3ServiceEIDs share this well known index
274	   (3) 64-bit BDD state value is associated with each H3-indexed tile
275	   (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums

[major] All these assumptions are outside of lisp -- that in itself is
not a bad thing.  What is not good is that there's no description of
what some of these things are (index, BDD state, tile state), how they
are configured, or exchanged, or ??, and much less how to
verify/validate that the assumptions are satisfied.  As mentioned
before, there is no specific reference to the H3 or BDD work.

Furthermore, besides the "64-bit HID", which I think is associated to
the H3ServiceEID, there's no specific relationship to lisp operating
if any of these assumptions is met, or not.


[major] What is the effect on the system if one, or more, of these
assumptions is not met?



277	  0       1       2       3       4       5       6       7
278	  +-------+-------+-------+-------+-------+-------+-------+-------+
279	  |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
280	  |0123012301230123012301230123012301230123012301230123012301230123
281	  +---------------------------------------------------------------+

283	  Figure 3: Nibble based representation, 16 fields x 16 enumerations

[major] This is a representation of what?  The "tile state"?


285	   We name the nibbles using hexadecimal index according to the
286	   position where the most significant nibble has index 0.
287	   Values are defined in section 8.

[style nit] I prefer it if the document is written in the third person
(The nibbles are named...) instead of the first (We name...).


[minor] "index 0"

Does that mean that the numbers on line 279 represent the index?
Please indicate that on the figure, or at least be more explicit.


[major] Where are these values carried?  How are they signaled?  From
the assumptions above, it sounds like the values represent the "tile
state"...but I'm not sure if that is an H3 or BDD attribute.  ??

In either case, defining and maintaining an IETF-created registry
seems to assume that H3/BDD will use it.  Will they?



289	   Subscription of MobilityClients to mobility-network is renewed
290	   while on the move and is not intended as the basic connectivity.
291	   MobilityClients use DNS/AAA to obtain temporary EIDs/EdgeRTRs
292	   and use (LISP) data-plane tunnels to communicate using their
293	   temporary EIDs with the dynamically assigned EdgeRTRs.

[nit] s/to mobility-network/to the mobility-network


[minor] "not intended as the basic connectivity"  Then what it?  This
whole document talks about the mobility network -- the fact that
different connectivity may exist seems out of scope.

[minor] "use DNS/AAA...obtain temporary EIDs/EdgeRTRs...dynamically
assigned EdgeRTRs"

Where is this specified?  Please put a reference to that part of the document.



295	   MobilityClient are otherwise unaware of the LISP network control
296	   plane and simply regard the data-plane tunnels as a virtual
297	   private network (VPN) that supports IPv6 EID to upload (Ucast)
298	   and Subscribe-to (Mcast) H3Services.

[minor] "MobilityClient are otherwise unaware of the LISP network
control plane..."

As I understand it, the MobilityClient only uses the LISP data plane...


[major] The term "VPN" (used only here and in the next paragraph) may
carry connotations related to privacy that are not explained.  If
needed, consider using a different descriptor.


[nit] This is the first time "Ucast" is used.  Please expand.


[nit] Assuming that mcast was expanded before, please be consistent
with the capitalizations: most instances use "mcast", not "Mcast".



300	   In order to get access to the MobilityVPN, MobilityClients first
301	   authenticate with the MobilityVPN AAA Server. DIAMETER [RFC6733]
302	   based AAA is typically done at the provider edge (PE) by gateways.
303	   However, the typical case involves several types of CPE connected
304	   to a specific service provider. On other hand, the Mobility VPN
305	   may overlay a number of wireless networks and cloud-edge providers.
306	   It also involves dozens of Car-OEM, Driving-Applications, Smart-
307	   City vendors. This is why we require clients to first go through
308	   AAA in order to get both a MobilityClientEID and EdgeRTR RLOC.

[minor] Is the "MobilityVPN" (or "Mobility VPN") the same as the
"Mobility Network"?  Please be consistent!


[minor] Please expand AAA on first use.


[nit] I believe rfc6733 doesn't capitalize "DIAMETER" (Diameter).


[nit] s/AAA is typically done/AAA is typically used


[major] "AAA is typically done at the provider edge"

If AAA is not used, what are the risks of having an unauthorized
MobileClient. If AAA is not used, can the system operate?


[major] "AAA in order to get both a MobilityClientEID and EdgeRTR RLOC"

This is a major departure from the lisp architecture!  In general,
ITRs query the Mapping System, but in this case there are no
Map-Request/Map-Reply messages, they are replaced by AAA.  IOW, AAA is
the mapping system -- at least part of it.  Am I understanding this
correctly?

Is this new mapping system specified somewhere else?  If not, this
document will need a lot more details -- for example, I included some
questions below about the AVPs used.

Given that the Diameter Server is now the Map-Server, there's also the
question of how the mappings (if any) are registered by the ETRs.

If only the LISP data plane is used, it is ok to use a different
"mapping system".  It just needs to be completely specified -- or a
pointer to where it is included.



310	   ClientXTR performs the following steps to use the mobility network:
311	   1) obtain the address of the mobility network AAA server using DNS
312	   2) obtain MobilityClientEID and EdgeRTR(s) from AAA DIAMETER server

[major] Where is this exchange specified?


313	   3) renew authorization from AAA while using the mobility network
314	     MobilityClient DomainNameServer  DIAMETER-AAA  MobilityEdgeRTR
315	     |                    |                   |                   |
316	     | nslookup nexagon   |                   |                   |
317	     |------------------->|                   |                   |
318	     |<-------------------|                   |                   |
319	     |  Mobility AAA IP   |                   |                   |
320	     |                    |                   |                   |
321	     |  AAR(AVP:IMSI/User/Password/Toyota)    |                   |
322	     |--------------------------------------->|                   |
323	     |                    |                   | ACR(AVP ClientEID)|
324	     |                    |                   |------------------>|
325	     |                    |                   |<------------------|
326	     |                    |                   | ACA(AVP ClientEID)|
327	     |    AAA (Client::EID,EdgeRTR::RLOC)     |                   |
328	     |<---------------------------------------|                   |
329	     |                    |                   |                   |
330	     .                                                            .
331	     . Upload to IPv6 H3ServiceEID, Subscribe MLDv2 H3ServiceEID  .
332	     .                                                            .
333	     |                                                            |
334	     |----------------------------------------------------------->|
335	     .                                                            .
336	     .                                                            .
337	     |<-----------------------------------------------------------|
338	     |                                                            |
339	     .                                                            .
340	     .   Signal freeing multicast Updates from H3ServiceEID       .
341	     .                                                            .
342	     |                    |                   |                   |
343	     |               AAR(Interim)             |                   |
344	     |--------------------------------------->|   ACR (Interim)   |
345	     |                    |                   |------------------>|
346	     |                    |                   |<------------------|
347	     |                    |                   |   ACA (Interim)   |
348	     |<---------------------------------------|                   |
349	     |               AAA (Interim)            |                   |

351	  Figure 4: DNS and AAA Exchange for nexagon-network login

[major] "nslookup nexagon"

This is not a FQDN -- what is the expectation about the DNS setup that
will work in this network?

I think that going into this type of detail is too much for what
should be a description of how LISP works in this type of network.


[minor] Expand or define AAR, AAA, ACR, ACA, AVP -- I only found these
last three in rfc6733.


[major] Which AVPs are used?  Where are they specified?


[minor] The figure uses both "ClientEID" and "Client::EID" to, I
think, refer to the "MobilityClient EID".  Please be consistent.


[minor] The Figure mentions MLDv2 and multicast in general -- please
put a forward reference to where that is discussed.


[?] Does the "Interim" indication have a special meaning?  Maybe it's
something related to Diameter (?).



353	   Using this network login and re-login method we ensure that:

[?] I'm not sure where the "login and re-login method" is reflected above.



354	   - MobilityClientEIDs serve as credentials with the EdgeRTRs

[major] Does this mean that the EdgeRTRs are the nodes that complete
the authorization process -- is that what this step is?

323	     |                    |                   | ACR(AVP ClientEID)|
324	     |                    |                   |------------------>|
325	     |                    |                   |<------------------|
326	     |                    |                   | ACA(AVP ClientEID)|

If so, there seems to be a required relationship between the Diameter
server and the EdgeRTR.  What is that?



355	   - EdgeRTRs are provisioned to whitelist MobilityClient EIDs

[major] This seems related to my last question: the EdgeRTRs are
provisioned with MobilityClient EIDs -- but, how does the Diameter
server know to select a specific EID that will be authorized by the
EdgeRTR.

Note that none of this is specific to lisp -- so if there are
references where the process is explained, please point to them.


[major] "whitelist"

In order to improve inclusivity, please consider using a different term.

https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/



356	   - EdgeRTRs are not tightly coupled to H3.r9 areas (privacy/balance)

[major] I'm missing the explanation of why "privacy/balance" is the
reason for not tightly coupling, or maybe the result of it.



357	   - MobilityClients do not need to update EdgeRTRs while roaming
358	   The same EdgeRTR may serve several H3.r9 areas for ride continuity
359	   and several EdgeRTRs may load balance an H3.r9 area with high
360	   density of MobilityClients. When a MobilityClient ClientXTR is
361	   homed to EdgeRTR, it is able to communicate with H3ServiceEIDs.

[major] "MobilityClients do not need to update EdgeRTRs...may serve
several H3.r9 areas"

The MobilityClients are in the H3.r15 tiles, not H3.r9.  My guess is
that there is a hierarchical relationship that hasn't been explained.

How/When does a MobilityClient need to "update EdgeRTRs" (which I
think means change to another EdgeRTR)?  Is this an action triggered
by the MobilityClient?



363	4. Mobility Clients Network Services

365	  The mobility network functions as a standard LISP overlay.
366	  The overlay delivers unicast and multicast packets across:
367	   - multiple access-networks and radio-access specifications
368	   - multiple edge providers, public, private, and hybrid clouds

[?]



370	  We use data-plane XTRs in the stack of each mobility client/server.
371	  ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs.
372	  This structure allows for MobilityClients to "show up" at any time,
373	  behind any network provider in a given mobility network admin/NAT
374	  domain, and for any H3ServiceEID to be instantiated, moved, or
375	  failed-over to any rack in any cloud-provider. LISP overlay enables
376	  these roaming mobility network elements to communicate uninterrupted.
377	  This quality is insured by the LISP RFCs. The determination of
378	  identities for MobilityClients to always refer to the correct
379	  H3ServiceEID is insured by H3 geo-spatial HIDs.

[minor] "...XTRs are homed to one or more EdgeRTRs"

You've mentioned the concept of "homed to" a couple of times.  What
does that mean from a lisp point of view?  How is it enforced?  The
next sentence uses "to associate"...



381	  There are two options to associate ClientXTRs with LISP EdgeRTRs:

383	  i. Semi-random load-balancing by DNS/AAA

385	  In this option we assume that in a given metro edge a pool of
386	  EdgeRTRs can distribute the Mobility Clients load randomly between
387	  them and that EdgeRTRs are topologically equivalent. Each RTR uses
388	  LISP to tunnel traffic to and from other EdgeRTRs for MobilityClient
389	  with H3Service exchanges. MobilityClients home to EdgeRTRs.

391	  ii. Topological by anycast

393	  In this option we align an EdgeRTR with topological aggregation.
394	  Mobility Clients are roaming in an area home to that RTR and so
395	  is the H3 Server. There is only one hop across the edge overlay
396	  between clients and servers and mcast replication is more
397	  focused, but clients need to keep re-homing as they move.

[major] Both of this options make assumptions.  How can a deployment
determine which scenario it's in?  What happens if the assumption made
is not met anymore?


[major] The "association" of the ClientXTRs to an EdgeRTR is the
function of the mapping system.  This document is not properly
specifying this new mapping system.

Both methods above assume that ant RTR will be able to provide the
needed reachability.  It assumes that even if both sets of EdgeRTRs
may be moving, the reachability will always be there.

Also, I assume that the EdgeRTRs learn about mappings between them
(through the mobility network) through rfc6833bis mechanisms.  This
means that the traffic may reach an EdgeRTR that doesn't have a
specific mapping, or (in the anycast case) that is even disconnected
from the mobility network.

What are the conditions that guarantee end-to-end reachability?  When
can they not be met?  What are the consequences?  Are there any
possible mitigations?



...
408	       MobilityClients <> ClientXTR <Access Provider > EdgeRTR  v
409	                                                                v
410	       v < < < < Map-Assisted Mobility-Network Overlay < < < <  v
411	       v
412	       > > > > EdgeRTR <Cloud Provider> ServerXTR <> H3ServiceEID

[major] What does the term "Map-Assisted" mean?  This figure needs
more explanation.



...
416	5. Mobility Unicast and Multicast

418	  Regardless of the way a given ClientXTR was associated with EdgeRTR,
419	  an authenticated MobilityClient EID can send: [64bitH3.15ID ::
420	  64bitState]annotations to the H3.r9 H3ServiceEID. The H3.r9 EID can
421	  be calculated by clients algorithmically from the H3.15 localization.

[??] "[64bitH3.15ID :: 64bitState]annotations"  ??


[minor] Are the "H3.r9 H3ServiceEID" and "H3.r9 EID" the same thing?


[nit] s/H3.15/H3.r15


[major] "The H3.r9 EID can be calculated by clients algorithmically
from the H3.15 localization."

By "clients" I assume you're referring to the MobilityClients.  Where
is the algorithm specified?



423	  The ClientXTR encapsulates MobilityClient EID and H3ServiceEID from
424	  the ClientXTR with the destination of the EdgeRTR RLOC LISP port.
425	  EdgeRTRs then re-encapsulate annotation packets to remote EdgeRTR.
426	  The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates
427	  MobilityClient EID to the ServerXTR, to the H3ServiceEID.

[minor] "encapsulates MobilityClient EID and H3ServiceEID from the ClientXTR"

The descriptions can be a lot clearer.  The EIDs are the
source/destination of the packet that comes from the MobilityClient
(not the ClientXTR)...


[minor] "with the destination of the EdgeRTR RLOC LISP port"

The destination is the EdgeRTR RLOC, where does the "LISP port" come
in?  Maybe you tried to compress in the UDP port number.  Please be
clear and specific.


[minor] I'm not sure what the relevance of "annotation packets" (the
specific type) is.  From the lisp point of view, a packet is a packet,
or are you expecting something different for other packets from the
MobilityClient?


[nit] s/to remote EdgeRTR/to a remote EdgeRTR


[minor] "re-encapsulates MobilityClient EID to the ServerXTR, to the
H3ServiceEID"

As written it sounds like a double re-encapsulation: to the ServerXTR
and then to the H3ServiceEID.  What is re-encapsulated is not the EID,
but the packet.



429	  The headers consist of the following fields:

431	  Outer headers = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56
432	  Inner headers = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52
433	  1500 (MTU) - 56 - 52 = 1392 bytes of effective payload

[minor] Please explain somewhere that you are listing the size of the headers.



435	  Nexagon Header Type allows for kv tupples or vkkk flooding

[?] What do k and v stand for?  This is the only part of the document
(and below) where this nomenclature is used.



436	  Type 0:reserved
437	  Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs
438	  Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 H3-R15 IDs
439	  Type 3-255: unassigned

[minor] Ok, so kv, vkkk is somewhat clarified.  Does this mean that
the types have different formats?  Please be more descriptive in the
definition of the types.


[major] Peeking ahead, I see that there's no description of the fields
or where the values come from after Figure 6.  I think it's better to
first present the figure and then describe the fields.  Please move
the fields description to after the figure.


[major] I assume you want IANA to manage the allocation of the types.
Please include that information in the IANA Considerations Section.



440	  Nexagon Header GZIP field: 0x000 no compression, or GZIP version.

[major] What is compressed?


[major] Where do the versions come from?  I found rfc1952 which
specifies GZIP version 4.3 -- how would that be represented in the
3-bit field?


[major] What should a receiver do if the version is not supported or
unknown?  This part of the specification seems to go beyond describing
how lisp is used --- but the packet format is described here, so I
have to ask.



441	  Nexagon Header Reserved bits

[major] In most cases reserved fields are specified as being set to 0
on transmission and ignored when received, do you want to specify
anything like that?



442	  Nexagon Header kv count (in any format)

[major] The figure shows "Pair Count = X" (which should really be just
"Pair Count"), and not "kv count".


[minor] What do you mean by "in any format"?  I assume you're
referring to the types...but then it's not clear how, for example Type
2 ("value, key,key,key..") should be counted.  Please be specific.



444	 0                   1                   2                   3
445	 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
446	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
447	|Version| Traffic Class |           Flow Label                  |  |
448	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
449	|         Payload Length        |  Next Header  |   Hop Limit   |  |
450	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
451	|                                                               |  |
452	+                                                               +  |
453	|                                                               |  |
454	+                    Source MobilityClientEID                   +  |
455	|                                                               | IPv6
456	+                                                               +  |
457	|                                                               |  |
458	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
459	|                                                               |  |
460	+                                                               +  |
461	|                                                               |  |
462	+                       Dest H3ServiceEID                       +  |
463	|                                                               |  |
464	+                                                               +  |
465	|                                                               | /
466	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467	|       Source Port = xxxx      |       Dest Port = xxxx        | \
468	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
469	|           UDP Length          |        UDP Checksum           | /
470	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
471	|  Type         |gzip |        Reserved         | Pair Count = X| Nexgon
472	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
473	|                                                               |
474	+                       64 Bit H3-R15 ID                        +
475	|                                                               |
476	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477	|                                                               |
478	+                       64 Bit State                            +
479	|                                                               |
480	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481	|                                                               |
482	+                       64 Bit H3-R15 ID                        +
483	|                                                               |
484	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
485	|                                                               |
486	+                       64 Bit State                            +
487	|                                                               |
488	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

490	  Figure 6: Uploaded detections packet format

[nit] s/Nexgon/Nexagon

I realize that the whole word may not fit, but that is not an excuse
to use a shorthand version without explanation.  Instead, explain
which fields are part of the Nexagon Header (as mentioned above).


[major] The rest of the fields are not specified anywhere.



491	  To Summarize Unicast Uploads:

493	   (1) MobilityClients can send annotations are localized to H3.r15
494	       tile. These annotations are sent to H3.r9 mobility H3ServiceEIDs

[minor] "MobilityClients can send annotations are localized to H3.r15 tile."

It's not clear to me if the MobilityClients or the annotations are localized.


[?] I'm guessing that "annnotations" and "uploads" are the same thing.
The word "upload" is used elsewhere as a noun, not just an action.
Please clarify.


[minor] "sent to H3.r9 mobility H3ServiceEIDs"

"H3ServiceEIDs" and "H3.r9 EIDs" have been used before to mean the
same thing -- I think.  This sentence seems to introduce a new term:
"H3.r9 mobility H3ServiceEIDs".   If they are all the same, please use
only one.  See the definition in §2.


[nit] s/H3ServiceEIDs/H3ServiceEIDs.



495	   (2) MobilityClient EID and H3ServiceEID HID are encapsulated:
496	         XTR <> RTR <> RTR <> XTR
497	       * RTRs can map-resolve re-tunnel HIDs

[minor] Please explain what is meant by "<>", it may not be clear to everyone.


[minor] Even though I understand what you mean my "map-resolve", I
haven't seen the term used as a verb in rfc6830bis/rfc6833.


[minor] s/re-tunnel/re-encapsulates


[minor] I mentioned before about the need to clarify what an HID is
and its relationship to EID and the H3ServiceEID in particular.



498	   (3) RTRs re-encapsulate original source-dest to ServerXTRs
499	       ServerXTRs decapsulate packets to H3ServiceEID

[minor] This text sounds like a repetition of step 2, which shows the
whole path.



501	  Each H3.r9 Server is also an IP Multicast Source used to update
502	  subscribers on the aggregate state of the H3.r15 tiles in the H3.r9
503	  server. This forms a multipoint to multipoint state channel per H3
504	  location, where the aggregation has compute-first propagation.

[minor] "H3.r9 Server" is a new term.


[minor] s/state of the H3.r15 tiles in the H3.r9 server/state of the
H3.r15 tiles


[?] "multipoint to multipoint state channel per H3 location"

Because there are multiple H3.r9 Servers per tile?  You'll probably
need to explain that more.


[minor] "the aggregation has compute-first propagation"

??



506	  We use [RFC8378] signal-free multicast to implement mcast channels in
507	  the overlay. The mobility network has many channels, with thousands
508	  subscribers per channel. MobilityClients driving through/subscribing
509	  to an H3.r9 area can explicitly issue an [RFC4604] MLDv2 in order to
510	  subscribe, or, may be subscribed implicitly by the EdgeRTR.

[minor] Is an "area" the same things as a "tile"?


[?] "MobilityClients driving through/subscribing to an H3.r9 area..."

I thought the MobilityClients were in the H3.r15 tiles.  :-(


[major] The MobilityClient "can explicitly issue an [RFC4604] MLDv2" what?


[major] s/RFC4604/RFC3810


[major] How does the MobilityClient know/discover which (S,G) to join?


[major] "MobilityClients...can...subscribe, or, may be subscribed
implicitly by the EdgeRTR."

How does a MobilityClient know what to do -- discover and join, or
wait.  How does the EdgeRTR discover which groups to join?  Even if
implicitly subscribed, the MobilityClient should somehow know which
(S,G) to listen to -- how is that done?



512	  The advantage of explicit client MLDv2 registration as [RFC8378]
513	  trigger is that clients manage their own mobility mcast handover per
514	  location-direction vectors, and that it allows for otherwise silent
515	  non annotating clients. The advantage of EdgeRTR implicit registration
516	  is that less signaling required.

[major] "client MLDv2 registration as [RFC8378] trigger"

rfc8378 unfortunately only talked about IGMP, no mention of MLD.
We'll need to add a paragraph or two (a couple of sentences may be
enough) about how the specification in rfc8378 also applies without
modification (?) to MLDv2.


[nit] s/clients/MobilityClients/g


[major] "mcast handover per location-direction vectors"

This makes discovering the (S,G) more important as it may change.


[major] "otherwise silent non annotating clients"

I thought annotations were in the client to server direction.  But
multicast is in the opposite direction.  What is the relationship
between the ability (or maybe willingness) of the MobilityClient to
send/annotate information and them receiving multicast traffic?  Is
there a downside if silent MobilityClients receive the multicast
information and use it...



518	  MLDv2 signaling messages are encapsulated between the ClientXTR and
519	  EdgeRTR, therefore there is no requirement for the underlying network
520	  to support native multicast. If native access multicast is supported
521	  then MobilityClient registration to H3ServiceEID safety channels may
522	  be integrated with it, in which case mobile packet-core element
523	  supporting it will use this standard to register with the
524	  appropriate H3.r9 channels in its area.

[major] "MLDv2 signaling messages are encapsulated between the
ClientXTR and EdgeRTR..."

rfc8378 doesn't talk about encapsulating anything -- §5.1.1 assumes
PIM being enabled.  As mentioned above, the use of rfc8378 is not "as
is", but there are assumptions made that are not obvious.  You'll need
to add text about the use of rfc8378 and the assumptions/differences.

The paragraph goes on to talk about the case when "native access
multicast is supported" -- I guess at this point rfc8378 is not used
anymore.  The text says that the "registration...may be integrated
with it" -- does this mean that is is optional?

But then it goes back to an "element supporting it will use this
standard to register with the appropriate H3.r9 channels in its area".
By "this standard" do you mean using rfc8378 or not -- I'm confused.
Also, I guess that the "H3.r9 channels" are equivalent to the
"H3ServiceEID safety channels" mentioned before, and to any other
mention of multicast information.  Is that a good guess?


[minor] This is the first time that "H3ServiceEID safety channels" is
used.  I assume the type of channel doesn't matter -- it's just that
it was never mentioned this way before.  Or is there relevance in the
use of "safety" to describe it?  Also, if we want to be strict, the
multicast information is provided by the servers not the EID.



526	  Multicast update packets are of the following structure:

528	 0                   1                   2                   3
529	 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
530	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
531	|Version| Traffic Class |           Flow Label                  |  |
532	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
533	|         Payload Length        |  Next Header  |   Hop Limit   |  |
534	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
535	|                                                               |  |
536	+                                                               +  |
537	|                                                               |  |
538	+                       Source H3-R9 EID Address                +  |
539	|                                                               | IPv6
540	+                                                               +  |
541	|                                                               |  |
542	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
543	|                                                               |  |
544	+                                                               +  |
545	|                                                               |  |
546	+                          Group Address                        +  |
547	|                                                               |  |
548	+                                                               +  |
549	|                                                               | /
550	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
551	|       Source Port = xxxx      |       Dest Port = xxxx        | \
552	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
553	|           UDP Length          |        UDP Checksum           | /
554	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
555	|                                                               |Nexagon
556	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
557	~                            Nexagons Payload                   ~
558	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

560	  Figure 7: Mcast update packet header

[minor] As drawn, the "Nexagon" section seems to only cover the first
4 bytes.  It also looks like those are empty.  ??


[major] Where is the "Nexagons Payload" defined?  Is that what the
next two figures show?  It is not clear.


[major] This part shows application level packet formats -- which have
no relationship to LISP.  Does this part of the description need to be
part of this document?



562	 0                   1                   2                   3
563	 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
564	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
565	|  Type =   1   |gzip |        Reserved         | Pair Count = X|Nexagon
566	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
567	|                                                               |
568	+                       64 Bit H3-R15 ID                        +
569	|                                                               |
570	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
571	|                                                               |
572	+                       64 Bit State                            +
573	|                                                               |
574	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
575	|                                                               |
576	+                       64 Bit H3-R15 ID                        +
577	|                                                               |
578	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
579	|                                                               |
580	+                       64 Bit State                            +
581	|                                                               |
582	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

584	  Figure 8: Mcast update payload, key-value, key-value..

[major] Where are the fields specified?  If they were defined earlier
(gzip, for example), please include a pointer to where.



...
610	  The remote EdgeRTRs homing MobilityClients in turn replicate the
611	  packet to the MobilityClients registered with them.

[major] The paragraph before the figures talked about how the tail end
of the multicast tree (from the MobilityClient to the EdgeRTR) was
formed.  But the rest of the process was not described.  This
paragraph jumps right into the delivery.  IOW, there's no description
of how the Servers know if there are subscribers..



613	  We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K)
614	  possible in H3.r9 to be part of any road. The H3.r9 server can
615	  transmit the status of all 600 or just those with meaningful states
616	  based on updated SLA and policy.

[major] "We expect an average of 600 H3.r15 tiles of the full 7^6
(~100K) possible...The H3.r9 server can transmit the status of all 600
or just those with meaningful states..."

Is there a scalability limitation with the system?



618	  To Summarize:

620	   (1) H3LISP Clients tune to H3.r9 mobility updates using [RFC8378]
621	       H3LISP Client issue MLDv2 registration to H3.r9 HIDs
622	       ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g).

[minor] "H3LISP" was used before in the context of a network...not a client.


[nit] These seem to be 3 separate sentences (or fragments).  Maybe use bullets.


[minor] "tune to H3.r9 mobility updates"   This is a new way to refer
to registration and multicast...


[minor] "using [RFC8378]"  See my comments above about rfc8378.


[minor] "H3.r9 HIDs"  And another way to refer to "H3.r9 channels"...



624	   (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g)
625	       RLOCs EdgeRTRs replicate mobility update and tunnel to registered
626	       EdgeRTRs Remote EdgeRTRs replicate updates to ClientXTRs.

[] See other comments above about the description of the process.



628	6.  Security Considerations

630	  The nexagon layer3 v2n network is inherently more secure and private
631	  then peer to peer alternatives because of the indirection. No car or
632	  infrastructure element communicates directly with MobilityClients.
633	  All information is conveyed using shared addressable geo-state.
634	  MobilityClients receive information only from geospatial channels
635	  originating from a trusted broker. MobilityClients have no indication
636	  as to the origin of the information. This is an important step towards
637	  better privacy, security, extendability, and interoperability compared
638	  with legacy layer2 protocols.

[major] This paragraph uses indirection to claim that this proposal is
"more secure and private" than the alternatives.  However, we don't
need a comparison, or a justification that this is better because the
alternative is not.  What is needed in an analysis of *this* proposal.

[Even if you wanted to compare to "peer to peer alternatives", there
is no baseline (or reference) presented to compare to.]

Please take a look at rfc6973 and rfc3552.

Note that I'm making this comment because of the claims made in
different parts of the document.  Because this use case is built on
top of lisp, many of the aspects should have been considered in the
base specifications, so pointing to them should cover a significant
portion of what is needed.  The only things left should be anything
that is specific to a nexagon-type deployment that is not present in a
typical lisp deployment.



640	  In order to be able to use the nexagon mobility network for a given
641	  period, the mobility clients go through a DNS/AAA stage by which they
642	  obtain their clientEID identifiers-credentials and the RLOCs of
643	  EdgeRTRs they may use as gateways to the network. This MobilityClient
644	  <> EdgeRTR interface is the most sensitive in this network to privacy
645	  and security considerations.

[major] This (the "DNS/AAA stage") is one of the parts of the solution
that is not related to lisp.


647	  The traffic on the MobilityClient<>EdgeRTR interface is tunneled, and
648	  its UDP content may be encrypted; still, the EdgeRTR will know based
649	  on the LISP headers alone the MobilityClient RLOC and H3-R9 (~0.1sqkm)
650	  geo-spatial area to which a given client uploads or subscribes to.

[major] "may be encrypted"

This is the first mention of encryption in the document.  If it is
possible, where is it specified?  What are the considerations to do it
or not?


[major] "H3-R9 (~0.1sqkm) geo-spatial area"

Knowing the location of the MobilityClient, its movement, and being
able to track it is a privacy issue.  I need you to address that in a
privacy section (see rfc6973).



652	  For this reason we envision the ability of enterprise or groups of
653	  users to "bring their own" EdgeRTRs. BYO-RTR masks individual clients'
654	  RLOC to H3-R9 association and is pre-provisioned to be able to use the
655	  mapping system and be on a white-list of EdgeRTRs aggregating
656	  H3ServiceEIDs. If the EdgeRTR functionality is delivered by 5GCore UPF
657	  then the only entity which can correlate underlay IP, User, and Geo-
658	  location is the regulated carrier, which can do so anyway.

[major] There are two sets of EdgeRTRs -- MobilityClient-facing and
Server-facing.  Does the ""bring their own" EdgeRTRs" strategy apply
to both or just one?  If only the MobilityClient-facing EdgeRTRs are
enterprise-specific, but the rest of the network is not, then there
are still opportunities for the tracking given that the rest of the
traffic (both annotations and multicast are in the clear), etc.


[?] "BYO-RTR...pre-provisioned to be able to use the mapping system
and be on a white-list of EdgeRTRs aggregating H3ServiceEIDs."

If the "EdgeRTRs aggregating H3ServiceEIDs" are "public" (not
enterprise-specific) then the configuration task is not trivial.  Are
there management/operational considerations that would apply to making
the decision of using BYO-RTRs?  Given that we're talking about
security/privacy considerations, I'm specially interested in those.


[major] "EdgeRTR functionality is delivered by 5GCore UPF"

This is the one and only time when 5G is mentioned in this document.
You'll need to provide more background on this option, expand UPF,
etc.



660	  Beyond this hop, the mapping system does not hold MobilityClientEIDs,
661	  and remote EdgeRTRs are only aware of MobilityClient ephemeral EIDs,
662	  not actual RLOC or any other mobile-device identifiers. EdgeRTRs
663	  register in the mapping (s,g) H3-R9 multicast groups. Which clients
664	  use which EdgeRTR is not in the mapping system, only the AAA server is
665	  aware of that. The H3ServiceEIDs themselves decrypt and parse actual
666	  H3-R15 annotations; they also consider during this MobilityClientEID
667	  credentials to avoid "fake-news", but again these are only temporary
668	  EIDs allocated to clients in order to be able to use the mobility
669	  network and not for their actual IP.

[?] What is the difference between MobilityClientEIDs and
"MobilityClient ephemeral EIDs"?  I understand the word "ephemeral" --
but the EID of the MobilityClient part is what sounds the same to me.


[major] "consider during this MobilityClientEID credentials to avoid
"fake-news""

Which credentials?

Does this mean that the H3ServiceEID can make decision on whether to
accept the information from the MobilityClients based on their
credentials?

You might want to be a little more specific on the meaning of "fake
news" in this context.



671	  H3Services are provisioned to their EdgeRTRs, in the EdgeRTRs, and
672	  optionally also in the mapping system.

[?] "provisioned to their EdgeRTRs, in the EdgeRTRs"   To and in???


[major] Services are provisioned in the mapping system?



674	  In summary of main risk mitigations for the lisp-nexagon interface:

[major] This is the first mention of the "lisp-nexagon interface".
The description below doesn't reflect what I would consider an
"interface".  Please describe more.



676	  (1) tapping: all communications are through dynamic tunnels therefore
677	  may be encrypted using IP-Sec or other supported point to point
678	  underlay standards. These are not static tunnels but LISP re-tunneling
679	  routers (RTRs) perform all nexagon Overlay aggregation.

[minor] "dynamic tunnels therefore may be encrypted"

Maybe it's just me, but I don't see an obvious connection between a
dynamic tunnel and the fact that encryption can be used.  I'm sure the
contents of static tunnels can be encrypted too.


[major] "may be encrypted using IP-Sec or other supported point to
point underlay standards"

If the encryption (this is just the second mention) is not required or
even recommended, protection against monitoring is not assured.


[?] "These are not static tunnels but LISP re-tunneling routers (RTRs)
perform all nexagon Overlay aggregation."

Sorry, but in the context of this section, I'm not sure what this
sentence is expected to convey.  In the previous sentence the use of
dynamic tunnels (aka "not static tunnels") seem to be used in a
positive way.  This sentence uses "but", which is confusing me...



681	  (2) spoofing: it is very hard to guess a MobilityClientEID valid for
682	  a short period of time. Clients and H3Services EIDs are whitelisted
683	  in EdgeRTRs, Clients using the AAA procedure, H3Services via dev-ops.

[major] "it is very hard to guess"

I'm not a security expert, but the pool of addresses is finite, so it
would seem that it may not be too hard to randomly spoof packets from
a limited range.  I'm sure the security reviewers will want more
assurances.


[] The mention of "dev-ops" will trigger the question of "how?" and
whether a YANG model exists for the configuration and monitoring of
this system.


685	  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs
686	  should be caught by the underlying service provider edge and access
687	  networks. EID impersonating is caught by EdgeRTR EID RLOC whitelist
688	  mismatch.

[] I don't think I understand the difference between "spoofing" and
"impersonating". :-(


[major] "should be caught by the underlying service provider edge and
access networks"

"should be caught" doesn't transmit a lot of confidence.   How is it done?



690	  (4) credibility: the interface crowd-sources geo-state and does not
691	  assume to trust single detections. Credit history track to
692	  MobilityClientEIDs by as part of normal H3Services fact checking,
693	  aggregate scores affect AAA credentials.

[major] "the interface crowd-sources geo-state"

In this context, "the interface" sounds like a place in the network,
an entity/node that has this function.  ???

This function seems to be at the application layer...and not one
related to lisp.


[major] "Credit history track to MobilityClientEIDs by as part of
normal H3Services fact checking, aggregate scores affect AAA
credentials."

Again, this part is not related to lisp.

Also, "fact checking" is mentioned -- I assume related to the mention
of "fake news" earlier.  I don't understand the relationship between
"credit history" and the "AAA credentials".



695	  (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and
696	  geo-location, only AAA is aware of client IDs credentials and credit
697	  but not geo-location. Aggregate credit score span all H3Services
698	  administratively without source.

[major] From the privacy point of view, please indicate which
potential risk still may exist even if all the information is not
known everywhere.  I'm specially interested in the location.



...
707	8.  IANA Considerations
...
715	Such registry should be populated with the following sub registries.

[major] There's no indication how/when any of the values in these
registries is used, or what they mean.  If defined here there should
be a discussion of their use (not in this section).


[EoR -19]