Re: Extending a /64 (The most welcome comment)

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

Hi Tony,

> -----Original Message-----
> From: Tony Whyman [mailto:[e-mail]]
> Sent: Thursday, November 19, 2020 12:42 AM
> To: Templin (US), Fred L <[e-mail]>; Brian E Carpenter <[e-mail]>; [e-mail]
> Subject: Re: Extending a /64 (The most welcome comment)
> 
> On 18/11/2020 22:27, Templin (US), Fred L wrote:
> > Brian,
> >
> >> How about an ops Area draft describing how the proposal works with BGP4 and how many new BGP routes it will create?
> > I am not well liked in ops, but if Tony is up for another document and has
> > enjoyed the IETF "ride" thus far sure why not. What do you think, Tony?
> >
> > Fred
> 
> Fred,
> 
> Not sure if I really understand the question. As we both know, BGP
> routes to mobiles are not readily aggregatable. They are also subject to
> an unusually high rate of change resulting in potential forwarding table
> volatility. If you go down the BGP path then some sort of containment
> strategy is required, as you have specified for AERO and which itself
> draws on the way the ATN/OSI works with IDRP routes. Outside the
> containment area only a highly aggregated route to all mobiles is ever
> advertised.

AERO/OMNI have benefitted immeasurably from the ICAO WG-I input
(yourself in particular), but the BGP arrangement is something that was
already in my specs before I entered the aviation fray - see RFC6179.
That it may resemble the way ATN/OSI works with IDRP is something
I was not aware of, but probably a good thing.

> Alternatively, Mobile IP avoids the problem by aggregating mobile routes
> effectively within the Home Agent and advertising only an aggregated
> route to some collective Home Network. A LISP based approach does not
> even work with BGP in the EID-space, although an xTR Proxy might
> advertise a highly aggregated route to all mobiles to the wider internet.
> 
> As for the "ride" - next time I'll confine myself to the simpler problem
> of delivering World Peace.

Indeed. We can talk about this off-list.

Fred

