draft-ietf-babel-rfc6126bis-19.txt   draft-ietf-babel-rfc6126bis-20.txt 
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Obsoletes: 6126,7557 (if approved) D. Schinazi Obsoletes: 6126,7557 (if approved) D. Schinazi
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: February 7, 2021 August 6, 2020 Expires: February 26, 2021 August 25, 2020
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-19 draft-ietf-babel-rfc6126bis-20
Abstract Abstract
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless robust and efficient both in ordinary wired networks and in wireless
mesh networks. This document describes the Babel routing protocol, mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557. and obsoletes RFCs 6126 and 7557.
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 February 7, 2021. This Internet-Draft will expire on February 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 18 3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 18
3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 21 3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 21
3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 25 3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 25
3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 26 3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 26
3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 28 3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 28
4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 32 4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33
4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 34 4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 34
4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 35 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 35
4.5. Parser state and encoding of updates . . . . . . . . . . 35 4.5. Parser state and encoding of updates . . . . . . . . . . 36
4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 37 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 37
4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 48 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 52 6. Security Considerations . . . . . . . . . . . . . . . . . . . 52
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. Normative References . . . . . . . . . . . . . . . . . . 53 8.1. Normative References . . . . . . . . . . . . . . . . . . 53
8.2. Informative References . . . . . . . . . . . . . . . . . 54 8.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Cost and Metric Computation . . . . . . . . . . . . 56 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 56
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 56 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 56
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 57 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 57
A.3. Route selection and hysteresis . . . . . . . . . . . . . 59 A.3. Route selection and hysteresis . . . . . . . . . . . . . 59
Appendix B. Protocol parameters . . . . . . . . . . . . . . . . 59 Appendix B. Protocol parameters . . . . . . . . . . . . . . . . 60
Appendix C. Route filtering . . . . . . . . . . . . . . . . . . 60 Appendix C. Route filtering . . . . . . . . . . . . . . . . . . 61
Appendix D. Considerations for protocol extensions . . . . . . . 61 Appendix D. Considerations for protocol extensions . . . . . . . 61
Appendix E. Stub Implementations . . . . . . . . . . . . . . . . 63 Appendix E. Stub Implementations . . . . . . . . . . . . . . . . 63
Appendix F. Compatibility with previous versions . . . . . . . . 64 Appendix F. Compatibility with previous versions . . . . . . . . 64
Appendix G. Changes from previous versions . . . . . . . . . . . 65 Appendix G. Changes from previous versions . . . . . . . . . . . 65
G.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 65 G.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 65
G.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 65 G.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 65
G.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 65 G.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 65
G.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 66 G.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 66
G.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 66 G.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 66
G.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 67 G.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 67
G.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 67 G.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 67
G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67 G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67
G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67 G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67
G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67 G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67
G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67 G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67
G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 67 G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 68
G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 68 G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 68
G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 68 G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 68
G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 68 G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 68
G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 68 G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 69
G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 69 G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 69
G.18. Changes since draft-ietf-babel-rfc6126bis-15 . . . . . . 69 G.18. Changes since draft-ietf-babel-rfc6126bis-15 . . . . . . 69
G.19. Changes since draft-ietf-babel-rfc6126bis-16 . . . . . . 69 G.19. Changes since draft-ietf-babel-rfc6126bis-16 . . . . . . 69
G.20. Changes since draft-ietf-babel-rfc6126bis-17 . . . . . . 69 G.20. Changes since draft-ietf-babel-rfc6126bis-17 . . . . . . 69
G.21. Changes since draft-ietf-babel-rfc6126bis-18 . . . . . . 69 G.21. Changes since draft-ietf-babel-rfc6126bis-18 . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 G.22. Changes since draft-ietf-babel-rfc6126bis-19 . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix- designed to be robust and efficient both in networks using prefix-
based routing and in networks using flat routing ("mesh networks"), based routing and in networks using flat routing ("mesh networks"),
and both in relatively stable wired networks and in highly dynamic and both in relatively stable wired networks and in highly dynamic
wireless networks. This document describes the Babel routing wireless networks. This document describes the Babel routing
protocol, and obsoletes [RFC6126] and [RFC7557]. protocol, and obsoletes [RFC6126] and [RFC7557].
skipping to change at page 25, line 43 skipping to change at page 25, line 43
shortest paths (assuming that the metric is left-distributive, see shortest paths (assuming that the metric is left-distributive, see
Section 3.5.2). There are two reasons, however, why this strategy Section 3.5.2). There are two reasons, however, why this strategy
may lead to instability in the presence of continuously varying may lead to instability in the presence of continuously varying
metrics. First, if two parallel routes oscillate around a common metrics. First, if two parallel routes oscillate around a common
value, then the smallest metric strategy will keep switching between value, then the smallest metric strategy will keep switching between
the two. Second, when a route is selected, congestion along it the two. Second, when a route is selected, congestion along it
increases, which might increase packet loss, which in turn could increases, which might increase packet loss, which in turn could
cause its metric to increase; this is a feedback loop, of the kind cause its metric to increase; this is a feedback loop, of the kind
that is prone to causing persistent oscillations. that is prone to causing persistent oscillations.
In order to limit this kind of instabilities, a route selection In order to limit these kinds of instabilities, a route selection
strategy SHOULD include some form of hysteresis, i.e., be sensitive strategy SHOULD include some form of hysteresis, i.e., be sensitive
to a route's history: if a route is currently selected, then the to a route's history: if a route is currently selected, then the
strategy should only switch to a different route if the latter has strategy should only switch to a different route if the latter has
been consistently good for some period of time. A RECOMMENDED been consistently good for some period of time. A RECOMMENDED
hysteresis algorithm is given in Appendix A.3. hysteresis algorithm is given in Appendix A.3.
After the route selection procedure is run, triggered updates After the route selection procedure is run, triggered updates
(Section 3.7.2) and requests (Section 3.8.2) are sent. (Section 3.7.2) and requests (Section 3.8.2) are sent.
3.7. Sending Updates 3.7. Sending Updates
skipping to change at page 27, line 29 skipping to change at page 27, line 29
unlike a routing loop, does not endanger the integrity of the unlike a routing loop, does not endanger the integrity of the
network. When a route is retracted, a node SHOULD send a triggered network. When a route is retracted, a node SHOULD send a triggered
update and SHOULD make a reasonable attempt at ensuring that all update and SHOULD make a reasonable attempt at ensuring that all
neighbours receive this retraction. neighbours receive this retraction.
Finally, a node MAY send a triggered update when the metric for a Finally, a node MAY send a triggered update when the metric for a
given prefix changes in a significant manner, due to a received given prefix changes in a significant manner, due to a received
update, because a link's cost has changed, or because a different update, because a link's cost has changed, or because a different
next hop has been selected. A node SHOULD NOT send triggered updates next hop has been selected. A node SHOULD NOT send triggered updates
for other reasons, such as when there is a minor fluctuation in a for other reasons, such as when there is a minor fluctuation in a
route's metric, when the selected next hop changes, or to propagate a route's metric, when the selected next hop changes without inducing a
new sequence number (except to satisfy a request, as specified in significant change to the route's metric, or to propagate a new
sequence number (except to satisfy a request, as specified in
Section 3.8). Section 3.8).
3.7.3. Maintaining Feasibility Distances 3.7.3. Maintaining Feasibility Distances
Before sending an update (prefix, plen, router-id, seqno, metric) Before sending an update (prefix, plen, router-id, seqno, metric)
with finite metric (i.e., not a route retraction), a Babel node with finite metric (i.e., not a route retraction), a Babel node
updates the feasibility distance maintained in the source table. updates the feasibility distance maintained in the source table.
This is done as follows. This is done as follows.
If no entry indexed by (prefix, plen, router-id) exists in the source If no entry indexed by (prefix, plen, router-id) exists in the source
skipping to change at page 32, line 35 skipping to change at page 32, line 35
over IPv6). It MUST NOT send packets larger than the attached over IPv6). It MUST NOT send packets larger than the attached
interface's MTU adjusted for lower-layer headers or 512 octets, interface's MTU adjusted for lower-layer headers or 512 octets,
whichever is larger, but not exceeding 2^16 - 1 adjusted for lower- whichever is larger, but not exceeding 2^16 - 1 adjusted for lower-
layer headers. Every Babel speaker MUST be able to receive packets layer headers. Every Babel speaker MUST be able to receive packets
that are as large as any attached interface's MTU adjusted for lower- that are as large as any attached interface's MTU adjusted for lower-
layer headers or 512 octets, whichever is larger. Babel packets MUST layer headers or 512 octets, whichever is larger. Babel packets MUST
NOT be sent in IPv6 Jumbograms [RFC2675]. NOT be sent in IPv6 Jumbograms [RFC2675].
4.1. Data Types 4.1. Data Types
4.1.1. Interval 4.1.1. Representation of integers
All multi-octet fields that represent integers are encoded with the
most significant octet first (in Big-Endian format [IEN137], also
called Network Order). The base protocol only carries unsigned
values; if an extension needs to carry signed values, it will need to
specify their encoding (e.g., two's complement).
4.1.2. Interval
Relative times are carried as 16-bit values specifying a number of Relative times are carried as 16-bit values specifying a number of
centiseconds (hundredths of a second). This allows times up to centiseconds (hundredths of a second). This allows times up to
roughly 11 minutes with a granularity of 10ms, which should cover all roughly 11 minutes with a granularity of 10ms, which should cover all
reasonable applications of Babel (see also Appendix B). reasonable applications of Babel (see also Appendix B).
4.1.2. Router-Id 4.1.3. Router-Id
A router-id is an arbitrary 8-octet value. A router-id MUST NOT A router-id is an arbitrary 8-octet value. A router-id MUST NOT
consist of either all binary zeroes (0000000000000000 hexadecimal) or consist of either all binary zeroes (0000000000000000 hexadecimal) or
all binary ones (FFFFFFFFFFFFFFFF hexadecimal). all binary ones (FFFFFFFFFFFFFFFF hexadecimal).
4.1.3. Address 4.1.4. Address
Since the bulk of the protocol is taken by addresses, multiple ways Since the bulk of the protocol is taken by addresses, multiple ways
of encoding addresses are defined. Additionally, within Update TLVs of encoding addresses are defined. Additionally, within Update TLVs
a common subnet prefix may be omitted when multiple addresses are a common subnet prefix may be omitted when multiple addresses are
sent in a single packet -- this is known as address compression sent in a single packet -- this is known as address compression
(Section 4.6.9). (Section 4.6.9).
Address encodings: Address encodings:
o AE 0: wildcard address. The value is 0 octets long. o AE 0: wildcard address. The value is 0 octets long.
skipping to change at page 33, line 28 skipping to change at page 33, line 34
o AE 2: IPv6 address. Compression is allowed. 16 octets or less. o AE 2: IPv6 address. Compression is allowed. 16 octets or less.
o AE 3: link-local IPv6 address. Compression is not allowed. The o AE 3: link-local IPv6 address. Compression is not allowed. The
value is 8 octets long, a prefix of fe80::/64 is implied. value is 8 octets long, a prefix of fe80::/64 is implied.
The address family associated to an address encoding is either IPv4 The address family associated to an address encoding is either IPv4
or IPv6; it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AEs 2 or IPv6; it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AEs 2
and 3. and 3.
4.1.4. Prefixes 4.1.5. Prefixes
A network prefix is encoded just like a network address, but it is A network prefix is encoded just like a network address, but it is
stored in the smallest number of octets that are enough to hold the stored in the smallest number of octets that are enough to hold the
significant bits (up to the prefix length). significant bits (up to the prefix length).
4.2. Packet Format 4.2. Packet Format
A Babel packet consists of a 4-octet header, followed by a sequence A Babel packet consists of a 4-octet header, followed by a sequence
of TLVs (the packet body), optionally followed by a second sequence of TLVs (the packet body), optionally followed by a second sequence
of TLVs (the packet trailer). The format is designed to be of TLVs (the packet trailer). The format is designed to be
skipping to change at page 36, line 20 skipping to change at page 36, line 37
o the next hop is taken either from the source-address of the o the next hop is taken either from the source-address of the
network-layer packet that contains the Babel packet, or from an network-layer packet that contains the Babel packet, or from an
explicit Next-Hop TLV (Section 4.6.8). explicit Next-Hop TLV (Section 4.6.8).
In addition to the above, an Update TLV can omit a prefix of the In addition to the above, an Update TLV can omit a prefix of the
prefix being announced, which is then extracted from the preceding prefix being announced, which is then extracted from the preceding
Update TLV in the same address family (IPv4 or IPv6). Finally, as a Update TLV in the same address family (IPv4 or IPv6). Finally, as a
special optimisation for the case when a router-id coincides with the special optimisation for the case when a router-id coincides with the
interface-id part of an IPv6 address, Router-ID TLV itself may be interface-id part of an IPv6 address, Router-ID TLV itself may be
omitted and the router-id derived derived from the low-order bits of omitted and the router-id derived from the low-order bits of the
the advertised prefix (Section 4.6.9). advertised prefix (Section 4.6.9).
In order to implement these compression techniques, Babel uses a In order to implement these compression techniques, Babel uses a
stateful parser: a TLV may refer to data from a previous TLV. The stateful parser: a TLV may refer to data from a previous TLV. The
parser state consists of the following pieces of data: parser state consists of the following pieces of data:
o for each address encoding that allows compression, the current o for each address encoding that allows compression, the current
default prefix; this is undefined at the start of the packet, and default prefix; this is undefined at the start of the packet, and
is updated by each Update TLV with the Prefix flag set is updated by each Update TLV with the Prefix flag set
(Section 4.6.9); (Section 4.6.9);
skipping to change at page 55, line 26 skipping to change at page 55, line 26
[IEEE802.11] [IEEE802.11]
IEEE, "IEEE Standard for Information technology-- IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", (MAC) and Physical Layer (PHY) Specifications",
IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April
2012. 2012.
[IEN137] Cohen, D., "On holy wars and a plea for peace", IEN 137,
April 1980.
[IS-IS] Standardization, I. O. F., "Information technology -- [IS-IS] Standardization, I. O. F., "Information technology --
Telecommunications and information exchange between Telecommunications and information exchange between
systems -- Intermediate System to Intermediate System systems -- Intermediate System to Intermediate System
intra-domain routeing information exchange protocol for intra-domain routeing information exchange protocol for
use in conjunction with the protocol for providing the use in conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", ISO/ connectionless-mode network service (ISO 8473)", ISO/
IEC 10589:2002, 2002. IEC 10589:2002, 2002.
[JITTER] Floyd, S. and V. Jacobson, "The synchronization of [JITTER] Floyd, S. and V. Jacobson, "The synchronization of
periodic routing messages", IEEE/ACM Transactions on periodic routing messages", IEEE/ACM Transactions on
skipping to change at page 59, line 28 skipping to change at page 59, line 33
Route selection (Section 3.6) is the process by which a node selects Route selection (Section 3.6) is the process by which a node selects
a single route among the routes that it has available towards a given a single route among the routes that it has available towards a given
destination. With Babel, any route selection procedure that only destination. With Babel, any route selection procedure that only
ever chooses feasible routes with a finite metric will yield a set of ever chooses feasible routes with a finite metric will yield a set of
loop-free routes; however, in the presence of continuously variable loop-free routes; however, in the presence of continuously variable
metrics such as ETX (Appendix A.2.2), a naive route selection metrics such as ETX (Appendix A.2.2), a naive route selection
procedure might lead to persistent oscillations. Such oscillations procedure might lead to persistent oscillations. Such oscillations
can be limited or avoided altogether by implementing hysteresis can be limited or avoided altogether by implementing hysteresis
within the route selection algorithm, i.e., by making the route within the route selection algorithm, i.e., by making the route
selection algorithm sensitive to a route's history. Any reasonable selection algorithm sensitive to a route's history. Any reasonable
hysteresis algorithm should yield good results ; the following hysteresis algorithm should yield good results; the following
algorithm is simple to implement and has been successfully deployed algorithm is simple to implement and has been successfully deployed
in a variety of environments. in a variety of environments.
For every route R, in addition to the route's metric m(R), maintain a For every route R, in addition to the route's metric m(R), maintain a
smoothed version of m(R) written ms(R) (we RECOMMEND computing ms(R) smoothed version of m(R) written ms(R) (we RECOMMEND computing ms(R)
as an exponentially smoothed average (see Section 3.7 of [RFC793]) of as an exponentially smoothed average (see Section 3.7 of [RFC793]) of
m(R) with a time constant equal to the Hello interval multiplied by a m(R) with a time constant equal to the Hello interval multiplied by a
small number such as 3). If no route to a given destination is small number such as 3). If no route to a given destination is
selected, then select the route with the smallest metric, ignoring selected, then select the route with the smallest metric, ignoring
the smoothed metric. If a route R is selected, then switch to a the smoothed metric. If a route R is selected, then switch to a
skipping to change at page 65, line 4 skipping to change at page 65, line 6
There are other changes, but these are not of a nature to prevent There are other changes, but these are not of a nature to prevent
interoperability: interoperability:
o the conditions on route acquisition (Section 3.5.3) have been o the conditions on route acquisition (Section 3.5.3) have been
relaxed; relaxed;
o route selection should no longer use the route's sequence number o route selection should no longer use the route's sequence number
(Section 3.6); (Section 3.6);
o the format of the packet trailer has been defined (Section 4.2); o the format of the packet trailer has been defined (Section 4.2);
o router-ids with a value of all-zeros or all-ones have been o router-ids with a value of all-zeros or all-ones have been
forbidden (Section 4.1.2); forbidden (Section 4.1.3);
o the compression state is now specific to an address family rather o the compression state is now specific to an address family rather
than an address encoding (Section 4.5); than an address encoding (Section 4.5);
o packet pacing is now recommended (Section 3.1). o packet pacing is now recommended (Section 3.1).
Appendix G. Changes from previous versions Appendix G. Changes from previous versions
[RFC Editor: Please delete this section before publication.] [RFC Editor: Please delete this section before publication.]
skipping to change at page 69, line 46 skipping to change at page 70, line 10
o 2-out-of-3 cost computation is now RECOMMENDED on LANs. o 2-out-of-3 cost computation is now RECOMMENDED on LANs.
o Reference to RFC 793 Section 3.7 added as exponential smoothing o Reference to RFC 793 Section 3.7 added as exponential smoothing
example. example.
G.21. Changes since draft-ietf-babel-rfc6126bis-18 G.21. Changes since draft-ietf-babel-rfc6126bis-18
o Reserved Address Encodings 224-254 for Experimental Use, and 255 o Reserved Address Encodings 224-254 for Experimental Use, and 255
for future expansion. for future expansion.
G.22. Changes since draft-ietf-babel-rfc6126bis-19
o Mention that multi-octet fields are in big-endian.
o Minor typos and clarifications.
Authors' Addresses Authors' Addresses
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
David Schinazi David Schinazi
Google LLC Google LLC
 End of changes. 21 change blocks. 
21 lines changed or deleted 42 lines changed or added

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