On Tue, Mar 13, 2018 at 10:58 AM, Templin, Fred L <fred.l.temp...@boeing.com > wrote:
> Hi Chris, > > > > >yup, sure what I was proposing is that they DO participate. > > >I could see a world where the plane has a simple BGP instance, and some > orchestration does the equivalent of the mobile cell hand-off for > hand-devices: > > "about to leave AS1, start peering with AS2, ... drop peering with AS1" > > > > With the Connexion By Boeing experience, we have proof that frequent > injections > > and withdrawals of prefixes due to mobility is bad for BGP. Plus, aircraft > are > > it's bad for bgp on the global scale, but in a VPN scenario you're talking about ~10k routes? (number of planes concurrently in the air) and transitions at a rate of 100/second? 500/second? (what rate is expected at 10k planes? at 100k planes?) For quick/dirty numbers: https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/ says there are 25k planes (round numbers) planes that I think qualify in your pool. > multi-link entities that often have multiple data links operational > simultaneously, > > where each data link connects to a data link service provider network that > may > > know nothing about BGP internally. And, we want to avoid tunneling over the > > low data rate wireless data links themselves. > > > > >I imagine each plane could even maintain more than one live BGP session > with the ground stations, even. It's good to hear that the expected churn > is low, that makes 'plane based bgp' even more >attractive (to me anyway). > > > > No, the aircraft could be moving into and out of service range > dynamically, changing > > their IP addresses frequently, switching between available data links, and > updating > why would you change ip addressing on the plane? having them keep their addressing seems simpler and more conducive to stability, no? > their QoS conditions, e.g., based on signal strength changes. So, there is > a lot going > > on from a mobility standpoint, but the architecture in our doc prevents > that from > > percolating up into BGP. > > > > >Again this still sounds like /2547 mpls vpn/ sorts of stuff, not > something super related to grow's 'global routing (internet focused) > operations' area, is it? > > > > Again, this is a simple BGP arrangement – no RFC2547, no mpls, etc. About > whether > > or not it is related to grow, that’s what we’re here to find out. > > > ok, other folk ought to chime in then. > Thanks - Fred > > > > >in a 2547 sort of scenario (any of the vpn overlays really) the carrier > network doesn't have to know anything at all about the vpn content or > routes. > > > > > > > > > > *From:* Christopher Morrow [mailto:christopher.mor...@gmail.com] > *Sent:* Monday, March 12, 2018 7:16 PM > > *To:* Templin, Fred L <fred.l.temp...@boeing.com> > *Cc:* grow@ietf.org; Saccone, Gregory T <gregory.t.sacc...@boeing.com>; > Gaurav Dawra <gdawra.i...@gmail.com> > *Subject:* Re: [GROW] A Simple BGP-based Mobile Routing System for the > Aeronautical Telecommunications Network > > > > > > > > On Mon, Mar 12, 2018 at 4:59 PM, Templin, Fred L < > fred.l.temp...@boeing.com> wrote: > > Hi Chris, > > > > Thanks for the comments, but no the planes (as Clients) do not do BGP; > > only the ground-domain Servers and Relays do BGP. > > > > Servers are ASBRs for stub ASes and connect to Relays that are ASBRs for > > a core AS in a hub-and-spokes fashion. When a plane contacts a Server, > > it becomes part of that Server’s stub AS. And, because planes do not > > move rapidly from Server to Server, the amount of mobility-related BGP > > update churn as seen by the core AS is dampened. > > > > But, the planes themselves do not participate in BGP, and are therefore > > not mobile ASes. > > > > yup, sure what I was proposing is that they DO participate. > > I could see a world where the plane has a simple BGP instance, and some > orchestration does the equivalent of the mobile cell hand-off for > hand-devices: > "about to leave AS1, start peering with AS2, ... drop peering with AS1" > > > > I imagine each plane could even maintain more than one live BGP session > with the ground stations, even. It's good to hear that the expected churn > is low, that makes 'plane based bgp' even more attractive (to me anyway). > > > > Again this still sounds like /2547 mpls vpn/ sorts of stuff, not > something super related to grow's 'global routing (internet focused) > operations' area, is it? > > in a 2547 sort of scenario (any of the vpn overlays really) the carrier > network doesn't have to know anything at all about the vpn content or > routes. > > > > > > Thanks - Fred > > > > *From:* Christopher Morrow [mailto:christopher.mor...@gmail.com] > *Sent:* Monday, March 12, 2018 12:31 PM > *To:* Templin, Fred L <fred.l.temp...@boeing.com> > *Cc:* grow@ietf.org; Saccone, Gregory T <gregory.t.sacc...@boeing.com>; > Gaurav Dawra <gdawra.i...@gmail.com> > *Subject:* Re: [GROW] A Simple BGP-based Mobile Routing System for the > Aeronautical Telecommunications Network > > > > (as a normal participant) > > > > On Thu, Mar 8, 2018 at 3:14 PM, Templin, Fred L <fred.l.temp...@boeing.com> > wrote: > > Hello, > > We have published a document that proposes BGP as the core of a mobile > routing > service for worldwide civil aviation in the Aeronautical > Telecommunications Network > with Internet Protocol Services (ATN/IPS). This would be an overlay > network deployment > of standard BGP with ASes arranged in such a way as to mitigate the > mobility-related > instability that was inherent in past approaches. The system also > leverages an > adjunct route optimization service known as AERO. > > The ATN/IPS is planned to eventually replace existing air traffic > management services > with an IPv6-based service as part of a long-term evolution. The choice of > mobile > routing services is being made now, with this approach, LISP and Mobile > IPv6 as > candidates. Although the decision is being considered in the International > Civil > Aviation Organization (ICAO), we feel the time is right to socialize the > effort > in the IETF. > > > > Hey, much of this document reads like: > "hey, the global internet is messy, and slowish, we think making our > own bgp domain will make that problem go away" > > > > Followed by what smells a lot like any old RFC2547 MPLS VPN deployment. > I'm not sure I buy the need for 'ip mobility' in a world where the plane > COULD be a BGP speaker and just negotiate upstream connectivity 'in real > time'... but overall this just sounds like any other 2547 deployment to me? > > You'd have to convince your constituent parts that depending upon various > providers 2547 interconnection agreements to work out properly is > sane/useful/cost-effective/not-prone-to-explosion... but ... sure, make a > 2547 network, make the planes do bgp, and orchestrate the add/remove > peerings part across the network as planes move around. > > >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
