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