< draft-ietf-rtgwg-atn-bgp-07.txt   draft-ietf-rtgwg-atn-bgp-08.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: June 20, 2021 G. Dawra Expires: June 21, 2021 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
December 17, 2020 December 18, 2020
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-07 draft-ietf-rtgwg-atn-bgp-08
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 June 20, 2021. This Internet-Draft will expire on June 21, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 11 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 13 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 15 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 16 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 20 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 21
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 30 skipping to change at page 3, line 30
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 provides an Overlay Multilink Network Interface (OMNI)
virtual link layer as discussed in [I-D.templin-6man-omni-interface]. virtual link layer [I-D.templin-6man-omni-interface] as a Non-
Each aircraft connects to the OMNI link via an OMNI Interface
configured over the aircraft's underlying physical and/or virtual
access network interfaces. The OMNI interface connects to a Non-
Broadcast, Multiple Access (NBMA) virtual link that spans the entire Broadcast, Multiple Access (NBMA) virtual link that spans the entire
ATN/IPS. ATN/IPS. Each aircraft connects to the OMNI link via an OMNI
interface configured over the aircraft's underlying physical and/or
virtual 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 manifested through a (virtual)
bridging service based on IPv6 encapsulation [RFC2473] known as the bridging service based on IPv6 encapsulation [RFC2473] known as the
OMNI Adaptation Layer (OAL). Further discussion of the OAL is found OMNI Adaptation Layer (OAL)
in the following sections of this document, with reference to
[I-D.templin-6man-omni-interface][I-D.templin-intarea-6706bis]. [I-D.templin-6man-omni-interface][I-D.templin-intarea-6706bis].
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
headquarters, etc. The OAL conversely uses ULAs in the source and headquarters, etc.
destination addresses of IPv6 encapsulation headers. Each ULA
includes an MNP in the interface identifier as discussed in The OAL uses ULAs in the source and destination addresses of IPv6
[I-D.templin-6man-omni-interface], and the BGP routing services encapsulation headers. Each ULA includes an MNP in the interface
performs forwarding based on these "MNP-ULAs" instead of based on the identifier ("MNP-ULA") as discussed in
MNPs themselves. [I-D.templin-6man-omni-interface]. Due to MNP delegation policies
and random MN mobility properties, MNP-ULAs are generally not
aggregatable in the BGP routing service. In addition, OMNI link
service nodes configure administratively-assigned ULAs ("ADM-ULA")
that are statically-assigned and derived from a shorter ADM-ULA
prefix assigned to their OMNI link partition
[I-D.templin-6man-omni-interface]. Unlike MNP-ULAs, the ADM-ULAs are
persistently present and unchanging in the routing system. The BGP
routing services therefore perform forwarding based on these MNP-ULAs
and ADM-ULAs instead of based on the GUA MNPs themselves.
Connexion By Boeing [CBB] was an early aviation mobile routing Connexion By Boeing [CBB] was an early aviation mobile routing
service based on dynamic updates in the global public Internet BGP service based on dynamic updates in the global public Internet BGP
routing system. Practical experience with the approach has shown routing system. Practical experience with the approach has shown
that frequent injections and withdrawals of prefixes in the Internet that frequent injections and withdrawals of prefixes in the Internet
routing system can result in excessive BGP update messaging, slow routing system can result in excessive BGP update messaging, slow
routing table convergence times, and extended outages when no route routing table convergence times, and extended outages when no route
is available. This is due to both conservative default BGP protocol is available. This is due to both conservative default BGP protocol
timing parameters (see Section 6) and the complex peering timing parameters (see Section 6) and the complex peering
interconnections of BGP routers within the global Internet interconnections of BGP routers within the global Internet
skipping to change at page 5, line 23 skipping to change at page 5, line 30
simple routing model therefore greatly reduces the number of BGP simple routing model therefore greatly reduces the number of BGP
updates that need to be synchronized among peers, and the number is updates that need to be synchronized among peers, and the number is
reduced further still when intradomain routing changes within stub reduced further still when intradomain routing changes within stub
ASes are processed within the AS instead of being propagated to the ASes are processed within the AS instead of being propagated to the
core. BGP Route Reflectors (RRs) [RFC4456] can also be used to core. BGP Route Reflectors (RRs) [RFC4456] can also be used to
support increased scaling properties. support increased scaling properties.
When there are multiple INET partitions, the c-ASBRs of each When there are multiple INET partitions, the c-ASBRs of each
partition use eBGP to peer with the c-ASBRs of other partitions so partition use eBGP to peer with the c-ASBRs of other partitions so
that the full set of ULAs for all partitions are known globally among that the full set of ULAs for all partitions are known globally among
all of the c-ASBRs. Each c/s-ASBR further configures an all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA
administratively-assigned "ADM-ULA" (see: which is taken from a ADM-ULA prefix assigned to each partition, as
[I-D.templin-6man-omni-interface]) which is taken from a ADM-ULA well as static forwarding table entries for all other OMNI link
prefix assigned to each partition, as well as static forwarding table partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL
entries for all other OMNI link partition prefixes. Both ADM-ULAs for nested encapsulation where the inner IPv6 packet is encapsulated
and MNP-ULAs are used by the OAL for nested encapsulation where the in an IPv6 OAL header with ULA source and destination addresses,
inner IPv6 packet is encapsulated in an IPv6 OAL header with ULA which is then encapsulated in an IP header specific to the INET
source and destination addresses, which is then encapsulated in an IP partition.
header specific to the INET partition.
The remainder of this document discusses the proposed BGP-based ATN/ The remainder of this document discusses the proposed BGP-based ATN/
IPS mobile routing service. IPS mobile routing service.
2. Terminology 2. Terminology
The terms Autonomous System (AS) and Autonomous System Border Router The terms Autonomous System (AS) and Autonomous System Border Router
(ASBR) are the same as defined in [RFC4271]. (ASBR) are the same as defined in [RFC4271].
The following terms are defined for the purposes of this document: The following terms are defined for the purposes of this document:
skipping to change at page 6, line 39 skipping to change at page 6, line 46
partition (or "segment") partition (or "segment")
A fully-connected internal subnetwork of an INET in which all A fully-connected internal subnetwork of an INET in which all
nodes can communicate with all other nodes within the same nodes can communicate with all other nodes within the same
partition using the same IP protocol version and addressing plan. partition using the same IP protocol version and addressing plan.
Each INET consists of one or more partitions. Each INET consists of one or more partitions.
Overlay Multilink Network Interface (OMNI) Overlay Multilink Network Interface (OMNI)
A virtual layer 2 bridging service that presents an ATN/IPS A virtual layer 2 bridging service that presents an ATN/IPS
overlay unified link view even though the underlay may consist of overlay unified link view even though the underlay may consist of
multiple INET partitions. The OMNI virtual link is manifested multiple INET partitions. The OMNI virtual link is manifested
through nested encapsulation in which GUA-addessed IPv6 packets through nested encapsulation in which GUA-addressed IPv6 packets
from the ATN/IPS are first encapsulated in ULA-addressed IPv6 from the ATN/IPS are first encapsulated in ULA-addressed IPv6
headers which are then forwarded to the next hop using INET headers which are then forwarded to the next hop using INET
encapsulation if necessary. Forwarding over the OMNI virtual link encapsulation if necessary. Forwarding over the OMNI virtual link
is therefore based on ULAs instead of GUAs. In this way, packets is therefore based on ULAs instead of GUAs. In this way, packets
sent from a source can be conveyed over the OMNI virtual link even sent from a source can be conveyed over the OMNI virtual link even
though there may be many underlying INET partitions in the path to though there may be many underlying INET partitions in the path to
the destination. the destination.
OMNI Adaptation Layer (OAL) OMNI Adaptation Layer (OAL)
A middle layer below the IPv6 layer but above the INET layer that A middle layer below the IPv6 layer but above the INET layer that
skipping to change at page 8, line 18 skipping to change at page 8, line 24
coordinated in an overlay network via tunnels between neighboring coordinated in an overlay network via tunnels between neighboring
ASBRs over one or more underlying INETs. The overlay does not ASBRs over one or more underlying INETs. The overlay does not
interact with the underlying INET BGP routing systems, and only a interact with the underlying INET BGP routing systems, and only a
small and unchanging set of MSPs are advertised externally instead of small and unchanging set of MSPs are advertised externally instead of
the full dynamically changing set of MNPs. the full dynamically changing set of MNPs.
Within each INET partition, one or more s-ASBRs connect each stub AS Within each INET partition, one or more s-ASBRs connect each stub AS
to the INET partition core using a shared stub AS Number (ASN). Each to the INET partition core using a shared stub AS Number (ASN). Each
s-ASBR further uses eBGP to peer with one or more c-ASBRs. All s-ASBR further uses eBGP to peer with one or more c-ASBRs. All
c-ASBRs are members of the INET partition core AS, and use a shared c-ASBRs are members of the INET partition core AS, and use a shared
core ASN. Globally-unique public ASNs could be assigned, e.g., core ASN. Unique ASNs are assigned according to the standard 16-bit
either according to the standard 16-bit ASN format or the 32-bit ASN ASN format [RFC4271], where each ASBR assigns an ASN that matches its
scheme defined in [RFC6793]. ADM-ULA suffix.
The c-ASBRs use iBGP to maintain a synchronized consistent view of The c-ASBRs use iBGP to maintain a synchronized consistent view of
all active MNP-ULAs currently in service within the INET partition. all active MNP-ULAs currently in service within the INET partition.
Figure 1 below represents the reference INET partition deployment. Figure 1 below represents the reference INET partition deployment.
(Note that the figure shows details for only two s-ASBRs (s-ASBR1 and (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and
s-ASBR2) due to space constraints, but the other s-ASBRs should be s-ASBR2) due to space constraints, but the other s-ASBRs should be
understood to have similar Stub AS, MNP and eBGP peering understood to have similar Stub AS, MNP and eBGP peering
arrangements.) The solution described in this document is flexible arrangements.) The solution described in this document is flexible
enough to extend to these topologies. enough to extend to these topologies.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
destined to all other MNP-ULAs will correctly incur ICMPv6 destined to all other MNP-ULAs will correctly incur ICMPv6
Destination Unreachable messages [RFC4443] due to the black hole Destination Unreachable messages [RFC4443] due to the black hole
route. (This is the same behavior as for ordinary BGP routers in the route. (This is the same behavior as for ordinary BGP routers in the
Internet when they receive packets for which there is no route Internet when they receive packets for which there is no route
available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to
s-ASBRs, but instead originate a default route. In this way, s-ASBRs s-ASBRs, but instead originate a default route. In this way, s-ASBRs
have only partial topology knowledge (i.e., they know only about the have only partial topology knowledge (i.e., they know only about the
active MNP-ULAs currently within their stub ASes) and they forward active MNP-ULAs currently within their stub ASes) and they forward
all other packets to c-ASBRs which have full topology knowledge. all other packets to c-ASBRs which have full topology knowledge.
Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable
within an INET partition, and each partition configures a unique ADM-
ULA prefix that is permanently announced into the routing system.
The core ASes of each INET partition are joined together through The core ASes of each INET partition are joined together through
external BGP peerings. The c-ASBRs of each partition establish external BGP peerings. The c-ASBRs of each partition establish
external peerings with the c-ASBRs of other partitions to form a external peerings with the c-ASBRs of other partitions to form a
"core-of-cores" OAL AS. The OAL AS contains the global knowledge of "core-of-cores" OMNI link AS. The OMNI link AS contains the global
all MNP-ULAs deployed worldwide, and supports ATN/IPS overlay knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS
communications between nodes located in different INET partitions by overlay communications between nodes located in different INET
virtue of OAL encapsulation. Figure 2 shows a reference OAL partitions by virtue of OAL encapsulation. OMNI link nodes can then
topology. navigate to ASBRs by including an ADM-ULA or directly to an end
system by including an MNP-ULA in the destination address of an OAL-
encapsulated packet (see: [I-D.templin-intarea-6706bis]) . Figure 2
shows a reference OAL topology.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. .-(::::::::) . . .-(::::::::) .
. .-(::::::::::::)-. +------+ . . .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ . . (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. .-(::::::::) | . . .-(::::::::) | .
skipping to change at page 16, line 42 skipping to change at page 17, line 42
Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with
the ATN/IPS unicast IPv6 routes resolving over INET routes. the ATN/IPS unicast IPv6 routes resolving over INET routes.
Consequently, c-ASBRs and potentially s-ASBRs will need to support Consequently, c-ASBRs and potentially s-ASBRs will need to support
separate local ASes for the two BGP routing domains and routing separate local ASes for the two BGP routing domains and routing
policy or assure routes are not propagated between the two BGP policy or assure routes are not propagated between the two BGP
routing domains. From a conceptual and operational standpoint, the routing domains. From a conceptual and operational standpoint, the
implementation should provide isolation between the two BGP routing implementation should provide isolation between the two BGP routing
domains (e.g., separate BGP instances). domains (e.g., separate BGP instances).
ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random
40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit
OMNI link identifier '*' to form the prefix [ULA*]::/64. Each
individual address taken from [ULA*]::/64 includes additional routing
information in the interface identifier. For example, for the MNP
2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120,
and for the administrative address 1001/8 the ADM-ULA is
[ULA*]::1001/120 (see: [I-D.templin-6man-omni-interface] for further
details). This gives rise to a BGP routing system that must
accommodate large numbers of long and non-aggregatable MNP-ULA
prefixes as well as moderate numbers of long and semi-aggregatable
ADM-ULA prefixes. The system is kept stable and scalable through the
s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility-
related churn is not exposed to the core.
7. Stub AS Mobile Routing Services 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling clients, and are responsible for all localized mobility signaling
without disturbing the BGP routing system. Clients can enlist the without disturbing the BGP routing system. Clients can enlist the
services of a candidate mobility service such as Mobile IPv6 (MIPv6) services of a candidate mobility service such as Mobile IPv6 (MIPv6)
[RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO
[I-D.templin-intarea-6706bis] according to the service offered by the [I-D.templin-intarea-6706bis] according to the service offered by the
stub AS. Further details of mobile routing services are out of scope stub AS. Further details of mobile routing services are out of scope
for this document. for this document.
 End of changes. 16 change blocks. 
50 lines changed or deleted 76 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/