draft-ietf-babel-source-specific-00.txt   draft-ietf-babel-source-specific-01.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Updates: 6126bis IRIF, University of Paris-Diderot Updates: 6126bis (if approved) IRIF, University of Paris-Diderot
(if approved) August 11, 2017 Intended status: Standards Track August 21, 2017
Intended status: Standards Track Expires: February 22, 2018
Expires: February 12, 2018
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-00 draft-ietf-babel-source-specific-01
Abstract Abstract
This document describes an extension to the Babel routing protocol to Source-specific routing is an extension to traditional next-hop
support source-specific routing. routing where packets are forwarded according to both their
destination and their source address. This document describes the
source-specific routing extension to the Standard Track's Babel
routing protocol defined in [BABEL]. It is incompatible with the
Experimental Track's Babel [RFC6126].
Status of this Memo 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
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 12, 2018. This Internet-Draft will expire on February 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction and background . . . . . . . . . . . . . . . . . 3 2. Introduction and background . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . 3 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
3.3. The Table of Pending 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 . . . . . . . . . . . . . . . . . 5 5.1. Source-specific messages . . . . . . . . . . . . . . . . 6
5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 5 5.2. Route Acquisition . . . . . . . . . . . . . . . . . . . . 6
5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 6 5.3. Wildcard retractions (update) . . . . . . . . . . . . . . 6
5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6 5.4. Wildcard requests . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility with the base protocol . . . . . . . . . . . . . 8 6. Compatibility with the base protocol . . . . . . . . . . . . 7
6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 9 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 9 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 9 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
7.2. Source-specific Update . . . . . . . . . . . . . . . . . . 10 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
7.3. Source-specific (Route) Request . . . . . . . . . . . . . 10 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 10 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security considerations . . . . . . . . . . . . . . . . . . . 11 9. Security considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. TODOs 1. TODOs
o Source Prefix sub-TLV type: TBD o Source Prefix sub-TLV type: TBD
o check references (Section) for BABEL in 6126bis o check references (Section) for BABEL in 6126bis
o define wildcard Requests behaviour
2. Introduction and background 2. Introduction and background
Source-specific routing (also known as Source Address Dependant The Babel routing protocol as defined is [BABEL] is a distance vector
Routing, SAD Routing or SADR) is an extension to traditional next-hop routing protocol for next-hop routing. In next-hop routing, each
routing where packets are routed according to both their destination node maintains a forwarding table which maps prefixes to next-hops.
and their source address. This document describes the source- The forwarding decision is a per-packet operation which depends on
specific routing extension to the Babel routing protocol as defined the destination address of the packets and on the entries of the
in 6126bis [BABEL]. forwarding table. When a packet is about to be routed, its
destination address is compared to the prefixes of the routing table:
the entry with the most specific prefix containing the destination
address of the packet is choosen, and the packet is forwarded to the
associated next-hop. Next-hop routing is a simple, well understood
paradigm that works satisfactorily in a large number of cases.
Background information about source-specific routing is provided in Source-specific routing is a modest extension of next-hop routing
[SS-ROUTING]. where the forwarding decision additionnaly depends on the source
address of the packets. The forwarding tables are extended to map
pairs of prefixes (destination, source) to a next-hop. When multiple
entries are candidate to route a packet, the one with the most
specific destination prefix is choosen, and in case of equality the
one with the most specific source. In source-specific routing, two
packets with the same destination but different sources may be
forwarded among different paths.
The main application of source-specific routing is, at the time of
this writing, multihoming with Provider Agregatable (PA) addresses.
In such configuration, each Internet Service Provider (ISP) provides
to the network a PA prefix and a default route for this prefix while
performing ingress filtering ([BCP84]). Each host has one address
per ISP, and sends packets with one of these addresses as source
address. Source-specific routing ensures that packets are routed
towards the provider of their source address, such that they are not
filtered out. More details and more use cases can be found in
[SS-ROUTING],[IETF-SSR].
This document describes the source-specific routing extension for the
Babel routing protocol [BABEL]. This involves changes to data
structures and protocol messages. The data structures receive an
additionnal source prefix which is part of the index, similarly to
(and with) the destination prefix. The Update, Route Request and
Seqno Request are the three messages which carry a (destination)
prefix: they are extended with a source prefix.
3. Data Structures 3. Data Structures
This extension adds some data to the data structures maintained by a Some of the data structures of a Babel node contains a destination
Babel node. prefix or are partly indexed by a destination prefix. This extension
adds a source prefix to these structures and indexes.
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: the following field. With this extension, the source table is
indexed by triples of the form (prefix, source prefix, router-id).
o the source prefix (sprefix, splen) specifying the source address o the source prefix specifying the source address of packets to
of packets to which this entry applies. which this entry applies.
If a source table entry has a zero length source prefix (splen equals If a source table entry has a zero length source prefix, then the
to 0), then the entry is a non-source-specific entry, and is treated entry is a non-source-specific entry, and is treated just like a
just like a source table entry defined by the original Babel source table entry defined by the original Babel protocol.
protocol.
With this extension the route entry contains a source which itself With this extension, the route entry contains a source which itself
contains a source prefix. These are two very different concepts, and contains a source prefix. These are two very different concepts, and
should not be confused. should not 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, this table is indexed by the Section 3.2.6. With this extension, the route table is indexed by
5-tuple (prefix, plen, source prefix, source plen, router-id) triples of the form (prefix, source prefix, neighbour) obtained from
obtained from the associated source table entry. the associated source table entry.
If a route table entry has a zero length source prefix, then the If a route table entry has a zero length source prefix, then the
entry is a non-source-specific entry, and is treated just like a entry is a non-source-specific entry, and is treated just like a
route table entry defined by the original Babel protocol. route table entry defined by the original Babel protocol.
3.3. The Table of Pending Requests 3.3. The Table of Pending Seqno Requests
Every Babel node maintains a table of pending requests, as described Every Babel node maintains a table of pending seqno requests, as
in [BABEL], Section 3.2.7. A source-specific Babel node extends this described in [BABEL], Section 3.2.7. A source-specific Babel node
table with the following entry: extends this table with the following entry. With this extension,
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.
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 prefix: 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 fragment of a routing other. Consider for example the following routing table:
table:
(2001:DB8:0:1::/64, ::/0, A) destination source next-hop
(::/0, 2001:DB8:0:2::/64, B) 2001:DB8:0:1::/64 ::/0 A
::/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 packets with a source in 2001:DB8: are to be routed through A, while all packets with source in
0:2::/64 are to be routed through B. A packet with source 2001:DB8:0: 2001:DB8:0:2::/64 are to be routed through B. A packet with source
2::42 and destination 2001:DB8:0:1::57 matches both rules, although 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules,
neither is more specific than the other. A choice is necessary, and although neither is more specific than the other. A choice is
unless the choice being made is the same on all routers in a routing necessary, and unless the choice being made is the same on all
domain, persistent routing loops may occur. More informations are routers in a routing domain, persistent routing loops may occur.
available in [SS-ROUTING] Section IV.C. More informations are available 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.)
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. We only describe the fundamental differences between
the original protocol and the extension in this section. The other the original protocol and this extension in this section. The other
mechanisms described in [BABEL] (Section 3) are extended to pairs of mechanisms described in [BABEL] (Section 3) are extended to pairs of
(destination, source) prefixes instead of just (destination) (destination, source) prefixes instead of just (destination)
prefixes. prefixes.
5.1. Source-specific messages 5.1. Source-specific messages
Three messages are used to communicate informations on routes: Three messages carry a destination prefix: Updates, Route Requests
Updates, Route Requests and Seqno Requests. With this extension, and Seqno Requests. These messages are extended to carry, in
these messages carry an additionnal source prefix if (and only if) addition, a source prefix if (and only if) the corresponding route is
the corresponding route is source-specific. More formally, an source-specific. More formally, an Update, a Route Request and a
Update, a Route Request and a Seqno Request MUST carry a source Seqno Request MUST carry a source prefix if they concern a source-
prefix if they concern a source-specific route (non-zero length specific route (non-zero length source prefix) and MUST NOT carry a
source prefix) and MUST NOT carry a source prefix otherwise (zero source prefix otherwise (zero length source prefix). A message which
length source prefix). A message which carries a source prefix is carries a source prefix is said to be source-specific.
said to be source-specific.
5.2. Route Acquisition 5.2. Route Acquisition
When a non-source-specific Babel node receives a source-specific When a non-source-specific Babel node receives a source-specific
update, it silently ignores it. update, it silently ignores it. When a source-specific Babel node
receives a non-source-specific update, it MUST treat this update as a
zero length source-specific update.
TODO{On receipt of a source-specific update (id, prefix, source When a source-specific Babel node receives a source-specific update
prefix, seqno, metric), a source-specific Babel node behaves as (prefix, source prefix, router-id, seqno, metric) from a neighbour
described in [BABEL] Section 3.5.4 though indexing entries by (neigh, neigh, it behaves as described in [BABEL] (Section 3.5.4) though
id, prefix, source prefix).} When a source-specific Babel node indexing entries by (prefix, source prefix, neigh).
receives a non-source-specific update, it MUST treat this update as
carrying a zero length source prefix.
5.3. Wildcard retractions (update) 5.3. Wildcard retractions (update)
The original protocol defines a wildcard update with AE equals to 0 The original protocol defines a wildcard update with AE equals to 0
as being a wildcard retraction. A node receiving a wildcard as being a wildcard retraction. A node receiving a wildcard
retraction on an interface must consider that the sending node retraction on an interface must consider that the sending node
retracts all the routes it advertised on this interface. retracts all the routes it advertised on this interface.
Wildcard retractions are used when a node is about to leave the Wildcard retractions are used when a node is about to leave the
network. Thus, this extension does not define source-specific network. Thus, this extension does not define source-specific
wildcard retraction, but extends wildcard retraction to apply also to wildcard retraction, but extends wildcard retraction to apply also to
source-specific routes. More formally, a wildcard update MUST NOT source-specific routes. More formally, a wildcard update MUST NOT
carry a source prefix, and a source-specific Babel node receiving a carry a source prefix, and a source-specific Babel node receiving a
(legacy) wildcard update MUST retracts all routes it learns from this (legacy) wildcard update MUST retracts all routes it learns from this
node (including source-specific ones). node (including source-specific ones).
5.4. Wildcard requests 5.4. Wildcard requests
TODO: behaviour to be defined.
5.4.1. Proposal 1
The original Babel protocol states that when a node receives a The original Babel protocol states that when a node receives a
wildcard route request, it SHOULD send a full routing table dump. wildcard route request, it SHOULD send a full routing table dump.
This extension does not change this statement: a source-specific node This extension does not change this statement: a source-specific node
SHOULD send a full routing table dump when receiving a wildcard SHOULD send a full routing table dump when receiving a wildcard
request. request.
Source-specific wildcard requests does not exist: a wildcard request Source-specific wildcard requests does not exist: a wildcard request
SHOULD NOT carry a source prefix. MUST NOT carry a source prefix, and a source prefix associated with a
wildcard update SHOULD be ignored.
5.4.2. Proposal 2
We assume that a mandatory sub-TLV has a corresponding non-mandatory
sub-TLV. This proposal is like Proposal 3 but instead of having
multiple wildcard request TLVs, one for each kind of route
understood, we use one wildcard request with sub-TLVs corresponding
to the extension. To have a full routing table dump, a node sends a
wildcard requests with a non-mandatory Source sub-TLV.
A source-specific node SHOULD always attach a non-mandatory Source
sub-TLV to its wildcard requests.
This proposal has been rejected because it implies to share the space
of non-mandatory and mandatory sub-TLVs.
5.4.3. Proposal 3 (mentionned by Juliusz)
The Babel protocol provides the ability to request a full routing
table dump by sending a "wildcard request", a route request with the
AE field set to 0. As the original protocol has no source-specific
routes, such a request may only concern non-source-specific routes.
This extension does not modify the semantics of wildcard requests in
that sense: a wildcard request prompts the receiver to send its non-
source-specific routes only, and a Babel node SHOULD NOT send any
source-specific updates in reply to a wildcard request.
To obtain a dump of the source-specific routes, a source-specific
wildcard request MUST be used. A source-specific wildcard request is
a wildcard request carrying a zero length source prefix.
When a node receives a source-specific wildcard request, it SHOULD
send a dump of its routes which are source-specific "only". It
SHOULD NOT send any non-source-specific routes in reply to a source-
specific wildcard request. It SHOULD NOT send any source-specific
routes which are under the effect of a future extension. Such
extension should detail how to handle the possible combinations.
In consequence, a node requiring a full routing table dump must send
both a non-source-specific wildcard request and a source-specific
wildcard request.
5.4.4. Proposal 4 (mentionned by Juliusz)
Wildcard requests are deprecated. Either deprecate it in 6126bis, or
say the following.
A node receiving a wildcard request SHOULD ignore it.
This proposal has been rejected because wildcard requests speeds up
the convergence of the network on boot. This is considered
important.
5.4.5. Proposal 5 (mentionned by David)
By default, a vanilla wildcard request triggers a dump of all non-
specific routes. We define a new non-mandatory sub-TLV on Route
Requests called "Requested Route Types" that contains an array of all
the types of routes this request is requesting.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | RR Type 1 | RR Type 2...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
We also create a registry of Requested Route (RR) types, for example:
0 = Regular
1 = Source-Specific
2 = TOS-specific
etc.
A node receiving a Requested Route Types sub-TLV in a wildcard One of the motivation behalf this design choice is that wildcard
request SHOULD sends back a dump of all its routes corresponding to requests are defined with AE equals to 0. They naturally apply to AE
the requested types or to a combination of these types. 1, AE 2 and AE 3 defined in [BABEL], but also to any other AE which
may be defined in the future. New AEs, new TLVs or new sub-TLVs are
extension mechanisms. Thus, the semantics of a wildcard request is
clearly to also asks for routes coming from extensions.
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 its known 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 not compatible with the Experimental
Track's Babel Routing Protocol (RFC 6126). It requires the mandatory Track's Babel Routing Protocol [RFC6126]. It requires the mandatory
sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT sub-TLV introduced in [BABEL]. Consequently, this extension MUST NOT
be used with routers implementing RFC 6126, otherwise persistent be used with routers implementing RFC 6126, otherwise persistent
routing loops may occur. 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 merely ignores the source prefix to (D, S). Suppose that B (non source-specific) merely ignores the
information when it receives the update rather than ignoring the sub- source prefix information when it receives the update rather than
TLV, and reannounces the route as D. This reannouncement reaches A, ignoring the whole TLV, and reannounces the route as D. This
which treats it as (D, ::/0). Packets destined to D but not sourced reannouncement reaches A, which treats it as (D, ::/0). Packets
in S will be forwarded by A to B, and by B to A, causing a persistent destined to D but not sourced in S will be forwarded by A to B, and
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
In general, discarding source-specific routes by non-source-specific In general, discarding source-specific routes by non-source-specific
skipping to change at page 9, line 35 skipping to change at page 8, line 29
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 by
the three following existing messages: Update, Route Request and the three following existing messages: Update, Route Request and
Seqno Request. Seqno Request.
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 | Length | Source Plen | Source Prefix... |Type = TBD[128]| Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields: Fields:
Type Set to TBD to indicate a Source Prefix sub-TLV.
Type Set to TBD[128] 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 field's encoding (AE) is the same as the Prefix's. The source prefix encoding (AE) is the same as the Prefix's. It is
It is defined by the AE field of the corresponding TLV. defined by the AE field of the corresponding 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. The whole TLV MUST be
ignored if that TLV is not recognized as described in Section 4.4. ignored if that sub-TLV is not recognized. Otherwise, routing loops
may occur (see Section 6.1).
Otherwise, routing loops may occur.
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]). manner than routes with non-source-specific Updates (see [BABEL]). A
This TLV MUST NOT be attached to wildcard updates. wildcard retraction (Update with AE equals to 0) MUST NOT carry a
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. The destination prefix uses the source prefix attached to Updates. However, as defined in
compression as defined in [BABEL] for Updates with Mandatory [BABEL] (Section 4.5), the compression is allowed for the destination
extensions. prefix of source-specific routes. Legacy implementation will
correctly update their parser state while ignoring the whole TLV
However, as defined in [BABEL] (Section 4.5), the compression is afterwards.
allowed for the destination prefix of source-specific routes. Legacy
implementation will correctly update their parser state, while
ignoring the whole TLV afterwards.
7.3. Source-specific (Route) Request 7.3. Source-specific (Route) Request
TODO: A source-specific Route Request prompts the receiver to send an A source-specific Route Request is a Route Request TLV with a Source
update for a given pair of destination and source prefixes. It MUST Prefix sub-TLV. It prompts the receiver to send an update for a
NOT be used to request a full routing table dump. The Source Prefix given pair of destination and source prefixes. A wildcard request
sub-TLV of a wildcard source-specific Route Request (Request with AE (Route Request with AE equals to 0) MUST NOT carry a Source Prefix
equals to 0 and a Source Prefix sub-TLV) MIGHT be ignored: a receiver sub-TLV.
MIGHT reply by a full routing table dump.
7.4. Source-Specific Seqno Request 7.4. Source-Specific Seqno Request
A source-specific Seqno Request is just like a Seqno Request for a A source-specific Seqno Request is a Seqno Request TLV with a Source
source-specific route. It uses the same mechanisms described in Prefix sub-TLV. It is just like a Seqno Request for a source-
[BABEL]. specific route. It uses the same mechanisms described in [BABEL].
8. IANA Considerations 8. IANA Considerations
IANA is instructed to add the following entry to the "Babel sub-TLV IANA is requested to allocate TBD, a Babel sub-TLV type from the
Types" registry: range reserved for mandatory sub-TLVs [value 128 suggested], and to
add the following entry to the "Babel mandatory sub-TLV Types"
registry:
+------+---------------+-----------------+ +----------+---------------+-----------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+---------------+-----------------+ +----------+---------------+-----------------+
| TBD | 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. It does not by
itself change the security properties of the protocol. itself change the security properties of the protocol.
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-02, May 2017.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[IETF-SSR]
Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing,
May 2017.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol
(Experimental)", RFC 6126, February 2011.
10.2. Informative References 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 version is available online from http://arxiv.org/
http://arxiv.org/pdf/1403.0445. pdf/1403.0445.
Authors' Addresses Authors' Addresses
Matthieu Boutier Matthieu Boutier
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13, 75205 Paris Cedex 13
France France
Email: boutier@irif.fr Email: boutier@irif.fr
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13, 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 50 change blocks. 
215 lines changed or deleted 198 lines changed or added

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