draft-ietf-babel-source-specific-04.txt   draft-ietf-babel-source-specific-05.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: April 26, 2019 October 23, 2018 Expires: October 13, 2019 April 11, 2019
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-04 draft-ietf-babel-source-specific-05
Abstract Abstract
Source-specific routing (also known as Source-Address Dependent Source-specific routing (also known as Source-Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where Routing, SADR) is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their packets are forwarded according to both their destination and their
source address. This document describes an extension for source- source address. This document describes an extension for source-
specific routing to the Babel routing protocol. specific routing to the Babel routing protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 26, 2019. This Internet-Draft will expire on October 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Source-specific routing [SS-ROUTING], or Source Address Dependent Source-specific routing [SS-ROUTING], or Source Address Dependent
Routing (SADR) [DSR], is a modest extension to next-hop routing where Routing (SADR) [DSR], is a modest extension to next-hop routing where
the forwarding decision depends not only on the destination address the forwarding decision depends not only on the destination address
but also on the source address of the packet being routed, which but also on the source address of the packet being routed, which
makes it possible for two packets with the same destination but makes it possible for two packets with the same destination but
different source addresses to be routed following different paths. different source addresses to be routed following different paths.
The forwarding tables are extended to map pairs of prefixes The forwarding tables are extended to map pairs of prefixes
(destination, source) to next hops. When multiple entries match a (destination, source) to next hops. When multiple entries match a
given packet, the one with the most specific destination prefix is given packet, the one with the most specific destination prefix is
chosen, and, in case of equality, the one with the most specific chosen, and, in the case of equally specific destination prefixes,
source prefix. the one with the most specific source prefix.
The main application of source-specific routing is a form of The main application of source-specific routing is a form of
multihoming known as multihoming with multiple addresses. When using multihoming known as multihoming with multiple addresses. When using
this technique in a network connected to multiple providers, every this technique in a network connected to multiple providers, every
host is assigned multiple addresses, one per provider. When a host host is assigned multiple addresses, one per provider. When a host
sources a packet, it picks one of its addresses as the source sources a packet, it picks one of its addresses as the source
address, and source-specific routing is used to route the packet to address, and source-specific routing is used to route the packet to
an edge router that is connected to the corresponding provider, which an edge router that is connected to the corresponding provider, which
is compatible with [BCP84]. Unlike classical multihoming, this is compatible with [BCP84]. Unlike classical multihoming, this
technique is applicable to small networks, as it does not require the technique is applicable to small networks, as it does not require the
skipping to change at page 5, line 52 skipping to change at page 5, line 52
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, and we therefore only describe differences between Babel protocol, and we therefore only describe differences between
the original protocol and the extended protocol. the original protocol and the extended protocol.
In the original protocol, three TLVs carry a destination prefix: In the original protocol, three TLVs carry a destination prefix:
Updates, Route Requests and Seqno Requests. This specification Updates, Route Requests and Seqno Requests. This specification
extends these messages to optionally carry a source prefix sub-TLV, extends these messages to optionally carry a Source Prefix sub-TLV,
as described in Section 7 below. The sub-TLV is marked as mandatory, as described in Section 7 below. The sub-TLV is marked as mandatory,
so that an unextended implementation will silently ignore the whole so that an unextended implementation will silently ignore the whole
enclosing TLV. A node obeying this specification MUST NOT send a TLV enclosing TLV. A node obeying this specification MUST NOT send a TLV
with a zero-length source prefix: instead, it sends a TLV with no with a zero-length source prefix: instead, it sends a TLV with no
source prefix sub-TLV. Conversely, an extended implementation MUST Source Prefix sub-TLV. Conversely, an extended implementation MUST
interpret an unextended TLV as carrying a source prefix of zero interpret an unextended TLV as carrying a source prefix of zero
length. Taken together, these properties ensure interoperability length. Taken together, these properties ensure interoperability
between the original and extended protocols (see Section 6 below). between the original and extended protocols (see Section 6 below).
5.1. Protocol Messages 5.1. Protocol Messages
This extension allows three TLVs of the original Babel protocol to This extension allows three TLVs of the original Babel protocol to
carry a source prefix: Update TLVs, Route Request TLVs and Seqno carry a source prefix: Update TLVs, Route Request TLVs and Seqno
Request TLVs. Request TLVs.
In order to advertise a route with a non-zero length source prefix, a 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 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 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, except that neigh, it behaves as described in [BABEL] Section 3.5.4, except that
the entry under consideration is indexed by (prefix, source prefix, the entry under consideration is indexed by (prefix, source prefix,
neigh) rather than just (prefix, neigh). neigh) rather than just (prefix, neigh).
Similarly, when a node needs to send a Request of either kind that Similarly, when a node needs to send a Request of either kind that
applies to a route with a non-zero length source prefix, it sends a applies to a route with a non-zero length source prefix, it sends a
source-specific Request, i.e., a Request with a source prefix sub- source-specific Request, i.e., a Request with a Source Prefix sub-
TLV. When a node receives a source-specific Request, it behaves as TLV. When a node receives a source-specific Request, it behaves as
described in Section 3.8 of [BABEL], except that the request applies described in Section 3.8 of [BABEL], except that the request applies
to the Route Table entry carrying the source prefix indicated by the to the Route Table entry carrying the source prefix indicated by the
sub-TLV. Source Prefix sub-TLV.
5.2. Wildcard Messages 5.2. Wildcard Messages
In the original protocol, the Address Encoding value 0 is used for In the original protocol, the Address Encoding value 0 is used for
wildcard messages: messages that apply to all routes, of any address wildcard messages: messages that apply to all routes, of any address
family and with any destination prefix. Wildcard messages are family and with any destination prefix. Wildcard messages are
allowed in two places in the protocol: wildcard retractions are used allowed in two places in the protocol: wildcard retractions are used
to retract all of the routes previously advertised by a node on a to retract all of the routes previously advertised by a node on a
given interface, and wildcard Route Requests are used to request a given interface, and wildcard Route Requests are used to request a
full dump of the Route Table from a given node. Wildcard messages full dump of the Route Table from a given node. Wildcard messages
are intended to apply to all routes, including routes decorated with are intended to apply to all routes, including routes decorated with
additional data and AE values to be defined by future extensions, and additional data and AE values to be defined by future extensions, and
hence this specification extends wildcard operations to apply to all hence this specification extends wildcard operations to apply to all
routes, whatever the value of the source prefix. routes, whatever the value of the source prefix.
More precisely, a node receiving an Update with the AE field set to 0 More precisely, a node receiving an Update with the AE field set to 0
and the Metric field set to infinity (a wildcard retraction) MUST and the Metric field set to infinity (a wildcard retraction) MUST
apply the route acquisition procedure described in Section 3.5.4 of 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 [BABEL] to all of the routes that it has learned from the sending
node, whatever the value of the source prefix. A node MUST NOT send 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 a wildcard retraction with an attached source prefix, and a node that
receives a wildcard retraction with a source prefix MUST ignore it. receives a wildcard retraction with a source prefix MUST ignore it.
Similarly, a node that receives a route request with the AE field set Similarly, a node that receives a route request with the AE field set
to 0 (a wildcard route request) SHOULD send a full routing table to 0 (a wildcard route request) SHOULD send a full routing table
dump, including routes with a non-zero length source prefix. A node dump, including routes with a non-zero length source prefix. A node
MUST NOT send a wildcard request that carries a source prefix, and a MUST NOT send a wildcard request that carries a source prefix, and a
node receiving a wildcard request with a source prefix MUST ignore node receiving a wildcard request with a source prefix MUST ignore
it. 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 of its extensions). More precisely, if non-source-specific all previously standardised extensions). More precisely, if non-
routers and source-specific routers are mixed in a single routing source-specific routers and source-specific routers are mixed in a
domain, Babel's loop-avoidance properties are preserved, and, in single routing domain, Babel's loop-avoidance properties are
particular, no persistent routing loops will occur. preserved, and, in particular, no persistent routing loops will
occur.
However, this extension is encoded using mandatory sub-TLVs, However, this extension is encoded using mandatory sub-TLVs,
introduced in [BABEL], and therefore is not compatible with the older introduced in [BABEL], and therefore is not compatible with the older
version of the Babel Routing Protocol [RFC6126] which does not version of the Babel Routing Protocol [RFC6126] which does not
support such sub-TLVs. Consequently, this extension MUST NOT be used support such sub-TLVs. Consequently, this extension MUST NOT be used
with routers implementing RFC 6126, otherwise persistent routing with routers implementing RFC 6126, otherwise persistent routing
loops may occur. loops may occur.
6.1. Loop-avoidance 6.1. Loop-avoidance
skipping to change at page 8, line 13 skipping to change at page 8, line 13
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
In general, discarding source-specific routes by non-source-specific In general, the discarding of source-specific routes by non-source-
routers will cause route starvation. Intuitively, unless there are specific routers will cause route starvation. Intuitively, unless
enough non-source-specific routes in the network, non-source-specific there are enough non-source-specific routes in the network, non-
routers will suffer starvation, and discard packets for destinations source-specific routers will suffer starvation, and discard packets
that are only announced by source-specific routers. for destinations 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: This extension defines a new sub-TLV used to carry a source prefix:
the Source Prefix sub-TLV. It can be used within an Update, a Route the Source Prefix sub-TLV. It can be used within an Update, a Route
skipping to change at page 9, line 11 skipping to change at page 9, line 11
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 contents of the source prefix sub-TLV are interpreted according The contents of the Source Prefix sub-TLV are interpreted according
to the AE of the enclosing TLV. to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains
a Source Prefix sub-TLV, then the whole TLV MUST be ignored.
Similarly, if a TLV contains multiple Source Prefix sub-TLVs, then
the whole TLV MUST be ignored.
Note that this sub-TLV is a mandatory sub-TLV. Therefore, as Note that this sub-TLV is a mandatory sub-TLV. Therefore, as
described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if
that sub-TLV is not understood (or malformed). Otherwise, routing that sub-TLV is not understood (or malformed). Otherwise, routing
loops may occur (see Section 6.1). 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 as routes with non-source-specific Updates (see [BABEL]). A
wildcard retraction (Update with AE equal to 0) MUST NOT carry a wildcard retraction (Update with AE equal to 0) MUST NOT carry a
Source Prefix sub-TLV. Source Prefix sub-TLV.
Babel uses a stateful compression scheme to reduce the size taken by Babel uses a stateful compression scheme to reduce the size taken by
destination prefixes in update TLVs (see Section 4.5 of [BABEL]). destination prefixes in update TLVs (see Section 4.5 of [BABEL]).
The source prefix defined by this extension is not compressed. On The source prefix defined by this extension is not compressed. On
the other hand, compression is allowed for the destination prefixes the other hand, compression is allowed for the destination prefixes
carried by source-specific updates. As described in Section 4.5 of carried by source-specific updates. As described in Section 4.5 of
[BABEL], unextended implementations will correctly update their [BABEL], unextended implementations will correctly update their
parser state while otherwise ignoring the whole TLV. parser state while otherwise ignoring the 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, as described in given pair of destination and source prefixes, as described in
Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with
AE equals to 0) MUST NOT carry a Source Prefix sub-TLV. AE equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard
request with a Source Prefix sub-TLV is received, then the request
MUST be ignored.
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 requests the receiving node to perform the Prefix sub-TLV. It requests the receiving node to perform the
procedure described in Section 3.8.1.2 of [BABEL], but applied to a procedure described in Section 3.8.1.2 of [BABEL], but applied to a
pair of a destination and source prefix. pair of a destination and source prefix.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 10, line 21 skipping to change at page 10, line 23
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, and does not in TLVs already present in the original Babel protocol, and does not in
itself change the security properties of the protocol. However, itself change the security properties of the protocol. However,
source-specific routing gives more control over routing to the source-specific routing gives more control over routing to the
sending hosts, which might have security implications (see Section 8 sending hosts, which might have security implications (see Section 8
of [DSR]). of [DSR]).
10. Acknowledgments 10. Acknowledgments
The authors are grateful to Joel Halpern for his help with this The authors are grateful to Donald Eastlake and Joel Halpern for
document. their help with this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet
Draft draft-ietf-babel-rfc6126bis-06, October 2018. Draft draft-ietf-babel-rfc6126bis-06, October 2018.
[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.
 End of changes. 17 change blocks. 
28 lines changed or deleted 34 lines changed or added

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