CC’ing the LISP working group since you are soliciting help. LISP WG folks, please comment. Thanks in advance.
> Le 06/04/2016 23:05, Dino Farinacci a écrit : >>> Any new solution designed in this group must not alter what you >>> know to do v2i with LISP. For example, if there is prefix exchange >>> between vehicle and an RSU that must not break LISP from doing v2i >>> (vehicle to Internet) through that same RSU. There is a similar >>> problem in Mobile IP. >> >> LISP doens’t have a prefix exchange. The vehicle would be assigned a >> static IPv6 EID address. There won’t be any broad changes to the LISP >> protocol to support this because we support such use-cases already. > > It is good that LISP can work ok when prefix exchanges happen near it. This > kind of text can easily make part of a gap analysis draft. > > If a car uses LISP for its V2I, and car uses a prefix exchange to a nearby > car, you may want that people in the Internet reach this latter car via > former's car LISP V2I. In that case, one may want LISP to accept a prefix > coming from another car, into the LISP system, maybe tag it differently. There should be no prefix exchange. It takes too long to do signalling when you want to move application data. The car should have an EID that is preassigned (and based on the VIN number of the car - auto-makers have asked for this requirement). When the car moves in signal range of an RSU, it uses it immmediately to send traffic. Return traffic needs to be encapsulated to the RSU, so the EID to RSU-RLOC binding needs to go to the mapping database as fast as possible. We can take advantage of a liner physical path and do predictive RLOCs. So encapsulated traffic can go to the current RSU, or the one the car is about to approach, or both at the same time to minimize packet loss. > That would express that prefix exchanges can work fully independently of LISP. Or avoided all together because it will serve no purpose. >> That is, an EID can move around when another device is the RLOC. So >> the RSU is the RLOC and encap/decaps packets to and from the EID (the >> car) that roams. The EIDs that come in range of the RSU are >> registered dynamically to the mapping system. >> >> We do this for LISP-MN when LISP runs in a smartphone. And we do this >> when VM roams from one type-of-rack switch to another in the data >> center. In the former case, the EID and RLOC in are in the same node. >> In the latter case, the EID and RLOC are in separate nodes. >> >> So we (the LISP WG) can present the solution and the ITS group can >> decide what the gaps are. > > Ok. > > Now the question is also whether there is someone from the LISP community > intent in contributing text to a WG item in ITS, called 'gap analysis’. We will get someone to do it. > >>> If so, then this should be described so in the gap analysis or in a >>> requirements draft. Which one would you prefer? >>> >>> (RSU: Road Side Unit: a set of computers linked by Ethernet and >>> situated in a box along the road, to control traffic lights and >>> other embedded sensors, and also do 802.11p to the vehicle; an RSU >>> is connected to the Internet by either ADSL or its own cellular >>> link). >> >> And as I mentioned in the BOF. We solved this with planes. Where the >> EIDs were end-systems on the plane that had session continuity >> requirements. When the planes flew over routers on the ground, the >> routers were the RLOCs for the EIDs on the plane. Very much like cars >> driving by RSUs. >> >> If you think it would be useful, we could even demonstrate this for >> the ITS group. > > Thank you for the offer! Demonstrators are always welcome. We can show solutions and architectures for better understanding through demos. > But, we are not there yet. Let's discuss charter now and in 1 month we'll > see. > > Alex Ack. Dino > >> >> Dino >> >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
