Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Paul:

This needs further mail list discussion, especially the point about ND.

Russ

> On Apr 15, 2020, at 10:35 AM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
> 
> Hi Fred,
> I will include your comments on the aviation domain in the revision of our IPWAVE PS draft.
> 
> Thanks for your valuable input.
> 
> Best Regards,
> Paul
> 
> 
> 2020년 4월 15일 (수) 오전 12:34, Templin (US), Fred L <Fred..L.Templin@boeing.com <mailto:Fred.L.Templin@boeing.com>>님이 작성:
> Hi, I read this draft and have some comments. In the aviation domain, we are designing
> an Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS)
> with the goal of having a worldwide IPv6 Internetwork interconnecting aircraft, air traffic
> controllers and other authorized entities. This work is focused in the International Civil
> Aviation Organization (ICAO), but is now being brought into the IETF:
> 
> https://datatracker.ietf.org/liaison/1676/ <https://datatracker.ietf.org/liaison/1676/>
> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/ <https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/>
> https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/ <https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/>
> 
> However, the vehicular network model we have for the airplanes differs significantly from
> the vehicular model in this ipwave draft when in fact I think there should be no difference.
> 
> In particular, in the ATN/IPS aircraft are statically configured with a Mobile Network
> Prefix (MNP) (sort of like a VIN) that travels with the aircraft wherever it goes. It uses
> this MNP to form a unique link-local address, then assigns the address to the OMNI
> interface which is a virtual interface configured over the wireless data link interfaces.
> Then, on the wireless links themselves, there are no on-link prefixes and no PIOs
> advertised by access routers. The wireless links therefore carry only link-local or
> MNP-addressed IPv6 packets, therefore no two vehicles will appear to be on the
> same subnet and no multi-link issues for subnet partitions and merges occur.. Also,
> DAD is not needed at all due to the unique assignment of MNPs.
> 
> This same model could be applied to ipwave vehicles, and would alleviate the problems
> stated in Section 5. In particular, the link model could adopt the OMNI link model (see
> the OMNI draft) where all nodes within the transportation system are "neighbors" on
> a shared NBMA virtual link. IPv6 ND works with no modifications, and the link model is
> always connected. So, there would be no need for vehicular extensions to IPv6 and ND.
> Likewise, mobility management services would work the same as the ATN/IPS design
> and would not require any adaptations for fast-moving vehicles. 
> 
> Final comment for now - the document lists only MIPv6 and PMIPv6 as example
> mobility services. We are considering them in the aviation domain, but also have
> AERO and LISP as candidate services. Since these would also apply in the ipwave
> case, it would be good to list them as candidates here also.
> 
> Fred
> _______________________________________________
> its mailing list
> its@ietf.org <mailto:its@ietf.org>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its