> Tony
> 
> 
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: Wednesday, November 18, 2020 2:20 PM
> >> To: Templin (US), Fred L <[e-mail]>; Tony Whyman <[e-mail]>; [e-mail]
> >> Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
> >>
> >> Fred,
> >>
> >> My concern isn't about what happens inside the ICAO limited domain. What you say makes complete sense there. It's about how
> >> these prefixes (fail to) aggregate in what we used to call the default-free zone. (RFC1888 probably would have had that problem
> too,
> >> but as far as I know, nobody ever implemented it.) If there was a bgpops WG, that would be the place to discuss it.
> >>
> >> If the plan creates a new DFZ route for each airline, that's a negligible number in the BGP4 context. If it creates a new DFZ route for
> >> each aircraft, that could be problematic.
> >>
> >> How about an ops Area draft describing how the proposal works with BGP4 and how many new BGP routes it will create?
> >>
> >> Regards
> >>     Brian
> >>
> >> On 19-Nov-20 10:27, Templin (US), Fred L wrote:
> >>> Brian, there will be many non-airplane users of the ATN/IPS top-level IPv6 prefix
> >>> allocation - often in fixed and non-mobile environments - and we can expect them
> >>> to conform to CIDR conventions. We are only talking here about the airplanes,
> >>> which are always mobile and always away from "home".
> >>>
> >>> I have shown how we can route their prefixes using scalable de-aggregation,
> >>> and you seemed to concur. So, why can't we tolerate a 24-bit portion of the
> >>> airplane's prefix that does not come from a strict CIDR hierarchy?
> >>>
> >>> Fred
> >>>
> >>>> -----Original Message-----
> >>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> >>>> Sent: Wednesday, November 18, 2020 12:10 PM
> >>>> To: Tony Whyman <[e-mail]>; [e-mail]
> >>>> Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
> >>>>
> >>>> Tony,
> >>>>
> >>>> I don't like the argument that people are arguing for either "purity"
> >>>> or "perfection". That is not the issue. The issue is doing something
> >>>> that matches how IPv6 wide-area routing actually works, and that is
> >>>> by CIDRised prefix allocation.
> >>>>
> >>>> Now you have peeled back the onion to this point:
> >>>>
> >>>>> we have to have an addressing plan (for
> >>>>> aircraft) that is canonical with the existing NSAP Address.
> >>>> I understand that as a perceived requirement; it's more or less why
> >>>> we wrote RFC1888, although mapping US GOSIP addresses was the target
> >>>> then. I don't know how the ICAO lays out its NSAPA addresses, but I
> >>>> imagine that the aircraft ID is towards the low-order bits?
> >>>> That's where it should be in an IPv6 address, IMNSHO.
> >>>>
> >>>> The current proposal seems to be limited to 16 subnets on an
> >>>> aircraft and that is highly likely to come back and bite you.
> >>>>
> >>>> Regards
> >>>>     Brian Carpenter
> >>>>
> >>>> On 18-Nov-20 22:33, Tony Whyman wrote:
> >>>>> On 18/11/2020 03:30, Michael Richardson wrote:
> >>>>>> When we designed IPv6, we assumed that everyone would get some, even if they
> >>>>>> didn't connect.
> >>>>>>
> >>>>>>       > ULAs only have the first property.
> >>>>>>       > If a device doesn't need the second property, the device doesn't need a GUA.
> >>>>>>
> >>>>>> Again, what is this business of trying to ration IPv6?
> >>>>>> Do they really need 39 bits? I don't know.
> >>>>>>
> >>>>>> Our entire Ipv6 architecture ENCOURAGES entities to ask for the amount of space
> >>>>>> that they think they might need over the lifetime of their effort and NEVER
> >>>>>> COME BACK for more.
> >>>>>>
> >>>>>> That's why /64 for IIDs, and /48s for every site.
> >>>>> If there is another edition of RFC 8200 then the sentence beginning "Our
> >>>>> entire.." should be copied to the front page of the new edition. Yes, we
> >>>>> all get the idea that addressing plans should be as elegant as possible
> >>>>> - but IPv4-think should have no place in this. But, perhaps the most
> >>>>> important notion that comes through in the above is that each industry
> >>>>> ultimately knows best when it comes to the compromises that have to be
> >>>>> made to create an industry specific addressing plan.
> >>>>>
> >>>>> Over the last few days, I have been happy to try and peel away the
> >>>>> issues that lay behind our proposed IPv6 addressing plan and to use it
> >>>>> as an opportunity to spread understanding of the ATN/IPS and the
> >>>>> constraints under which we are working. However, there is one point that
> >>>>> it seems to be too difficult for some to get their head around and that
> >>>>> is that we are not starting with a "clean sheet of paper". We have to
> >>>>> respect the constraints that we have and sometimes arguably poor
> >>>>> decisions that were made in the past and the result is a compromise. It
> >>>>> will offend those who demand purity - but purity is not the objective.
> >>>>> The objective is to deploy a working IPv6 based system.
> >>>>>
> >>>>> In the ICAO Working Groups, we are writing the 3rd edition of the
> >>>>> ATN/IPS Manual. There were two earlier versions and both represent
> >>>>> failed attempts to deliver an IPS based ATN. They failed - not
> >>>>> necessarily for technical reasons - but because there was no business
> >>>>> case. This is a very hard nosed industry and, unless its use is
> >>>>> commanded by regulation, if a new technology does not deliver more
> >>>>> passengers or raise the profit/passenger then it ain't going to happen.
> >>>>>
> >>>>> Even now, I am hard pressed to see any business case for an ATN/IPS
> >>>>> replacing the venerable ATN/OSI. The ATN/OSI is a CLNP overlay on top of
> >>>>> an IPv4 network, it works, with some limitations, and will support the
> >>>>> current generation of applications. With nugatory upgrades it could
> >>>>> support the next generation. Some might point to presumed cost savings
> >>>>> by replacing CLNP with something that is industry mainstream - but the
> >>>>> truth is that the CLNP bits are, by and large, in systems that perform
> >>>>> functions that are unique to civil aviation, while the rest is catalogue
> >>>>> item routers.
> >>>>>
> >>>>> However, looking to the long term, it will be increasingly difficult to
> >>>>> develop new applications on the ATN/OSI base and we should seize the
> >>>>> first opportunity that we can find to move on to an ATN/IPS.
> >>>>>
> >>>>> A funding window has opened up with the European Space Agency (ESA) and
> >>>>> the EU's SESAR research programme putting in the funds to develop a
> >>>>> prototype SATCOM service for the ATN/IPS. This should just about extend
> >>>>> to cover initial avionics on a single aircraft type (different
> >>>>> generations of aircraft have different communication architectures and
> >>>>> everything has to be type approved before it can be used). The funding
> >>>>> should also cover a protocol gateway allowing the prototype to interwork
> >>>>> with ATC Centres i.e. to at least demonstrate an operational service
> >>>>> using the ATN/IPS.
> >>>>>
> >>>>> Even stretching the funding envelope this far is optimistic. Adding in
> >>>>> anything else like a new registration scheme for aircraft and lookup
> >>>>> tables in the protocol gateway will kill the project financially. Yes, I
> >>>>> know that these are not technically difficult, but when you work in an
> >>>>> environment where every new function has to be subject to a hazard
> >>>>> analysis, a safety case, a high end develop lifecycle and rigorous
> >>>>> testing then, what looks like a simple function on paper, quickly gets
> >>>>> replaced by a dollar sign followed by lots of digits.
> >>>>>
> >>>>> To keep this project feasible, we have to have an addressing plan (for
> >>>>> aircraft) that is canonical with the existing NSAP Address. You may
> >>>>> prefer purity and demand that we have a perfect addressing plan. But you
> >>>>> are not helping.
> >>>>>
> >>>>> Our goal is to get a working ATN/IPS on to a single aircraft type with
> >>>>> minimum change to the existing system. Once this has been demonstrated
> >>>>> to be feasible and "industry mainstream" then the case can be made for
> >>>>> rolling it out to other aircraft types and, may be, one day, even the
> >>>>> ATC Centre's will get upgraded - but that will probably have wait until
> >>>>> a new application provides the business case.
> >>>>>
> >>>>> Perhaps another aphorism that could be put on the front page of a future
> >>>>> version of RFC 8200 is "never let the perfect be the enemy of the good".
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Tony Whyman, MWA
> >>>>>
> >>>>> PS: we could always declare the ATN as a closed network and use our own
> >>>>> addressing plan - but does not help make the "industry mainstream" case,
> >>>>> does it.
> >>>>>
> >>>>> --------------------------------------------------------------------
> >>>>> IETF IPv6 working group mailing list
> >>>>> [e-mail]
> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>>>
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> [e-mail]
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>> .
> >>>
> >