< draft-ietf-rtgwg-atn-bgp-11.txt   draft-ietf-rtgwg-atn-bgp-12.txt >
Network Working Group F. Templin, Ed. Network Working Group F. L. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: January 7, 2022 G. Dawra Expires: 5 July 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
July 6, 2021 1 January 2022
A Simple BGP-based Mobile Routing System for the Aeronautical A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network Telecommunications Network
draft-ietf-rtgwg-atn-bgp-11 draft-ietf-rtgwg-atn-bgp-12
Abstract Abstract
The International Civil Aviation Organization (ICAO) is investigating The International Civil Aviation Organization (ICAO) is investigating
mobile routing solutions for a worldwide Aeronautical mobile routing solutions for a worldwide Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS). Telecommunications Network with Internet Protocol Services (ATN/IPS).
The ATN/IPS will eventually replace existing communication services The ATN/IPS will eventually replace existing communication services
with an IPv6-based service supporting pervasive Air Traffic with an IPv6-based service supporting pervasive Air Traffic
Management (ATM) for Air Traffic Controllers (ATC), Airline Management (ATM) for Air Traffic Controllers (ATC), Airline
Operations Controllers (AOC), and all commercial aircraft worldwide. Operations Controllers (AOC), and all commercial aircraft worldwide.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2022. This Internet-Draft will expire on 5 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 21 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The worldwide Air Traffic Management (ATM) system today uses a The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on service known as Aeronautical Telecommunications Network based on
Open Systems Interconnection (ATN/OSI). The service is used to Open Systems Interconnection (ATN/OSI). The service is used to
augment controller to pilot voice communications with rudimentary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
skipping to change at page 3, line 29 skipping to change at page 3, line 28
they are subject to errors, delay, disruption, signal intermittence, they are subject to errors, delay, disruption, signal intermittence,
degradation due to atmospheric conditions, etc. The well-connected degradation due to atmospheric conditions, etc. The well-connected
ground domain ATN/IPS network should therefore treat each safety-of- ground domain ATN/IPS network should therefore treat each safety-of-
flight critical packet produced by (or destined to) an aircraft as a flight critical packet produced by (or destined to) an aircraft as a
precious commodity and strive for an optimized service that provides precious commodity and strive for an optimized service that provides
the highest possible degree of reliability. the highest possible degree of reliability.
The ATN/IPS is an IPv6-based overlay network configured over one or The ATN/IPS is an IPv6-based overlay network configured over one or
more Internetworking underlays ("INETs") maintained by aeronautical more Internetworking underlays ("INETs") maintained by aeronautical
network service providers such as ARINC, SITA and Inmarsat. The network service providers such as ARINC, SITA and Inmarsat. The
overlay provides an Overlay Multilink Network Interface (OMNI) Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni]
virtual link layer [I-D.templin-6man-omni] as a Non-Broadcast, provides a Non-Broadcast, Multiple Access (NBMA) virtual link that
Multiple Access (NBMA) virtual link that spans the entire ATN/IPS. spans the entire ATN/IPS. Each aircraft connects to the OMNI link
Each aircraft connects to the OMNI link via an OMNI interface via an OMNI interface configured over the aircraft's underlying
configured over the aircraft's underlying physical and/or virtual physical and/or virtual access network interfaces.
access network interfaces.
Each underlying INET comprises one or more "partitions" where all Each underlying INET comprises one or more "partitions" where all
nodes within a partition can exchange packets with all other nodes, nodes within a partition can exchange packets with all other nodes,
i.e., the partition is connected internally. There is no requirement i.e., the partition is connected internally. There is no requirement
that any two INET partitions use the same IP protocol version nor that any two INET partitions use the same IP protocol version nor
have consistent IP addressing plans in comparison with other have consistent IP addressing plans in comparison with other
partitions. Instead, the OMNI link sees each partition as a partitions. Instead, the OMNI link sees each partition as a
"segment" of a link-layer topology manifested through a (virtual) "segment" of a link-layer topology concatenated by a service known as
bridging service based on IPv6 encapsulation [RFC2473] known as the the OMNI Adaptation Layer (OAL)
OMNI Adaptation Layer (OAL) [I-D.templin-6man-omni][I-D.templin-6man-aero] based on IPv6
[I-D.templin-6man-omni][I-D.templin-6man-aero]. encapsulation [RFC2473].
The IPv6 addressing architecture provides different classes of The IPv6 addressing architecture provides different classes of
addresses, including Global Unicast Addresses (GUAs), Unique Local addresses, including Global Unicast Addresses (GUAs), Unique Local
Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193].
The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from
an Internet assigned numbers authority, and each aircraft will an Internet assigned numbers authority, and each aircraft will
receive a Mobile Network Prefix (MNP) delegation from the MSP that receive a Mobile Network Prefix (MNP) delegation from the MSP that
accompanies the aircraft wherever it travels. ATCs and AOCs will accompanies the aircraft wherever it travels. ATCs and AOCs will
likewise receive MNPs, but they would typically appear in static (not likewise receive MNPs, but they would typically appear in static (not
mobile) deployments such as air traffic control towers, airline mobile) deployments such as air traffic control towers, airline
skipping to change at page 7, line 49 skipping to change at page 8, line 10
Stub Autonomous System Stub Autonomous System
A logical grouping that includes all Clients currently associated A logical grouping that includes all Clients currently associated
with a given s-ASBR. with a given s-ASBR.
Client Client
An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf
node. The Client could be a singleton host, or a router that node. The Client could be a singleton host, or a router that
connects a mobile or fixed network. connects a mobile or fixed network.
Proxy Proxy/Server
An ANET/INET border node that acts as a transparent intermediary An ANET/INET border node that acts as a transparent intermediary
between Clients and s-ASBRs. From the Client's perspective, the between Clients and s-ASBRs. From the Client's perspective, the
Proxy presents the appearance that the Client is communicating Proxy/Server presents the appearance that the Client is
directly with the s-ASBR. From the s-ASBR's perspective, the communicating directly with the s-ASBR. From the s-ASBR's
Proxy presents the appearance that the s-ASBR is communicating perspective, the Proxy/Server presents the appearance that the
directly with the Client. s-ASBR is communicating directly with the Client.
Mobile Network Prefix (MNP) Mobile Network Prefix (MNP)
An IPv6 prefix that is delegated to any ATN/IPS end system, An IPv6 prefix that is delegated to any ATN/IPS end system,
including ATCs, AOCs, and aircraft. including ATCs, AOCs, and aircraft.
Mobility Service Prefix (MSP) Mobility Service Prefix (MSP)
An aggregated prefix assigned to the ATN/IPS by an Internet An aggregated prefix assigned to the ATN/IPS by an Internet
assigned numbers authority, and from which all MNPs are delegated assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24
MSP). MSP).
skipping to change at page 11, line 31 skipping to change at page 11, line 31
. (::: Partition 3 ::)--|c-ASBR|---+ . . (::: Partition 3 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. ..(etc).. x . . ..(etc).. x .
. . . .
. . . .
. <- ATN/IPS Overlay Bridged by the OAL AS -> . . <- ATN/IPS Overlay Bridged by the OAL AS -> .
. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .
Figure 2: Spanning Partitions with the OAL Figure 2: Spanning Partitions with the OAL
Scaling properties of this ATN/IPS routing system are limited by the Scaling properties of this ATN/IPS routing system are limited by the
number of BGP routes that can be carried by the c-ASBRs. A 2015 number of BGP routes that can be carried by the c-ASBRs. A 2015
study showed that BGP routers in the global public Internet at that study showed that BGP routers in the global public Internet at that
time carried more than 500K routes with linear growth and no signs of time carried more than 500K routes with linear growth and no signs of
router resource exhaustion [BGP]. A more recent network emulation router resource exhaustion [BGP]. A more recent network emulation
study also showed that a single c-ASBR can accommodate at least 1M study also showed that a single c-ASBR can accommodate at least 1M
dynamically changing BGP routes even on a lightweight virtual dynamically changing BGP routes even on a lightweight virtual
machine. Commercially-available high-performance dedicated router machine. Commercially-available high-performance dedicated router
hardware can support many millions of routes. hardware can support many millions of routes.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
configure an Overlay Multilink Network (OMNI) Interface configure an Overlay Multilink Network (OMNI) Interface
[I-D.templin-6man-omni] over their underlying ANET interfaces as a [I-D.templin-6man-omni] over their underlying ANET interfaces as a
connection to an NBMA virtual link (manifested by the OAL) that spans connection to an NBMA virtual link (manifested by the OAL) that spans
the entire ATN/IPS. Clients may further move between ANETs in a the entire ATN/IPS. Clients may further move between ANETs in a
manner that is perceived as a network layer mobility event. Clients manner that is perceived as a network layer mobility event. Clients
could therefore employ a multilink/mobility routing service such as could therefore employ a multilink/mobility routing service such as
those discussed in Section 7. those discussed in Section 7.
Clients register all of their active data link connections with their Clients register all of their active data link connections with their
serving s-ASBRs as discussed in Section 3. Clients may connect to serving s-ASBRs as discussed in Section 3. Clients may connect to
s-ASBRs either directly, or via a Proxy at the ANET/INET boundary. s-ASBRs either directly, or via a Proxy/Server at the ANET/INET
boundary.
Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs
via aviation data links. Clients register their ANET addresses with via aviation data links. Clients register their ANET addresses with
a nearby s-ASBR, where the registration process may be brokered by a a nearby s-ASBR, where the registration process may be brokered by a
Proxy at the edge of the ANET. Proxy/Server at the edge of the ANET.
+-----------------+ +-----------------+
| Client | | Client |
Data Link "A" +-----------------+ Data Link "B" Data Link "A" +-----------------+ Data Link "B"
+----- | OMNI Interface |--------+ +----- | OMNI Interface |--------+
/ +-----------------+ \ / +-----------------+ \
/ \ / \
/ \ / \
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+-------+ +-------+ +-------+ +-------+
... | Proxy | ............................ | Proxy | ... ... | P/S | ............................ | P/S | ...
. +-------+ +-------+ . . +-------+ +-------+ .
. ^^ ^^ . . ^^ ^^ .
. || || . . || || .
. || +--------+ || . . || +--------+ || .
. ++============> | s-ASBR | <============++ . . ++============> | s-ASBR | <============++ .
. +--------+ . . +--------+ .
. | eBGP . . | eBGP .
. (:::)-. . . (:::)-. .
. .-(::::::::) . . .-(::::::::) .
. .-(::: ATN/IPS :::)-. . . .-(::: ATN/IPS :::)-. .
skipping to change at page 13, line 39 skipping to change at page 13, line 39
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 3: ATN/IPS ANET Architecture Figure 3: ATN/IPS ANET Architecture
When a Client logs into an ANET it specifies a nearby s-ASBR that it When a Client logs into an ANET it specifies a nearby s-ASBR that it
has selected to connect to the ATN/IPS. The login process is has selected to connect to the ATN/IPS. The login process is
transparently brokered by a Proxy at the border of the ANET which transparently brokered by a Proxy/Server at the border of the ANET
then conveys the connection request to the s-ASBR via tunneling which then conveys the connection request to the s-ASBR via tunneling
across the OMNI virtual link. Each ANET border Proxy is also equally across the OMNI virtual link. Each ANET border Proxy/Server is also
capable of serving in the s-ASBR role so that a first on-link Proxy equally capable of serving in the s-ASBR role so that a first on-link
can be selected as the s-ASBR while all others perform the Proxy role Proxy/Server can be selected as the s-ASBR while all others perform
in a hub-and-spokes arrangement. An on-link Proxy is selected to the Proxy/Server role in a hub-and-spokes arrangement. An on-link
serve the s-ASBR role when it receives a control message from a Proxy/Server is selected to serve the s-ASBR role when it receives a
Client requesting that service. control message from a Client requesting that service.
A network-based s-ASBR can also be selected when the ANET does not The Client can coordinate with a network-based s-ASBR over additional
provide a Proxy, or when a different ANET Proxy has already been ANETs after it has already coordinated with a first-hop Proxy/Server
selected. Selection of a network-based s-ASBR could be through an over a first ANET. Selection of a network-based s-ASBR could be
address discovered through a first ANET Proxy, through consulting a through an address discovered through a first ANET Proxy/Server,
geographically-keyed static host file, through a DNS lookup, through through consulting a geographically-keyed static host file, through a
a network query response, etc. The s-ASBR then registers the address DNS lookup, through a network query response, etc. The s-ASBR then
of the Proxy as the address for the Client, and the Proxy forwards registers the addresses of the additional ANET Proxy/Server as the
the s-ASBR's reply to the Client. If the Client connects to multiple address for the Client over each distinct Client interface. If the
ANETs, the s-ASBR will register the addresses of all Proxies as Client connects to multiple ANETs, the s-ASBR will register the
addresses through which the Client can be reached. addresses of all Proxy/Servers as addresses through which the Client
can be reached.
The s-ASBR represents all of its active Clients as MNP-ULA routes in The s-ASBR represents all of its active Clients as MNP-ULA routes in
the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore
consists of the set of all of its active Clients (i.e., the stub AS consists of the set of all of its active Clients (i.e., the stub AS
is a logical construct and not a physical construct). The s-ASBR is a logical construct and not a physical construct). The s-ASBR
injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs
of its departed Clients via BGP updates to c-ASBRs, which further of its departed Clients via BGP updates to c-ASBRs, which further
propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since
Clients are expected to remain associated with their current s-ASBR Clients are expected to remain associated with their current s-ASBR
for extended periods, the level of MNP-ULA injections and withdrawals for extended periods, the level of MNP-ULA injections and withdrawals
skipping to change at page 15, line 14 skipping to change at page 15, line 14
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
... | Proxy1 | .......................... | Proxy2 | ... ... | P/S-1 | .......................... | P/S-2 | ...
. +--------+ +--------+ . . +--------+ +--------+ .
. ** ** . . ** ** .
. ** ** . . ** ** .
. ** ** . . ** ** .
. +---------+ +---------+ . . +---------+ +---------+ .
. | s-ASBR1 | | s-ASBR2 | . . | s-ASBR1 | | s-ASBR2 | .
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ ** Dogleg ** / . . \ ** Dogleg ** / .
. eBGP\ ** Route ** /eBGP . . eBGP\ ** Route ** /eBGP .
. \ **==============** / . . \ **==============** / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 4: Dogleg Route Before Optimization Figure 4: Dogleg Route Before Optimization
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
... | Proxy1 | .......................... | Proxy2 | ... ... | P/S-1 | .......................... | P/S-2 | ...
. +------v-+ +--^-----+ . . +------v-+ +--^-----+ .
. * * . . * * .
. *================================* . . *================================* .
. . . .
. +---------+ +---------+ . . +---------+ +---------+ .
. | s-ASBR1 | | s-ASBR2 | . . | s-ASBR1 | | s-ASBR2 | .
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ / . . \ / .
. eBGP\ /eBGP . . eBGP\ /eBGP .
. \ / . . \ / .
skipping to change at page 20, line 23 skipping to change at page 20, line 29
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
12.2. Informative References 12.2. Informative References
[ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground
Interface for Civil Aviation, IETF Liaison Statement Interface for Civil Aviation, IETF Liaison Statement
#1676, https://datatracker.ietf.org/liaison/1676/", March #1676, https://datatracker.ietf.org/liaison/1676/", 3
2020. March 2020.
[ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the
Aeronautical Telecommunication Network (ATN) using Aeronautical Telecommunication Network (ATN) using
Internet Protocol Suite (IPS) Standards and Protocol), Internet Protocol Suite (IPS) Standards and Protocol),
Draft Edition 3 (work-in-progress)", December 2020. Draft Edition 3 (work-in-progress)", 10 December 2020.
[BGP] Huston, G., "BGP in 2015, http://potaroo.net", January [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January
2016. 2016.
[BGP2] Huston, G., "BGP Instability Report, [BGP2] Huston, G., "BGP Instability Report,
http://bgpupdates.potaroo.net/instability/bgpupd.html", http://bgpupdates.potaroo.net/instability/bgpupd.html",
May 2017. May 2017.
[CBB] Dul, A., "Global IP Network Mobility using Border Gateway [CBB] Dul, A., "Global IP Network Mobility using Border Gateway
Protocol (BGP), http://www.quark.net/docs/ Protocol (BGP), http://www.quark.net/docs/
Global_IP_Network_Mobility_using_BGP.pdf", March 2006. Global_IP_Network_Mobility_using_BGP.pdf", March 2006.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)", Cabellos, "The Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-rfc6830bis-36 (work in progress), November Work in Progress, Internet-Draft, draft-ietf-lisp-
2020. rfc6830bis-36, 18 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6830bis-36.txt>.
[I-D.templin-6man-aero] [I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization Templin, F. L., "Automatic Extended Route Optimization
(AERO)", draft-templin-6man-aero-01 (work in progress), (AERO)", Work in Progress, Internet-Draft, draft-templin-
April 2021. 6man-aero-37, 15 November 2021,
<https://www.ietf.org/archive/id/draft-templin-6man-aero-
37.txt>.
[I-D.templin-6man-omni] [I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets Templin, F. L. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft- over Overlay Multilink Network (OMNI) Interfaces", Work in
templin-6man-omni-03 (work in progress), April 2021. Progress, Internet-Draft, draft-templin-6man-omni-51, 15
November 2021, <https://www.ietf.org/archive/id/draft-
templin-6man-omni-51.txt>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
skipping to change at page 22, line 9 skipping to change at page 22, line 30
routing system is still undergoing reconvergence. Therefore, as long routing system is still undergoing reconvergence. Therefore, as long
as the Client associates with the new s-ASBR before it departs from as the Client associates with the new s-ASBR before it departs from
the old s-ASBR (while informing the old s-ASBR of its new location) the old s-ASBR (while informing the old s-ASBR of its new location)
packets in flight during the BGP reconvergence window are packets in flight during the BGP reconvergence window are
accommodated without loss. accommodated without loss.
Appendix B. Change Log Appendix B. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -10 to -11: Differences from earlier versions:
o Introduced notion of the spanning tree
o Discussed Proxy/s-ASBR arrangement options.
Changes from -05 to -06:
o OMNI interface introduced
o Version and reference update.
Changes from -04 to -05:
o Version and reference update.
Changes from -03 to -04:
o added discussion of Bidirectional Forwarding Detection (BFD).
Changes from -02 to -03:
o added reference to ICAO A/G interface specification.
Changes from -01 to -02:
o introduced the SPAN and the concept of Internetwork partitioning
o new terms "ANET" (for (Radio) Access Network) and "INET" (for
Internetworking underlay)
o new appendix on BGP convergence considerations
Changes from -00 to -01:
o incorporated clarifications due to list comments and questions.
o new section 7 on Stub AS Mobile Routing Services
o updated references, and included new reference for MIPv6 and LISP
Status as of 08/30/2018:
o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' * Submit for RFC publication.
Authors' Addresses Authors' Addresses
Fred L. Templin (editor) Fred L. Templin (editor)
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA United States of America
Email: fltemplin@acm.org Email: fltemplin@acm.org
Greg Saccone Greg Saccone
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA United States of America
Email: gregory.t.saccone@boeing.com Email: gregory.t.saccone@boeing.com
Gaurav Dawra Gaurav Dawra
LinkedIn LinkedIn
USA United States of America
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Acee Lindem Acee Lindem
Cisco Systems, Inc. Cisco Systems, Inc.
USA United States of America
Email: acee@cisco.com Email: acee@cisco.com
Victor Moreno Victor Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
USA United States of America
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
 End of changes. 35 change blocks. 
116 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/