draft-ietf-babel-source-specific-01.txt   draft-ietf-babel-source-specific-02.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Updates: 6126bis (if approved) IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Intended status: Standards Track August 21, 2017 Expires: July 24, 2018 January 20, 2018
Expires: February 22, 2018
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-01 draft-ietf-babel-source-specific-02
Abstract Abstract
Source-specific routing is an extension to traditional next-hop Source-specific routing (also known as Source-Address Dependent
routing where packets are forwarded according to both their Routing, SADR) is an extension to traditional next-hop routing where
destination and their source address. This document describes the packets are forwarded according to both their destination and their
source-specific routing extension to the Standard Track's Babel source address. This document describes an extension for source-
routing protocol defined in [BABEL]. It is incompatible with the specific routing to the Babel routing protocol.
Experimental Track's Babel [RFC6126].
Source-specific routing is also known as Source Address Dependent
Routing, SAD Routing, SADR, Destination/Source Routing or Source/
Destination Routing.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 22, 2018. This Internet-Draft will expire on July 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. Introduction and background . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3
3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4
4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Source-specific messages . . . . . . . . . . . . . . . . 6 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 6 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6
5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 6
5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility with the base protocol . . . . . . . . . . . . 7 6. Compatibility with the base protocol . . . . . . . . . . . . 7
6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 7
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security considerations . . . . . . . . . . . . . . . . . . . 9 9. Security considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. TODOs 1. Introduction and background
o Source Prefix sub-TLV type: TBD
o check references (Section) for BABEL in 6126bis
2. Introduction and background
The Babel routing protocol as defined is [BABEL] is a distance vector The Babel routing protocol [BABEL] is a distance vector routing
routing protocol for next-hop routing. In next-hop routing, each protocol for next-hop routing. In next-hop routing, each node
node maintains a forwarding table which maps prefixes to next-hops. maintains a forwarding table which maps destination prefixes to next
The forwarding decision is a per-packet operation which depends on hops. The forwarding decision is a per-packet operation which
the destination address of the packets and on the entries of the depends on the destination address of the packets and on the entries
forwarding table. When a packet is about to be routed, its of the forwarding table. When a packet is about to be routed, its
destination address is compared to the prefixes of the routing table: destination address is compared to the prefixes of the routing table:
the entry with the most specific prefix containing the destination the entry with the most specific prefix containing the destination
address of the packet is choosen, and the packet is forwarded to the address of the packet is chosen, and the packet is forwarded to the
associated next-hop. Next-hop routing is a simple, well understood associated next-hop. Next-hop routing is a simple, well understood
paradigm that works satisfactorily in a large number of cases. paradigm that works satisfactorily in a large number of cases.
Source-specific routing is a modest extension of next-hop routing Source-specific routing [SS-ROUTING], or Source Address Dependent
where the forwarding decision additionnaly depends on the source Routing (SADR) [DSR], is a modest extension to next-hop routing where
address of the packets. The forwarding tables are extended to map the forwarding decision depends not only on the destination address
pairs of prefixes (destination, source) to a next-hop. When multiple but also on the source address of the packet being routed, which
entries are candidate to route a packet, the one with the most makes it possible for two packets with the same destination but
specific destination prefix is choosen, and in case of equality the different source addresses to be routed following different paths.
one with the most specific source. In source-specific routing, two The forwarding tables are extended to map pairs of prefixes
packets with the same destination but different sources may be (destination, source) to next hops. When multiple entries match a
forwarded among different paths. given packet, the one with the most specific destination prefix is
chosen, and, in case of equality, the one with the most specific
source prefix.
The main application of source-specific routing is, at the time of The main application of source-specific routing is multihoming with
this writing, multihoming with Provider Agregatable (PA) addresses. multiple addresses, a technique for multihoming which, unlike
In such configuration, each Internet Service Provider (ISP) provides multihoming, does not require the use of provider-independent
to the network a PA prefix and a default route for this prefix while addresses and does not cause excessive growth of the global routing
performing ingress filtering ([BCP84]). Each host has one address table. In a network using this form of multihoming, each host is
per ISP, and sends packets with one of these addresses as source given multiple addresses, one per upstream provider. When a host
address. Source-specific routing ensures that packets are routed sources a packet, it picks one of its addresses as the source address
towards the provider of their source address, such that they are not of the packet, and source-specific routing is used to route the
filtered out. More details and more use cases can be found in packet to an edge router that is connected to the corresponding
[SS-ROUTING],[IETF-SSR]. provider, which is compatible with [BCP84]. More details are given
in [SS-ROUTING] and [DSR].
This document describes the source-specific routing extension for the This document describes a source-specific routing extension for the
Babel routing protocol [BABEL]. This involves changes to data Babel routing protocol [BABEL]. This involves minor changes to the
structures and protocol messages. The data structures receive an data structures, which must include a source prefix in addition to
additionnal source prefix which is part of the index, similarly to the destination prefix already present, and some changes to the
(and with) the destination prefix. The Update, Route Request and Update, Route Request and Seqno Request TLVs, which are extended with
Seqno Request are the three messages which carry a (destination) a source prefix. The source prefix is encoded using a mandatory sub-
prefix: they are extended with a source prefix. TLV ([BABEL] Section 4.4).
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Data Structures 3. Data Structures
Some of the data structures of a Babel node contains a destination A number of the conceptual data structures described in Section 3.2
prefix or are partly indexed by a destination prefix. This extension of [BABEL] contain a destination prefix. This specification extends
adds a source prefix to these structures and indexes. these data structures with a source prefix. Data from the original
protocol, which do not specify a source prefix, are stored with a
zero length source prefix, which matches exactly the same set of
packets as the original, non-source-specific data.
3.1. The Source Table 3.1. The Source Table
Every Babel node maintains a source table, as described in [BABEL], Every Babel node maintains a source table, as described in [BABEL]
Section 3.2.5. A source-specific Babel node extends this table with Section 3.2.5. A source-specific Babel node extends this table with
the following field. With this extension, the source table is the following field:
indexed by triples of the form (prefix, source prefix, router-id).
o the source prefix specifying the source address of packets to o The source prefix specifying the source address of packets to
which this entry applies. which this entry applies.
If a source table entry has a zero length source prefix, then the The source table is now indexed by triples of the form (prefix,
entry is a non-source-specific entry, and is treated just like a source prefix, router-id).
source table entry defined by the original Babel protocol.
With this extension, the route entry contains a source which itself Note that the route entry contains a source which itself contains a
contains a source prefix. These are two very different concepts, and source prefix. These are two very different concepts that should not
should not be confused. be confused.
3.2. The Route Table 3.2. The Route Table
Every Babel node maintains a route table, as described in [BABEL], Every Babel node maintains a route table, as described in [BABEL]
Section 3.2.6. With this extension, the route table is indexed by Section 3.2.6. Each route table entry contains, among other data, a
triples of the form (prefix, source prefix, neighbour) obtained from source, which this specification extends with a source prefix as
the associated source table entry. described above. The route table is now indexed by triples of the
form (prefix, source prefix, neighbour), where the prefix and source
If a route table entry has a zero length source prefix, then the prefix are obtained from the source.
entry is a non-source-specific entry, and is treated just like a
route table entry defined by the original Babel protocol.
3.3. The Table of Pending Seqno Requests 3.3. The Table of Pending Seqno Requests
Every Babel node maintains a table of pending seqno requests, as Every Babel node maintains a table of pending seqno requests, as
described in [BABEL], Section 3.2.7. A source-specific Babel node described in [BABEL], Section 3.2.7. A source-specific Babel node
extends this table with the following entry. With this extension, extends this table with the following entry:
the table of pending seqno requests is indexed by triples of the form
(prefix, source prefix, router-id).
o the source prefix being requested. o The source prefix being requested.
The table of pending seqno requests is now indexed by triples of the
form (prefix, source prefix, router-id).
4. Data Forwarding 4. Data Forwarding
In next-hop routing, if two routing table entries overlap, then one In next-hop routing, if two routing table entries overlap, then one
is necessarily more specific than the other; the "longest prefix is necessarily more specific than the other; the "longest prefix
rule" specifies that the most specific applicable routing table entry rule" specifies that the most specific applicable routing table entry
is chosen. is chosen.
With source-specific routing, there might no longer be a most With source-specific routing, there might no longer be a most
specific applicable entry: two routing table entries might match a specific applicable entry: two routing table entries might match a
given packet without one necessarily being more specific than the given packet without one necessarily being more specific than the
other. Consider for example the following routing table: other. Consider for example the following routing table:
destination source next-hop destination source next-hop
2001:DB8:0:1::/64 ::/0 A 2001:DB8:0:1::/64 ::/0 A
::/0 2001:DB8:0:2::/64 B ::/0 2001:DB8:0:2::/64 B
This specifies that all packets with destination in 2001:DB8:0:1::/64 This specifies that all packets with destination in 2001:DB8:0:1::/64
are to be routed through A, while all packets with source in are to be routed through A, while all packets with source in
2001:DB8:0:2::/64 are to be routed through B. A packet with source 2001:DB8:0:2::/64 are to be routed through B. A packet with source
2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules,
although neither is more specific than the other. A choice is although neither is more specific than the other. A choice is
necessary, and unless the choice being made is the same on all necessary, and unless the choice being made is the same on all
routers in a routing domain, persistent routing loops may occur. routers in a routing domain, persistent routing loops may occur.
More informations are available in [SS-ROUTING] Section IV.C. More details are given in [SS-ROUTING] Section IV.C.
A Babel implementation MUST choose routing table entries by using the A Babel implementation MUST choose routing table entries by using the
so-called destination-first ordering, where a routing table entry R1 so-called destination-first ordering, where a routing table entry R1
is preferred to a routing table entry R2 when either R1's destination is preferred to a routing table entry R2 when either R1's destination
prefix is more specific than R2's, or the destination prefixes are prefix is more specific than R2's, or the destination prefixes are
equal and R1's source prefix is more specific than R2's. (In more equal and R1's source prefix is more specific than R2's. (In more
formal terms, routing table entries are compared using the formal terms, routing table entries are compared using the
lexicographic product of the destination prefix ordering by the lexicographic product of the destination prefix ordering by the
source prefix ordering.) source prefix ordering.) This is consistent with the behaviour
described in Section 3.3 of [DSR].
In practice, this means that a source-specific Babel implementation In practice, this means that a source-specific Babel implementation
must take care that any lower layer that performs packet forwarding must take care that any lower layer that performs packet forwarding
obey this semantics. In particular: obey this semantics. In particular:
o If the lower layers implement the destination-first ordering, then o If the lower layers implement the destination-first ordering, then
the Babel implementation MAY use them directly; the Babel implementation MAY use them directly;
o If the lower layers can hold source-specific routes, but not with o If the lower layers can hold source-specific routes, but not with
the right semantics, then the Babel implementation MUST the right semantics, then the Babel implementation MUST
disambiguate the routing table by using a suitable disambiguation disambiguate the routing table by using a suitable disambiguation
algorithm (see [SS-ROUTING] Section V.B for such an algorithm); algorithm (see [SS-ROUTING] Section V.B for such an algorithm);
o If the lower layers cannot hold source-specific routes, then a o If the lower layers cannot hold source-specific routes, then a
Babel implementation MUST silently ignore (drop) any source- Babel implementation MUST silently ignore (drop) any source-
specific routes. specific routes.
5. Protocol Operation 5. Protocol Operation
This extension does not fundamentally change the operation of the This extension does not fundamentally change the operation of the
Babel protocol. We only describe the fundamental differences between Babel protocol, and we therefore only describe differences between
the original protocol and this extension in this section. The other the original protocol and the extended protocol.
mechanisms described in [BABEL] (Section 3) are extended to pairs of
(destination, source) prefixes instead of just (destination)
prefixes.
5.1. Source-specific messages
Three messages carry a destination prefix: Updates, Route Requests In the original protocol, three TLVs carry a destination prefix:
and Seqno Requests. These messages are extended to carry, in Updates, Route Requests and Seqno Requests. This specification
addition, a source prefix if (and only if) the corresponding route is extends these messages to optionally carry a source prefix sub-TLV,
source-specific. More formally, an Update, a Route Request and a as described in Section 7 below. The sub-TLV is marked as mandatory,
Seqno Request MUST carry a source prefix if they concern a source- so that an unextended implementation will silently ignore the whole
specific route (non-zero length source prefix) and MUST NOT carry a enclising TLV. A node obeying this specification MUST NOT send a TLV
source prefix otherwise (zero length source prefix). A message which with a zero-length source prefix: instead, it sends a TLV with no
carries a source prefix is said to be source-specific. source prefix sub-TLV. Conversely, an extended implementation MUST
interpret an unextended TLV as carrying a source prefix of zero
length. Taken together, these properties ensure interoperability
between the original and extended protocols (see Section 6 below).
5.2. Route Acquisition 5.1. Protocol Messages
When a non-source-specific Babel node receives a source-specific This extension allows three TLVs of the original Babel protocol to
update, it silently ignores it. When a source-specific Babel node carry a source prefix: Update TLVs, Route Request TLVs and Seqno
receives a non-source-specific update, it MUST treat this update as a Request TLVs.
zero length source-specific update.
When a source-specific Babel node receives a source-specific update In order to advertise a route with a non-zero-length source prefix, a
node sends a source-specific Update, i.e., an Update with a source
prefix sub-TLV. When a node receives a source-specific Update
(prefix, source prefix, router-id, seqno, metric) from a neighbour (prefix, source prefix, router-id, seqno, metric) from a neighbour
neigh, it behaves as described in [BABEL] (Section 3.5.4) though neigh, it behaves as described in [BABEL] Section 3.5.4, except that
indexing entries by (prefix, source prefix, neigh). the entry under consideration is indexed by (prefix, source prefix,
neigh) rather than just (prefix, neigh).
5.3. Wildcard retractions (update)
The original protocol defines a wildcard update with AE equals to 0
as being a wildcard retraction. A node receiving a wildcard
retraction on an interface must consider that the sending node
retracts all the routes it advertised on this interface.
Wildcard retractions are used when a node is about to leave the Similarly, when a node needs to send a Request of either kind that
network. Thus, this extension does not define source-specific applies to a route with a non-zero length source prefix, it sends a
wildcard retraction, but extends wildcard retraction to apply also to source-specific Request, i.e., a Request with a source prefix sub-
source-specific routes. More formally, a wildcard update MUST NOT TLV. When a node receives a source-specific Request, it behaves as
carry a source prefix, and a source-specific Babel node receiving a described in Section 3.8 of [BABEL], except that the request applies
(legacy) wildcard update MUST retracts all routes it learns from this to the Route Table entry carrying the source prefix indicated by the
node (including source-specific ones). sub-TLV.
5.4. Wildcard requests 5.2. Wildcard Messages
The original Babel protocol states that when a node receives a In the original protocol, the Address Encoding value 0 is used for
wildcard route request, it SHOULD send a full routing table dump. wildcard messages: messages that apply to all routes, of any address
This extension does not change this statement: a source-specific node family and with any destination prefix. Wildcard messages are
SHOULD send a full routing table dump when receiving a wildcard allowed in two places in the protocol: wildcard retractions are used
request. to retract all of the routes previously advertised by a node on a
given interface, and wildcard Route Requests are used to request a
full dump of the Route Table from a given node. Wildcard messages
are intended to apply to all routes, including routes decorated with
additional data and AE values to be defined by future extensions, and
hence this specification extends wildcard operations to apply to all
routes, whatever the value of the source prefix.
Source-specific wildcard requests does not exist: a wildcard request More precisely, a node receiving an Update with the AE field set to 0
MUST NOT carry a source prefix, and a source prefix associated with a and the Metric field set to infinity (a wildcard retraction) MUST
wildcard update SHOULD be ignored. apply the route acquisition procedure described in Section 3.5.4 of
[BABEL] to all of the routes that is has learned from the sending
node, whatever the value of the source prefix. A node MUST NOT send
a wildcard retraction with an attached source prefix, and a node that
receives a wildcard retraction with a source prefix MUST silently
ignore it.
One of the motivation behalf this design choice is that wildcard Similarly, a node that receives a route request with the AE field set
requests are defined with AE equals to 0. They naturally apply to AE to 0 (a wildcard route request) SHOULD send a full routing table
1, AE 2 and AE 3 defined in [BABEL], but also to any other AE which dump, including routes with a non-zero-length source prefix. A node
may be defined in the future. New AEs, new TLVs or new sub-TLVs are MUST NOT send a wildcard request that carries a source prefix, and a
extension mechanisms. Thus, the semantics of a wildcard request is node receiving a wildcard request with a with a source prefix MUST
clearly to also asks for routes coming from extensions. silently ignore it.
6. Compatibility with the base protocol 6. Compatibility with the base protocol
The protocol extension defined in this document is, to a great The protocol extension defined in this document is, to a great
extent, interoperable with the base protocol defined in [BABEL] (and extent, interoperable with the base protocol defined in [BABEL] (and
all its known extensions). More precisely, if non-source-specific all of its extensions). More precisely, if non-source-specific
routers and source-specific routers are mixed in a single routing routers and source-specific routers are mixed in a single routing
domain, Babel's loop-avoidance properties are preserved, and, in domain, Babel's loop-avoidance properties are preserved, and, in
particular, no persistent routing loops will occur. particular, no persistent routing loops will occur.
However, this extension is not compatible with the Experimental However, this extension is encoded using mandatory sub-TLVs,
Track's Babel Routing Protocol [RFC6126]. It requires the mandatory introduced in [BABEL], and therefore is not compatible with the older
sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT version of the Babel Routing Protocol [RFC6126]. Consequently, this
be used with routers implementing RFC 6126, otherwise persistent extension MUST NOT be used with routers implementing RFC 6126,
routing loops may occur. otherwise persistent routing loops may occur.
6.1. Loop-avoidance 6.1. Loop-avoidance
The extension defined in this protocol uses a new Mandatory sub-TLV The extension defined in this protocol uses a new Mandatory sub-TLV
to carry the source prefix information. As discussed in Section 4.4 to carry the source prefix information. As discussed in Section 4.4
of [BABEL], this encoding ensures that non-source-specific routers of [BABEL], this encoding ensures that non-source-specific routers
will silently ignore the whole TLV, which is necessary to avoid will silently ignore the whole TLV, which is necessary to avoid
persistent routing loops in hybrid networks. persistent routing loops in hybrid networks.
Consider two nodes A and B, with A source-specific announcing a route Consider two nodes A and B, with A source-specific announcing a route
to (D, S). Suppose that B (non source-specific) merely ignores the to (D, S). Suppose that B (non source-specific) merely ignores the
source prefix information when it receives the update rather than source prefix information when it receives the update rather than
ignoring the whole TLV, and reannounces the route as D. This ignoring the whole TLV, and re-announces the route as D. This re-
reannouncement reaches A, which treats it as (D, ::/0). Packets announcement reaches A, which treats it as (D, ::/0). Packets
destined to D but not sourced in S will be forwarded by A to B, and destined to D but not sourced in S will be forwarded by A to B, and
by B to A, causing a persistent routing loop: by B to A, causing a persistent routing loop:
(D,S) (D) (D,S) (D)
<-- <-- <-- <--
------ A ----------------- B ------ A ----------------- B
--> -->
(D,::/0) (D,::/0)
6.2. Starvation and Blackholes 6.2. Starvation and Blackholes
skipping to change at page 8, line 20 skipping to change at page 8, line 12
routers will suffer starvation, and discard packets for destinations routers will suffer starvation, and discard packets for destinations
that are only announced by source-specific routers. that are only announced by source-specific routers.
A simple yet sufficient condition for avoiding starvation is to build A simple yet sufficient condition for avoiding starvation is to build
a connected source-specific backbone that includes all of the edge a connected source-specific backbone that includes all of the edge
routers, and announce a (non-source-specific) default route towards routers, and announce a (non-source-specific) default route towards
the backbone. the backbone.
7. Protocol Encoding 7. Protocol Encoding
This extension defines a new sub-TLV used to carry a source prefix by This extension defines a new sub-TLV used to carry a source prefix:
the three following existing messages: Update, Route Request and the Source Prefix sub-TLV. It can be used within an Update, a Route
Seqno Request. Request or a Seqno Request TLV to match a source-specific entry of
the Route Table, in conjunction with the destination prefix natively
carried by these TLVs.
Since a source-specific routing entry is characterized by a single
destination prefix and a single source prefix, a source-specific
message contains exactly one Source Prefix sub-TLV. A node MUST NOT
send more that one Source Prefix sub-TLV in a TLV, and a node
receiving more than one Source Prefix sub-TLV in a single TLV SHOULD
ignore this TLV. It MAY ignore the whole packet.
7.1. Source Prefix sub-TLV 7.1. Source Prefix sub-TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = TBD[128]| Length | Source Plen | Source Prefix... | Type = TBD | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields: Fields:
Type Set to TBD[128] to indicate a Source Prefix sub-TLV. Type Set to TBD to indicate a Source Prefix sub-TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, exclusive of the Type and Length
fields. fields.
Source Plen The length of the advertised source prefix. This MUST Source Plen The length of the advertised source prefix. This MUST
NOT be 0. NOT be 0.
Source Prefix The source prefix being advertised. This field's size Source Prefix The source prefix being advertised. This field's size
is (Source Plen)/8 rounded upwards. is (Source Plen)/8 rounded upwards.
The source prefix encoding (AE) is the same as the Prefix's. It is The contents of the source prefix sub-TLV are interpreted according
defined by the AE field of the corresponding TLV. to the AE of the enclosing TLV.
Note that this sub-TLV is a Mandatory sub-TLV. The whole TLV MUST be Note that this sub-TLV is a mandatory sub-TLV. Threfore, as
ignored if that sub-TLV is not recognized. Otherwise, routing loops described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if
may occur (see Section 6.1). that sub-TLV is not understood (or malformed). Otherwise, routing
loops may occur (see Section 6.1).
7.2. Source-specific Update 7.2. Source-specific Update
The source-specific Update is an Update TLV with a Source Prefix sub- The source-specific Update is an Update TLV with a Source Prefix sub-
TLV. It advertises or retracts source-specific routes in the same TLV. It advertises or retracts source-specific routes in the same
manner than routes with non-source-specific Updates (see [BABEL]). A manner than routes with non-source-specific Updates (see [BABEL]). A
wildcard retraction (Update with AE equals to 0) MUST NOT carry a wildcard retraction (Update with AE equals to 0) MUST NOT carry a
Source Prefix sub-TLV. Source Prefix sub-TLV.
Contrary to the destination prefix, this extension does not compress Contrary to the destination prefix, this extension does not compress
the source prefix attached to Updates. However, as defined in the source prefix attached to Updates. However, compression is
[BABEL] (Section 4.5), the compression is allowed for the destination allowed for the destination prefix of source-specific routes. As
prefix of source-specific routes. Legacy implementation will described in Section 4.5 of [BABEL], unextended implementations will
correctly update their parser state while ignoring the whole TLV correctly update their parser state while otherwise ignoring the
afterwards. whole TLV.
7.3. Source-specific (Route) Request 7.3. Source-specific (Route) Request
A source-specific Route Request is a Route Request TLV with a Source A source-specific Route Request is a Route Request TLV with a Source
Prefix sub-TLV. It prompts the receiver to send an update for a Prefix sub-TLV. It prompts the receiver to send an update for a
given pair of destination and source prefixes. A wildcard request given pair of destination and source prefixes, as described in
(Route Request with AE equals to 0) MUST NOT carry a Source Prefix Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with
sub-TLV. AE equals to 0) MUST NOT carry a Source Prefix sub-TLV.
7.4. Source-Specific Seqno Request 7.4. Source-Specific Seqno Request
A source-specific Seqno Request is a Seqno Request TLV with a Source A source-specific Seqno Request is a Seqno Request TLV with a Source
Prefix sub-TLV. It is just like a Seqno Request for a source- Prefix sub-TLV. It requests the receiving node to perform the
specific route. It uses the same mechanisms described in [BABEL]. procedure described in Section 3.8.1.2 of [BABEL], but applied to a
pair of a destination and source prefix.
8. IANA Considerations 8. IANA Considerations
IANA is requested to allocate TBD, a Babel sub-TLV type from the IANA is requested to allocate TBD, a Babel sub-TLV type from the
range reserved for mandatory sub-TLVs [value 128 suggested], and to range reserved for mandatory sub-TLVs [value 128 suggested], and to
add the following entry to the "Babel mandatory sub-TLV Types" add the following entry to the "Babel mandatory sub-TLV Types"
registry: registry:
+----------+---------------+-----------------+ +----------+---------------+-----------------+
| Type | Name | Reference | | Type | Name | Reference |
+----------+---------------+-----------------+ +----------+---------------+-----------------+
| TBD[128] | Source Prefix | (this document) | | TBD[128] | Source Prefix | (this document) |
+----------+---------------+-----------------+ +----------+---------------+-----------------+
9. Security considerations 9. Security considerations
The extension defined in this document adds a new sub-TLV to three The extension defined in this document adds a new sub-TLV to three
TLVs already present in the original Babel protocol. It does not by TLVs already present in the original Babel protocol, and does not in
itself change the security properties of the protocol. itself change the security properties of the protocol. However,
source-specific routing gives more control over routing to the
sending hosts, which might have security implications (see Section 8
of [DSR]).
10. References 10. References
10.1. Normative References 10.1. Normative References
[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet
Draft draft-ietf-babel-rfc6126bis-02, May 2017. Draft draft-ietf-babel-rfc6126bis-04, May 2017.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[IETF-SSR] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Lamparter, D. and A. Smirnov, "Destination/Source Requirement Levels", BCP 14, RFC 2119,
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing, DOI 10.17487/RFC2119, March 1997.
May 2017.
10.2. Informative References
[DSR] Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-
06, May 2018.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol [RFC6126] Chroboczek, J., "The Babel Routing Protocol
(Experimental)", RFC 6126, February 2011. (Experimental)", RFC 6126, February 2011.
10.2. Informative References
[SS-ROUTING] [SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing", Boutier, M. and J. Chroboczek, "Source-Specific Routing",
August 2014. August 2014.
In Proc. IFIP Networking 2015. A slightly earlier In Proc. IFIP Networking 2015. A slightly earlier
version is available online from http://arxiv.org/ version is available online from http://arxiv.org/
pdf/1403.0445. pdf/1403.0445.
Authors' Addresses Authors' Addresses
 End of changes. 52 change blocks. 
182 lines changed or deleted 199 lines changed or added

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