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

[Sharon Barkai <[e-mail]>]

Thank You Alvaro for the detailed review.
It is a great effort and is much appreciated!

I agree with your impression that it seems the draft tried to do too much.

The main reason is probably when the work started the concepts of mobility geolocation services were not yet well defined.
Consequently we were required to explain both the need and differentiation to other mechanisms using unstable terminology. 

At this point the terminology in the industry is a lot clearer.
The problem statement can therefore be made a lot clearer also.


The much narrower application routing problem statement refers to resolving 
key issues in the dataflow between mobility clients and Geolocation Services,
yet still probably requires:

- clear association between geospatial grids and EID addressable Geolocation Services
- association between geospatial grid for Geolocation and for point geospatial detections 
- example procedure for clients to use lisp as the application network with geo-privacy
- basic baseline tying enumerated detections, geo-locations, eid-addresses, and routing


I am attaching such a narrower problem rephrasing draft.
Was wondering if this direction is acceptable in your view.








> On Jun 3, 2022, at 18:12, Alvaro Retana <[e-mail]> wrote:
> 
> Hi!
> 
> This is a long review — some mail clients may truncate some of the text.  Here’s a pointer to the complete review:
> 
> https://mailarchive.ietf.org/arch/msg/lisp/b1WeZ7eCrpc2nWJFtf0nMDut2pI/ <https://mailarchive.ietf.org/arch/msg/lisp/b1WeZ7eCrpc2nWJFtf0nMDut2pI/> 
> 
> Alvaro.
> 
> On June 3, 2022 at 11:08:53 AM, Alvaro Retana ([e-mail] <mailto:[e-mail]>) wrote:
> 
>> 
>> 
>> 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 <https://mailarchive.ietf.org/arch/msg/its/WXt2d-FefiZ_iOcBsLgATKLDvVw>  
>>     [2] https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking <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 <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 <http://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/ <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 <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 <https://h3geo.org/>)is/(https://h3geo.org <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 <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/ <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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>