Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

["Templin, Fred L" <[e-mail]>]

Hi Dino,

> -----Original Message-----
> From: Dino Farinacci [mailto:[e-mail]]
> Sent: Monday, June 05, 2017 3:09 PM
> To: Templin, Fred L <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
> 
> > LISP’ers,
> 
> Fred, thanks for the email. Sorry for the delay on my response.
> 
> > Since the closing of the Routing Research Group (RRG), I have been focused
> > on furthering the development of my own technologies that began there,
> > and really haven't paid much attention to LISP - even to the point that I never
> > even took the time to read the LISP specs. That has changed over the past
> > couple of days, and now I think I have something to discuss that should
> > interest this group.
> 
> Well a lot of machinery has been added for the various new and modern use-cases coming up these days.
> 
> > I am involved in a working group that is designing an IPv6-based Internetwork
> > for the worldwide civil aviation air traffic management system. The network
> > will be known as the Aeronautical Telecommunications Network with Internet
> > Protocol Services (ATN/IPS). It will involve air traffic controllers communicating
> > with aircraft that use aviation data links with low bandwidth and high delay
> > properties (with some links having bandwidth as low as 32Kbps!). Each aircraft
> > will receive a /56 IPv6 prefix taken from a shorter ATN/IPS service prefix
> > (e.g., 2001:db8::/32).
> 
> Okay.
> 
> > Aircraft may undergo mobility events throughout their various phases of flights,
> > such as handing off between cell towers, switching from a terrestrial data link
> > to a satellite link, etc. So, the network needs to be designed to handle most
> > mobility events at the intra-site level and only propagate mobility events to
> > the network core when there is a major movement between sites. To that
> > end, I have published a document titled:
> 
> Note, have a look at draft-farinacci-lisp-predictive-rlocs-02. It has been called for adoption for a working group document. With this
> mechanism, we minimize packet loss an wouldn’t have to have a control-plane topology carry data packets as you are suggesting
> below.

Thanks, I read the document. It looks like the approach focuses on trying to hit
a moving target, and an airplane might be a good example use case. That is good,
but not exactly the case I was concerned about. I am concerned about an airplane
that sends a single, isolated packet that gets routed through some ground
network domain to an ITR that has no mapping cache entry for the destination.
The ITR then has to issue a map-request and wait for a map-reply to come back,
and in the interim the isolated packet could be lost. I would rather see the
packet make steady forward progress toward the destination even if it might
need to take a slightly longer path.

> > "A Simple BGP-based Mobile Routing System for the Aeronautical
> > Telecommunications Network":
> > https://datatracker.ietf.org/doc/draft-templin-atn-bgp/
> >
> > This document describes a simple BGP-based hierarchy in an overlay network
> > using tunnels. But after my reading over the past couple of days, I have come
> > to realize that it is an example of a LISP+ALT topology.
> 
> Well if you extend the LISP-ALT from the map-resolvers/map-servers to the xTR, then you have that push mechanism available.And
> then you know where an ETR is for a given EID.

I think where my document might differ from classical LISP-ALT (if there is such
a thing) is that the xTRs are also BGP routers but they have only a partial set of
EID-to-RLOC mappings. And, for any EID for which the xTR does not have a
mapping, it forwards packets to  a "default" BGP router that does have the
full set of mappings.

> > However, for this specific use case I see a possible departure from the
> > recommendations of RFC6836. Namely, the packets produced by aviation data
> 
> Because the topology was provisioned and capacity planned for moving small Map-Request messages that had different delivery
> requirements then packet data.

That sounds like a network planning consideration. The system could be sized
to accommodate data packets as well as control. And, I am not talking about
large packets at high data rates - I am expecting that only a few initial data
packets are forwarded over the longer path before route optimization
discovers a direct ITR->ETR path, and/or safety-of-flight critical small data
packets that need to be delivered with the highest possible reliability.

> > links need to be treated as precious commodities that are to be delivered
> > with the highest degree of reliability possible, which means that they must
> > not be dropped due to an on-demand mapping table lookup. This means
> > that the packets should be routed over the LISP+ALT topology unless or
> > until a mapping is discovered. RFC6836 recommends against this in the
> > general sense, but I believe what we have here is an exception.
> 
> I don’t think you need to. I think the reason you suggest that is because a LISP-ALT topology knows “where topologically” an EID is. But
> if you have that, you could just encapsulate to the last-hop BGP xTR. So the LISP-ALT topology wouldn’t be needed for packet data.

Based on what you are saying, I think there may be a difference between
"classical" LISP-ALT and what my document is proposing. In my design, ITRs
that are also BGP routers have only partial mapping information initially and
so don't know how to reach the last-hop BGP xTR until a route optimization
message is received. The (partial topology / full topology) design reduces
the number of BGP updates and reduces the BGP convergence time.

> > The packets produced by aircraft need to be treated as precious commodities
> 
> That is what everyone says. Just not your industry.  ;-)
> 
> > by the network since there is no way to tell if the aircraft will be able to
> > retransmit if the packet is dropped - each packet should be considered
> > as potentially the aircraft's very last transmission before falling silent.
> 
> Is there a multicast requirement?

Yes, good point. The system will need to support multicast. I don't address
this in the current document version, but it will need to be addressed.

> > So, what I think we should consider is whether there is a class of packets
> > that should *always* be routed over the LISP+ALT topology, i.e., instead
> > of serving as data probes. This could also give rise to a hybrid topology
> > where safety-of-flight-critical packets are unconditionally forwarded over
> > the ALT topology while lower priority packets are forwarded from ITR to
> > ETR in the true LISP sense.
> 
> Give us your opinion about the suggestions above.
> 
> > Please have a look at my document and consider this use case I am
> > describing. Please post comments to the list.
> 
> I did. We used this idea in many places to have a “push-based” overlay using the BGP protocol. I probably have implemented 3
> different variants of it. So it is a well-known tool.

The other thing to mention about BGP is this. Packets sent over the same paths
that carry BGP peerings maintained by TCP keepalives have the assurance that
the path has been tested before any data packets try to use the path. In contrast,
in my understanding of LISP when an ITR receives a map-reply from an ETR, it
knows that the ETR is up but does not yet know if the ITR->ETR path is working
because that path has not been tested yet. So, sending packets without testing
the ITR->ETR path first is a leap of faith in a certain sense and could result in a
black hole if that path is somehow blocked. In the approach I am suggesting,
ITR->ETR paths are always tested first before any data packets are sent.

Thanks - Fred
[e-mail]

> Thanks,
> Dino
> 
> >
> > Thanks- Fred
> > [e-mail]
> > _______________________________________________
> > lisp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
>