draft-ietf-babel-information-model-03.txt   draft-ietf-babel-information-model-04.txt 
Babel routing protocol B. Stark Babel routing protocol B. Stark
Internet-Draft AT&T Internet-Draft AT&T
Intended status: Informational June 5, 2018 Intended status: Informational October 22, 2018
Expires: December 7, 2018 Expires: April 25, 2019
Babel Information Model Babel Information Model
draft-ietf-babel-information-model-03 draft-ietf-babel-information-model-04
Abstract Abstract
This Babel Information Model can be used to create data models under This Babel Information Model can be used to create data models under
various data modeling regimes (e.g., YANG). It allows a Babel various data modeling regimes (e.g., YANG). It allows a Babel
implementation (via a management protocol such as netconf) to report implementation (via a management protocol such as NETCONF) to report
on its current state and may allow some limited configuration of on its current state and may allow some limited configuration of
protocol constants. protocol constants.
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 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 December 7, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Information Model . . . . . . . . . . . . . . . . . . . . 5 3. The Information Model . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition of babel-information-obj . . . . . . . . . . . 5 3.1. Definition of babel-information-obj . . . . . . . . . . . 5
3.2. Definition of babel-constants-obj . . . . . . . . . . . . 6 3.2. Definition of babel-constants-obj . . . . . . . . . . . . 6
3.3. Definition of babel-interfaces-obj . . . . . . . . . . . 6 3.3. Definition of babel-interfaces-obj . . . . . . . . . . . 7
3.4. Definition of babel-neighbors-obj . . . . . . . . . . . . 8 3.4. Definition of babel-neighbors-obj . . . . . . . . . . . . 8
3.5. Definition of babel-security-obj . . . . . . . . . . . . 9 3.5. Definition of babel-security-obj . . . . . . . . . . . . 10
3.6. Definition of babel-routes-obj . . . . . . . . . . . . . 11 3.6. Definition of babel-routes-obj . . . . . . . . . . . . . 11
4. Common Objects . . . . . . . . . . . . . . . . . . . . . . . 12 4. Common Objects . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Definition of babel-credential-obj . . . . . . . . . . . 12 4.1. Definition of babel-credential-obj . . . . . . . . . . . 12
4.2. Definition of babel-log-obj . . . . . . . . . . . . . . . 12 4.2. Definition of babel-log-obj . . . . . . . . . . . . . . . 13
5. Extending the Information Model . . . . . . . . . . . . . . . 12 5. Extending the Information Model . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol defined in Babel is a loop-avoiding distance-vector routing protocol defined in
draft-ietf-babel-rfc6126bis [rfc6126bis]. draft-babel-7298bis [I-D.ietf-babel-rfc6126bis]. [I-D.ietf-babel-hmac] defines a
[BABEL-HMAC] defines a security mechanism that allows Babel messages security mechanism that allows Babel messages to be cryptographically
to be cryptographically authenticated, and draft-babel-dtls authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism
[BABEL-DTLS] defines a security mechanism that allows Babel messages that allows Babel messages to be encrypted. This document describes
to encrypted. This document describes an information model for Babel an information model for Babel (including implementations using one
(including implementations using one of these security mechanisms) of these security mechanisms) that can be used to create management
that can be used to created management protocol data models (such as protocol data models (such as a NETCONF [RFC6241] YANG [RFC7950] data
a netconf [RFC6241] YANG data model). model).
Due to the simplicity of the Babel protocol, most of the information Due to the simplicity of the Babel protocol, most of the information
model is focused on reporting status of the Babel protocol, and very model is focused on reporting Babel protocol operational state, and
little of that is considered mandatory to implement (conditional on a very little of that is considered mandatory to implement (contingent
management protocol with Babel support being implemented). Some on a management protocol with Babel support being implemented). Some
parameters may be configurable; however, it is up to the Babel parameters may be configurable. However, it is up to the Babel
implementation whether to allow any of these to be configured within implementation whether to allow any of these to be configured within
its implementation. Where the implementation does not allow its implementation. Where the implementation does not allow
configuration of these parameters, it may still choose to expose them configuration of these parameters, it may still choose to expose them
as read-only. as read-only.
The Information Model is presented using a hierarchical structure. The Information Model is presented using a hierarchical structure.
This does not preclude a data model based on this Information Model This does not preclude a data model based on this Information Model
from using a referential or other structure. from using a referential or other structure.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in [RFC2119] and updated
updated by RFC 8174 [RFC8174] . by [RFC8174].
1.2. Notation 1.2. Notation
This document uses a programming language-like notation to define the This document uses a programming language-like notation to define the
properties of the objects of the information model. An optional properties of the objects of the information model. An optional
property is enclosed by square brackets, [ ], and a list property is property is enclosed by square brackets, [ ], and a list property is
indicated by two numbers in angle brackets, <m..n>, where m indicates indicated by two numbers in angle brackets, <m..n>, where m indicates
the minimal number of values, and n is the maximum. The symbol * for the minimal number of list elements, and n indicates the maximum
n means no upper bound. number of list elements. The symbol * for n means there are no
defined limits on the number of list elements. Each parameter and
object includes an indication of "ro" or "rw". "ro" means the
parameter or object is read-only. "rw" means it is read-write. For
an object, read-write means instances of the object can be created or
deleted. If an implementation is allowed to choose to implement a
"rw" parameter as read-only, this is noted in the parameter
description.
The object definitions use base types that are defined as follows: The object definitions use base types that are defined as follows:
base64 An opaque array of bytes. binary A binary string (sequence of octets).
boolean A type representing a boolean value. boolean A type representing a boolean value.
counter A non-negative integer that monotonically increases. counter A non-negative integer that monotonically increases.
Counters may have discontinuities and they are not Counters may have discontinuities and they are not
expected to persist across restarts. expected to persist across restarts.
credentials An opaque type representing credentials needed by a credentials An opaque type representing credentials needed by a
cryptographic mechanism to secure communication. Data cryptographic mechanism to secure communication. Data
models must expand this opaque type as needed and models must expand this opaque type as needed and
skipping to change at page 4, line 24 skipping to change at page 4, line 29
The Information Model is hierarchically structured as follows: The Information Model is hierarchically structured as follows:
information object information object
includes implementation version, router id, this node seqno, includes implementation version, router id, this node seqno,
enable flag parameters, supported security mechanisms enable flag parameters, supported security mechanisms
constants object (exactly one per information object) constants object (exactly one per information object)
includes UDP port and optional multicast group includes UDP port and optional multicast group
parameters parameters
interfaces object interfaces object
includes interface reference, Hello seqno and intervals, includes interface reference, Hello seqno and intervals,
update interval, link type, external cost parameters update interval, link type, metric computation parameters
neighbors object neighbors object
includes neighbor IP address, Hello history, cost includes neighbor IP address, Hello history, cost
parameters parameters
security object (per interface) security object (per interface)
includes enable flag, self credentials (credential includes enable flag, self credentials (credential
object), trusted credentials (credential object) object), trusted credentials (credential object)
security object (common to all interfaces) security object (common to all interfaces)
includes enable flag, self credentials (credential includes enable flag, self credentials (credential
object), trusted credentials (credential object) object), trusted credentials (credential object)
routes object routes object
includes route prefix, source router, reference to includes route prefix, source router, reference to
advertising neighbor, metric, sequence number, whether advertising neighbor, metric, sequence number, whether
route is feasible, whether route is selected route is feasible, whether route is selected
Following is a list of the data elements that an implementation can Most parameters are read-only. Following is a list of the parameters
choose to allow to be configurable: that are not required to be read-only:
o enable/disable babel o enable/disable Babel
o Constant: UDP port o Constant: UDP port
o Constant: IPv6 multicast group o Constant: IPv6 multicast group
o Interface: Link type o Interface: Link type
o Interface: External cost (must be configurable if implemented, but o Interface: External cost (must be configurable if implemented, but
implementation is optional) implementation is optional)
o Interface: enable/disable babel on this interface o Interface: enable/disable Babel on this interface
o Interface: enable/disable message log o Interface: enable/disable message log
o Security: enable/disable this security mechanism o Security: enable/disable this security mechanism
o Security: self credentials o Security: self credentials
o Security: trusted credentials o Security: trusted credentials
o Security: enable/disable security log o Security: enable/disable security log
Note that this overview is intended simply to be informative and is Note that this overview is intended simply to be informative and is
not normative. If there is any discrepancy between this overview and not normative. If there is any discrepancy between this overview and
the detailed information model definitions in subsequent sections, the detailed information model definitions in subsequent sections,
the error is in this overview. the error is in this overview.
3. The Information Model 3. The Information Model
3.1. Definition of babel-information-obj 3.1. Definition of babel-information-obj
object { object {
string babel-implementation-version; string ro babel-implementation-version;
boolean babel-enable; boolean rw babel-enable;
base64 babel-self-router-id; binary ro babel-self-router-id;
string babel-supported-link-types<1..*>; string ro babel-supported-link-types<1..*>;
[int babel-self-seqno;] [int ro babel-self-seqno;]
string babel-metric-comp-algorithms<1..*>; string ro babel-metric-comp-algorithms<1..*>;
string babel-security-supported<0..*>; string ro babel-security-supported<0..*>;
babel-constants-obj babel-constants; babel-constants-obj ro babel-constants;
babel-interfaces-obj babel-interfaces<0..*>; babel-interfaces-obj ro babel-interfaces<0..*>;
babel-routes-obj babel-routes<0..*>; babel-routes-obj ro babel-routes<0..*>;
babel-security-obj babel-security<0..*>; babel-security-obj ro babel-security<0..*>;
}babel-information-obj; } babel-information-obj;
babel-implementation-version: the version of this implementation babel-implementation-version: The name and version of this
of the Babel protocol implementation of the Babel protocol.
babel-enable: if true, the babel implementation is running; if babel-enable: When written, it configures whether the protocol shoud
false, the babel implementation is not currently running; MAY be be enabled (true) or disabled (false). A read from the running or
configurable to allow babel to be started or stopped intended datastore indicates the configured administrative value
of whether the protocol is enabled (true) or not (false). A read
from the operational datastore indicates whether the protocol is
actually running (true) or not (i.e., it indicates the operational
state of the protocol). A data model that does not replicate
parameters for running and operational datastores can implement
this as two separate parameters. An implementation MAY choose to
expose this parameter as read-only ("ro").
babel-self-router-id: the router-id used by this instance of the babel-self-router-id: The router-id used by this instance of the
Babel protocol to identify itself; draft-ietf-babel-rfc6126bis Babel protocol to identify itself. [I-D.ietf-babel-rfc6126bis]
[rfc6126bis] describes this as an arbitrary string of 8 octets describes this as an arbitrary string of 8 octets.
babel-supported-link-types: set of values of supported link types
where the following enumeration values MUST be supported when
applicable: "ethernet", "wireless", "tunnel", and "other"
babel-self-seqno: the current sequence number included in route babel-supported-link-types: Lists the set of link types supported by
updates for routes originated by this node this instance of Babel. Valid enumeration values are defined in
the Babel Link Types registry (see Section 7).
babel-metric-comp-algorithms: a set of names of supported cost babel-self-seqno: The current sequence number included in route
computation algorithms; possible values include "k-out-of-j", updates for routes originated by this node.
"ETX"
babel-security-supported: list of supported security mechanisms; babel-metric-comp-algorithms: List of supported cost computation
as babel security mechanisms are defined, they will need to algorithms. Possible values include "k-out-of-j", and "ETX".
indicate what enumeration value is to be used to represent them in
this parameter
babel-constants: a babel-constants-obj object babel-security-supported: List of supported security mechanisms. As
Babel security mechanisms are defined, they will need to indicate
what enumeration value is to be used to represent them in this
parameter.
babel-interfaces: a set of babel-interface-obj objects babel-constants: A babel-constants-obj object.
babel-security: a babel-security-obj object that applies to all babel-interfaces: A set of babel-interface-obj objects.
interfaces; if this object is implemented, it allows a security
babel-security: A babel-security-obj object that applies to all
interfaces. If this object is implemented, it allows a security
mechanism to be enabled or disabled in a manner that applies to mechanism to be enabled or disabled in a manner that applies to
all Babel messages on all interfaces all Babel messages on all interfaces.
babel-routes: a set of babel-route-obj objects; includes received babel-routes: A set of babel-route-obj objects. Contains the routes
and routes routes known to this node.
3.2. Definition of babel-constants-obj 3.2. Definition of babel-constants-obj
object { object {
int babel-udp-port; int rw babel-udp-port;
[ip-address babel-mcast-group-ipv6;] [ip-address rw babel-mcast-group;]
}babel-constants-obj; } babel-constants-obj;
babel-udp-port: UDP port for sending and listening for Babel babel-udp-port: UDP port for sending and listening for Babel
messages; default is 6696; MAY be configurable messages. Default is 6696. An implementation MAY choose to
expose this parameter as read-only ("ro").
babel-mcast-group-ipv6: multicast group for sending and listening babel-mcast-group: Multicast group for sending and listening to
to multicast announcements on IPv6; default is ff02:0:0:0:0:0:1:6; multicast announcements on IPv6. Default is ff02:0:0:0:0:0:1:6.
MAY be configurable An implementation MAY choose to expose this parameter as read-only
("ro").
3.3. Definition of babel-interfaces-obj 3.3. Definition of babel-interfaces-obj
object {
string babel-interface-reference;
[boolean babel-interface-enable;]
int babel-link-type;
[int babel-mcast-hello-seqno;]
[int babel-ucast-hello-seqno;]
[int babel-mcast-hello-interval;]
[int babel-ucast-hello-interval;]
[int babel-update-interval;]
[int babel-external-cost;]
[boolean babel-message-log-enable;]
[babel-log-obj babel-message-log<0..*>;]
babel-neighbors-obj babel-neighbors<0..*>;
[babel-security-obj babel-interface-security<0..*>;]
}babel-interfaces-obj;
babel-interface-reference: reference to an interface object as object {
defined by the data model (e.g., YANG, BBF TR-181); data model is string ro babel-interface-reference;
assumed to allow for referencing of interface objects which may be [boolean rw babel-interface-enable;]
at any layer (physical, Ethernet MAC, IP, tunneled IP, etc.); int rw babel-link-type;
referencing syntax will be specific to the data model; if there is string ro babel-interface-metric-algorithm;
no set of interface objects available, this should be a string [int ro babel-mcast-hello-seqno;]
that indicates the interface name used by the underlying operating [int ro babel-mcast-hello-interval;]
system [int ro babel-update-interval;]
[boolean rw babel-message-log-enable;]
[babel-log-obj ro babel-message-log<0..*>;]
babel-neighbors-obj ro babel-neighbors<0..*>;
[babel-security-obj ro babel-interface-security<0..*>;]
} babel-interfaces-obj;
babel-interface-enable: if true, babel sends and receives messages babel-interface-reference: Reference to an interface object as
on this interface; if false, babel messages received on this defined by the data model (e.g., YANG [RFC7950], BBF [TR-181]).
interface are ignored and none are sent; MAY be configurable Data model is assumed to allow for referencing of interface
objects which may be at any layer (physical, Ethernet MAC, IP,
tunneled IP, etc.). referencing syntax will be specific to the
data model. If there is no set of interface objects available,
this should be a string that indicates the interface name used by
the underlying operating system.
babel-link-type: indicates the type of link; set of values of babel-interface-enable: When written, it configures whether the
supported link types where the following enumeration values MUST protocol should be enabled (true) or disabled (false) on this
be supported when applicable: "ethernet", "wireless", "tunnel", interface. A read from the running or intended datastore
and "other"; additional values MAY be supported; MAY be indicates the configured administrative value of whether the
configurable protocol is enabled (true) or not (false). A read from the
operational datastore indicates whether the protocol is actually
running (true) or not (i.e., it indicates the operational state of
the protocol). A data model that does not replicate parameters
for running and operational datastores can implement this as two
separate parameters. An implementation MAY choose to expose this
parameter as read-only ("ro").
babel-mcast-hello-seqno: the current sequence number in use for babel-link-type: Indicates the type of link. Valid enumeration
multicast hellos sent on this interface values are identified in Babel Link Types registry. An
implementation MAY choose to expose this parameter as read-only
("ro").
babel-ucast-hello-seqno: the current sequence number in use for babel-interface-metric-algorithm: Indicates the metric computation
unicast hellos sent on this interface algorithm used on this interface. The value MUST be one of those
listed in the babel-information-obj babel-metric-comp-algorithms
parameter.
babel-mcast-hello-interval: the current multicast hello interval babel-mcast-hello-seqno: The current sequence number in use for
in use for hellos sent on this interface multicast hellos sent on this interface.
babel-ucast-hello-interval: the current unicast hello interval in babel-mcast-hello-interval: The current interval in use for
use for hellos sent on this interface multicast hellos sent on this interface.
babel-update-interval: the current update interval in use for this
interface
babel-external-cost: external input to cost of link of this babel-update-interval: The current interval in use for all updates
interface; if supported, this is a value that is added to the (multicast and unicast) sent on this interface.
metrics of routes learned over this interface; how an
implementation uses the value is up to the implementation, which
means the use may not be consistent across implementations; MUST
be configurable if implemented
babel-message-log-enable: if true, logging of babel messages babel-message-log-enable: When written, it configures whether
received on this interface is enabled; if false, babel messages logging should be enabled (true) or disabled (false). A read from
are not logged; MUST be configurable, if implemented the running or intended datastore indicates the configured
administrative value of whether logging is enabled (true) or not
(false). A read from the operational datastore indicates whether
logging is actually running (true) or not (i.e., it indicates the
operational state). A data model that does not replicate
parameters for running and operational datastores can implement
this as two separate parameters. An implementation MAY choose to
expose this parameter as read-only ("ro").
babel-message-log: log entries that have timestamp of a received babel-message-log: Log entries that have timestamp of a received
Babel message and the entire received Babel message (including Babel message and the entire received Babel message (including
Ethernet frame and IP headers, if possible); an implementation Ethernet frame and IP headers, if possible). An implementation
must restrict the size of this log, but how and what size is must restrict the size of this log, but how and what size is
implementation-specific implementation-specific. If this log is implemented, a mechanism
to clear it SHOULD be provided.
babel-neighbors: a set of babel-neighbors-obj objects babel-neighbors: A set of babel-neighbors-obj objects.
babel-interface-security: a babel-security-obj object that applies babel-interface-security: A babel-security-obj object that applies
to this interface; if implemented, this allows security to be to this interface. If implemented, this allows security to be
enabled only on specific interfaces or allows different security enabled only on specific interfaces or allows different security
mechanisms to be enabled on different interfaces mechanisms to be enabled on different interfaces.
3.4. Definition of babel-neighbors-obj 3.4. Definition of babel-neighbors-obj
object {
ip-address ro babel-neighbor-address;
[binary ro babel-hello-mcast-history;]
[binary ro babel-hello-ucast-history;]
int ro babel-txcost;
int ro babel-exp-mcast-hello-seqno;
int ro babel-exp-ucast-hello-seqno;
[int ro babel-ucast-hello-seqno;]
[int ro babel-ucast-hello-interval;]
[int ro babel-rxcost]
[int ro babel-cost]
} babel-neighbors-obj;
object { babel-neighbor-address: IPv4 or IPv6 address the neighbor sends
ip-address babel-neighbor-address;
[string babel-hello-mcast-history;]
[string babel-hello-ucast-history;]
int babel-txcost;
int babel-exp-mcast-hello-seqno;
int babel-exp-ucast-hello-seqno;
int babel-neighbor-ihu-interval;
[int babel-rxcost]
[int babel-cost]
}babel-neighbors-obj;
babel-neighbor-address: (IPv4 or v6) address the neighbor sends
messages from messages from
babel-hello-mcast-history: the multicast Hello history of whether babel-hello-mcast-history: The multicast Hello history of whether or
or not the multicast Hello messages prior to babel-exp-mcast- not the multicast Hello messages prior to babel-exp-mcast-hello-
hello-seqno were received, with a "1" for the most recent Hello seqno were received. A binary sequence where the most recently
placed in the most significant bit and prior Hellos shifted right received Hello is expressed as a "1" placed in the left-most bit,
(with "0" bits placed between prior Hellos and most recent Hello with prior bits shifted right (and "0" bits placed between prior
for any not-received Hellos); represented as a string using utf-8 Hello bits and most recent Hello for any not-received Hellos).
encoded hex digits where a "1" bit = Hello received and a "0" bit This value should be displayed using hex digits ([0-9a-fA-F]).
= Hello not received; see draft-ietf-babel-rfc6126bis [rfc6126bis] See [I-D.ietf-babel-rfc6126bis], section A.1.
section A.1
babel-hello-ucast-history: the unicast Hello history of whether or babel-hello-ucast-history: The unicast Hello history of whether or
not the unicast Hello messages prior to babel-exp-ucast-hello- not the unicast Hello messages prior to babel-exp-ucast-hello-
seqno were received, with a "1" for the most recent Hello placed seqno were received. A binary sequence where the most recently
in the most significant bit and prior Hellos shifted right (with received Hello is expressed as a "1" placed in the left-most bit,
"0" bits placed between prior Hellos and most recent Hello for any with prior bits shifted right (and "0" bits placed between prior
unreceived Hellos); represented as a string using utf-8 encoded Hello bits and most recent Hello for any not-received Hellos).
hex digits where a "1" bit = Hello received and a "0" bit = Hello This value should be displayed using hex digits ([0-9a-fA-F]).
not received; see draft-ietf-babel-rfc6126bis [rfc6126bis] section See [I-D.ietf-babel-rfc6126bis], section A.1.
A.1
babel-txcost: transmission cost value from the last IHU packet babel-txcost: Transmission cost value from the last IHU packet
received from this neighbor, or maximum value (infinity) to received from this neighbor, or maximum value (infinity) to
indicates the IHU hold timer for this neighbor has expired indicate the IHU hold timer for this neighbor has expired. See
[I-D.ietf-babel-rfc6126bis], section 3.4.2.
babel-exp-mcast-hello-seqno: expected multicast Hello sequence babel-exp-mcast-hello-seqno: Expected multicast Hello sequence
number of next Hello to be received from this neighbor; if number of next Hello to be received from this neighbor. If
multicast Hello messages are not expected, or processing of multicast Hello messages are not expected, or processing of
multicast messages is not enabled, this MUST be 0 multicast messages is not enabled, this MUST be 0.
babel-exp-ucast-hello-seqno: expected unicast Hello sequence babel-exp-ucast-hello-seqno: Expected unicast Hello sequence number
number of next Hello to be received from this neighbor; if unicast of next Hello to be received from this neighbor. If unicast Hello
Hello messages are not expected, or processing of unicast messages messages are not expected, or processing of unicast messages is
is not enabled, this MUST be 0 not enabled, this MUST be 0.
babel-neighbor-ihu-interval: current IHU interval for this babel-ucast-hello-seqno: The current sequence number in use for
neighbor unicast hellos sent to this neighbor.
babel-rxcost: reception cost calculated for this neighbor; this babel-ucast-hello-interval: The current interval in use for unicast
hellos sent to this neighbor.
babel-rxcost: Reception cost calculated for this neighbor. This
value is usually derived from the Hello history, which may be value is usually derived from the Hello history, which may be
combined with other data, such as statistics maintained by the combined with other data, such as statistics maintained by the
link layer; the rxcost is sent to a neighbour in each IHU link layer. The rxcost is sent to a neighbor in each IHU. See
[I-D.ietf-babel-rfc6126bis], section 3.4.3.
babel-cost: link cost is computed from the values maintained in babel-cost: Link cost is computed from the values maintained in the
the neighbour table: the statistics kept in the neighbour table neighbor table: the statistics kept in the neighbor table about
about the reception of Hellos, and the txcost computed from the reception of Hellos, and the txcost computed from received IHU
received IHU packets packets.
3.5. Definition of babel-security-obj 3.5. Definition of babel-security-obj
object {
string babel-security-mechanism
boolean babel-security-enable;
babel-credential-obj babel-security-self-cred<0..*>;
babel-credential-obj babel-security-trust<0..*>;
[boolean babel-credvalid-log-enable;]
[babel-log-obj babel-credvalid-log<0..*>;]
}babel-security-obj;
babel-security-mechanism: the name of the security mechanism this object {
object instance is about; the value MUST be the same as one of the string ro babel-security-mechanism
enumerations listed in the babel-security-supported parameter boolean rw babel-security-enable;
babel-credential-obj ro babel-security-self-cred<0..*>;
babel-credential-obj ro babel-security-trust<0..*>;
[boolean rw babel-credvalid-log-enable;]
[babel-log-obj ro babel-credvalid-log<0..*>;]
} babel-security-obj;
babel-security-enable: if true, the security mechanism is running; babel-security-mechanism: The name of the security mechanism this
if false, the security mechanism is not currently running; MAY be object instance is about. The value MUST be the same as one of
configurable to allow security mechanism to be started or stopped the enumerations listed in the babel-security-supported parameter.
babel-security-self-cred: credentials this router presents to babel-security-enable: When written, it configures whether this
participate in the enabled security mechanism; any private key security mechanism should be enabled (true) or disabled (false).
component of a credential MUST NOT be readable; adding and A read from the running or intended datastore indicates the
deleting credentials MAY be allowed configured administrative value of whether this security mechanism
is enabled (true) or not (false). A read from the operational
datastore indicates whether this security mechanism is actually
running (true) or not (i.e., it indicates the operational state).
A data model that does not replicate parameters for running and
operational datastores can implement this as two separate
parameters. An implementation MAY choose to expose this parameter
as read-only ("ro").
babel-security-trust: a set of babel-credential-obj objects that babel-security-self-cred: Credentials this router presents to
identify the credentials of routers whose babel messages may be participate in the enabled security mechanism. Any private key
component of a credential MUST NOT be readable. Adding and
deleting credentials MAY be allowed.
babel-security-trust: A set of babel-credential-obj objects that
identify the credentials of routers whose Babel messages may be
trusted or of a certificate authority (CA) whose signing of a trusted or of a certificate authority (CA) whose signing of a
router's credentials implies the router credentials can be router's credentials implies the router credentials can be
trusted, in the context of this security mechanism; how a security trusted, in the context of this security mechanism. How a
mechanism interacts with this list is determined by the mechanism; security mechanism interacts with this list is determined by the
a security algorithm may do additional validation of credentials, mechanism. A security algorithm may do additional validation of
such as checking validity dates or revocation lists, so presence credentials, such as checking validity dates or revocation lists,
in this list may not be sufficient to determine trust; adding and so presence in this list may not be sufficient to determine trust.
deleting credentials MAY be allowed Adding and deleting credentials MAY be allowed.
babel-credvalid-log-enable: if true, logging of messages that babel-credvalid-log-enable: When written, it configures whether
include credentials used for authentication is enabled; if false, logging should be enabled (true) or disabled (false). A read from
these messages are not logged; MUST be configurable, if the running or intended datastore indicates the configured
implemented administrative value of whether logging is enabled (true) or not
(false). A read from the operational datastore indicates whether
logging is actually running (true) or not (i.e., it indicates the
operational state). A data model that does not replicate
parameters for running and operational datastores can implement
this as two separate parameters. An implementation MAY choose to
expose this parameter as read-only ("ro").
babel-credvalid-log: log entries that have the timestamp a message babel-credvalid-log: Log entries that have the timestamp a message
containing credentials used for peer authentication (e.g., DTLS containing credentials used for peer authentication (e.g., DTLS
Server Hello) was received on a Babel port, and the entire Server Hello) was received on a Babel port, and the entire
received message (including Ethernet frame and IP headers, if received message (including Ethernet frame and IP headers, if
possible); an implementation must restrict the size of this log, possible). An implementation must restrict the size of this log,
but how and what size is implementation-specific but how and what size is implementation-specific. If this log is
implemented, a mechanism to clear it SHOULD be provided.
3.6. Definition of babel-routes-obj 3.6. Definition of babel-routes-obj
object { object {
ip-address babel-route-prefix; ip-address ro babel-route-prefix;
int babel-route-prefix-length; int ro babel-route-prefix-length;
base64 babel-route-router-id; binary ro babel-route-router-id;
string babel-route-neighbor; string ro babel-route-neighbor;
[int babel-route-received-metric;] [int ro babel-route-received-metric;]
[int babel-route-calculated-metric;] [int ro babel-route-calculated-metric;]
int babel-route-seqno; int ro babel-route-seqno;
ip-address babel-route-next-hop; ip-address ro babel-route-next-hop;
boolean babel-route-feasible; boolean ro babel-route-feasible;
boolean babel-route-selected; boolean ro babel-route-selected;
}babel-routes-obj; } babel-routes-obj;
babel-route-prefix: Prefix (expressed in IP address format) for
which this route is advertised
babel-route-prefix-length: Length of the prefix for which this babel-route-prefix: Prefix (expressed in IP address format) for
route is advertised which this route is advertised.
babel-route-router-id: router-id of the source router for which babel-route-prefix-length: Length of the prefix for which this route
this route is advertised is advertised babel-route-router-id: router-id of the source
router for which this route is advertised.
babel-route-neighbor: reference to the babel-neighbors entry for babel-route-neighbor: Reference to the babel-neighbors entry for the
the neighbor that advertised this route neighbor that advertised this route.
babel-route-received-metric: the metric with which this route was babel-route-received-metric: The metric with which this route was
advertised by the neighbor, or maximum value (infinity) to advertised by the neighbor, or maximum value (infinity) to
indicate a the route was recently retracted and is temporarily indicate the route was recently retracted and is temporarily
unreachable (see Section 3.5.5 of draft-ietf-babel-rfc6126bis unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]).
[rfc6126bis]); this metric will be 0 (zero) if the route was not This metric will be 0 (zero) if the route was not received from a
received from a neighbor but was generated through other means; neighbor but was generated through other means. Either babel-
either babel-route-calculated-metric or babel-route-received- route-calculated-metric or babel-route-received-metric MUST be
metric MUST be provided provided.
babel-route-calculated-metric: a calculated metric for this route; babel-route-calculated-metric: A calculated metric for this route.
how the metric is calculated is implementation-specific; maximum How the metric is calculated is implementation-specific. Maximum
value (infinity) indicates the route was recently retracted and is value (infinity) indicates the route was recently retracted and is
temporarily unreachable (see Section 3.5.5 of draft-ietf-babel- temporarily unreachable (see Section 3.5.5 of
rfc6126bis [rfc6126bis]); either babel-route-calculated-metric or [I-D.ietf-babel-rfc6126bis]). Either babel-route-calculated-
babel-route-received-metric MUST be provided metric or babel-route-received-metric MUST be provided.
babel-route-seqno: the sequence number with which this route was babel-route-seqno: The sequence number with which this route was
advertised advertised.
babel-route-next-hop: the next-hop address of this route; this babel-route-next-hop: The next-hop address of this route. This will
will be empty if this route has no next-hop address be empty if this route has no next-hop address.
babel-route-feasible: a boolean flag indicating whether this route
is feasible, as defined in Section 3.5.1 of draft-ietf-babel-
rfc6126bis [rfc6126bis])
babel-route-selected: a boolean flag indicating whether this route babel-route-feasible: A boolean flag indicating whether this route
is selected, i.e., whether it is currently being used for is feasible, as defined in Section 3.5.1 of
forwarding and is being advertised [I-D.ietf-babel-rfc6126bis]).
babel-route-selected: A boolean flag indicating whether this route
is selected (i.e., whether it is currently being used for
forwarding and is being advertised).
4. Common Objects 4. Common Objects
4.1. Definition of babel-credential-obj 4.1. Definition of babel-credential-obj
object { object {
credentials babel-cred; credentials ro babel-cred;
}babel-credential-obj; } babel-credential-obj;
babel-cred: a credential, such as an X.509 certificate, a public babel-cred: A credential, such as an X.509 certificate, a public
key, etc. used for signing and/or encrypting babel messages key, etc. used for signing and/or encrypting Babel messages.
4.2. Definition of babel-log-obj 4.2. Definition of babel-log-obj
object { object {
datetime babel-log-time; datetime ro babel-log-time;
string babel-log-entry; string ro babel-log-entry;
}babel-log-obj; } babel-log-obj;
babel-log-time: the date and time (according to the device babel-log-time: The date and time (according to the device internal
internal clock setting, which may be a time relative to boot time, clock setting, which may be a time relative to boot time, acquired
acquired from NTP, configured by the user, etc.) when this log from NTP, configured by the user, etc.) when this log entry was
entry was created created.
babel-log-entry: the logged message, as a string of utf-8 encoded babel-log-entry: The logged message, as a string of utf-8 encoded
hex characters hex characters.
5. Extending the Information Model 5. Extending the Information Model
Implementations MAY extend this information model with other Implementations MAY extend this information model with other
parameters or objects. For example, an implementation MAY choose to parameters or objects. For example, an implementation MAY choose to
expose babel route filtering rules by adding a route filtering object expose Babel route filtering rules by adding a route filtering object
with parameters appropriate to how route filtering is done in that with parameters appropriate to how route filtering is done in that
implementation. The precise means used to extend the information implementation. The precise means used to extend the information
model would be specific to the data model the implementation uses to model would be specific to the data model the implementation uses to
expose this information. expose this information.
6. Security Considerations 6. Security Considerations
This document defines a set of information model objects and This document defines a set of information model objects and
parameters that may be exposed to be visible from other devices, and parameters that may be exposed to be visible from other devices, and
some of which may be configured. Any mechanism or protocol that is some of which may be configured. Securing access to and ensuring the
used to transmit this information or allow for its configuration is integrity of this data is in scope of and the responsibility of any
also responsible for ensuring this is done so in a secure manner. data model derived from this information model. Specifically, any
YANG [RFC7950] data model is expected to define security exposure of
the various parameters, and a [TR-181] data model will be secured by
the mechanisms defined for the management protocol used to transport
it.
This information model defines objects that can allow credentials This information model defines objects that can allow credentials
(for this device, for trusted devices, and for trusted certificate (for this device, for trusted devices, and for trusted certificate
authorities) to be added and deleted. Public keys and shared secrets authorities) to be added and deleted. Public keys and shared secrets
may be exposed through this model. This model requires that private may be exposed through this model. This model requires that private
keys never be exposed. The Babel security mechanisms that make use keys never be exposed. The Babel security mechanisms that make use
of these credentials are not defined or identified in this model. of these credentials (e.g., [I-D.ietf-babel-dtls],
[I-D.ietf-babel-hmac]) are expected to define what credentials can be
used with those mechanisms.
7. IANA Considerations 7. IANA Considerations
This document makes no IANA requests. This document defines a Babel Link Type registry for the values of
the babel-link-type and babel-supported-link-types parameters to be
listed under the Babel Routing Protocol registry.
Valid Babel Link Type names are normatively defined as
o MUST be at least 1 character and no more than 20 characters long
o MUST contain only US-ASCII [RFC0020] letters 'A' - 'Z' and 'a' -
'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45)
o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')
o MUST NOT begin or end with a hyphen
o hyphens MUST NOT be adjacent to other hyphens
The rules for Link Type names, excepting the limit of 20 characters
maximum, are also expressed below (as a non-normative convenience)
using ABNF [RFC5234].
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2D ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
The allocation policy of this registry is Specification Required
[RFC8126].
The initial values in the "Babel Link Type" registry are:
+----------+-------------------------------------------+------------+
| Name | Used for Links Defined By | Reference |
+----------+-------------------------------------------+------------+
| ethernet | [IEEE-802.3-2018] | (this |
| | | document) |
| other | to be used when no link type information | (this |
| | available | document) |
| tunnel | to be used for a tunneled interface over | (this |
| | unknown physical link | document) |
| wireless | [IEEE-802.11-2016] | (this |
| | | document) |
| exp-* | Reserved for Experimental Use | (this |
| | | document) |
+----------+-------------------------------------------+------------+
8. Acknowledgements 8. Acknowledgements
Juliusz Chroboczek, Toke Hoeiland-Joergensen, and David Schinazi have Juliusz Chroboczek, Toke Hoeiland-Joergensen, David Schinazi, Mahesh
been very helpful in refining this information model. Jethanandani, Acee Lindem, and Carsten Bormann have been very helpful
in refining this information model.
The language in the Notation section was mostly taken from RFC 8193 The language in the Notation section was mostly taken from [RFC8193].
[RFC8193].
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-babel-rfc6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", draft-ietf-babel-rfc6126bis-05 (work in
progress), May 2018.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[rfc6126bis] [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Chroboczek, J., "The Babel Routing Protocol", Work in Writing an IANA Considerations Section in RFCs", BCP 26,
Progress, draft-ietf-babel-rfc6126bis, October 2017. RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[BABEL-DTLS] [I-D.ietf-babel-dtls]
Schinazi, D., "TBD", Work in Progress, rfc6347, March Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
2018. Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-01 (work in progress), October 2018.
[BABEL-HMAC] [I-D.ietf-babel-hmac]
Ovsienko, D., "Babel HMAC Cryptographic Authentication", Do, C., Kolodziejak, W., and J. Chroboczek, "Babel
Work in Progress, draft-ovsienko-babel-rfc7298bis, March Cryptographic Authentification", draft-ietf-babel-hmac-00
2018. (work in progress), August 2018.
[IEEE-802.11-2016]
"IEEE Standard 802.11-2016 - IEEE Standard for Information
Technology - Telecommunications and information exchange
between systems Local and metropolitan area networks -
Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications.".
[IEEE-802.3-2018]
"IEEE Standard 802.3-2018 - IEEE Approved Draft Standard
for Ethernet.".
[ISO.10646] [ISO.10646]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded "Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO Standard 10646:2014, 2014. Character Set (UCS)", ISO Standard 10646:2014, 2014.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8193] Burbridge, T., Eardley, P., Bagnulo, M., and J. [RFC8193] Burbridge, T., Eardley, P., Bagnulo, M., and J.
Schoenwaelder, "Information Model for Large-Scale Schoenwaelder, "Information Model for Large-Scale
Measurement Platforms (LMAPs)", RFC 8193, Measurement Platforms (LMAPs)", RFC 8193,
DOI 10.17487/RFC8193, August 2017, DOI 10.17487/RFC8193, August 2017,
<https://www.rfc-editor.org/info/rfc8193>. <https://www.rfc-editor.org/info/rfc8193>.
[TR-181] Broadband Forum, "Device Data Model",
<http://cwmp-data-models.broadband-forum.org/>.
Appendix A. Open Issues Appendix A. Open Issues
This draft must be reviewed against draft-ietf-babel-rfc6126bis. [I 1. I want to get rid of the security log, because all Babel messages
feel like this has been adequately done, but I could be wrong.] (which should be defined as all messages to/from the udp-port)
are be logged by message-log. I don't like message log as it is.
I think if logging is enabled it should just write to a text
file. This will mean there also needs to be a means of
downloading/reading the log file.
Following are some issues where a conscious decision may be useful: 2. Consider the following statistics: under interface object: sent
multicast Hello, sent updates, received Babel messages; under
neighbor object: sent unicast Hello, sent updates, sent IHU,
received Hello, received updates, received IHUs. Would also need
to enable/disable stats and clear stats.
1. babel-interfaces-obj: Juliusz:"This needs further discussion, I 3. Security section needs furter review
fear some of these are implementation details." [In the absence
of discussion, the current model stands. Note that all but link-
type and the neighbors sub-object are optional; if an
implementation does not have any of the optional elements then it
simply doesn't have them and that's fine.]
2. Would it be useful to define some parameters for reporting 4. Commands to add and delete credentials, and parameters that allow
statistics or logs? [2 logs are now included. If others are credential to be identified without allowing access to private
needed they need to be proposed.] credential info
3. Would it be useful to define some parameters specifically for 5. Check description of enable parameters to make sure ok for YANG
security anomalies? [The 2 logs should be useful in identifying and TR-181. Closed by updating description to be useful for YANG
security anomalies. If more is needed, someone needs to and TR-181, using language consistent with YANG descriptions.
propose.]
4. I created a basic security model. It's useful for single (or no) 6. Distinguish signed and unsigned integers?
active security mechanism (e.g., just HMAC, just DTLS, or
neither); but not multiple active (both HMAC and DTLS -- which is
not the same as HMAC of DTLS and would just mean that HMAC would
be used on all unencrypted messages -- but right now the model
doesn't allow for configuring HMAC of unencrypted messages for
routers without DTLS, while DTLS is used if possible). OK?
5. babel-external-cost may need more work. [if no comment, it will 7. Review new IANA Considerations section. Should ABNF be
be left as is] normative?
6. babel-hello-[mu]cast-history: the Hello history is formated as 16 Closed Issues:
bits, per A.1 of 6126bis. Is that a too implementation specific?
[We also now have an optional-to-implement log of received
messages, and I made these optional. So maybe this is ok?]
7. rxcost, txcost, cost: is it ok to model as integers, since 1. Datatype of the router-id: Closed by introducing binary datatype
6126bis 2.1 says costs and metrics need not be integers. [I have and using that for router-id
them as integers unless someone insists on something else.]
8. Should babel link types have an IANA registry? [Right now, none 2. babel-neighbor-address as IPv6-only: Closed by leaving as is
is defined.] (IPv4 and IPv6)
9. For the security log, should it also log whether the credentials 3. babel-implementation-version includes the name of the
were considered ok? [Right now it doesn't and I think that's ok implementation: Closed by adding "name" to description
because if you log Hellos it was ok and if you don't it wasn't.]
Closed Issues: 4. Delete external-cost?: Closed by deleting.
Closed by defining base64 type and using it for all router IDs: 5. Would it be useful to define some parameters for reporting
"babel-self-router-id: Should this be an opaque 64-bit value statistics or logs? [2 logs are now included. If others are
instead of int?" needed they need to be proposed. See Open Issues for additional
thoughts on logs and statistics.]
Closed as "No": Do we need a registry for the supported security 6. Closed by defining base64 type and using it for all router IDs:
mechanisms? [Given the current limited set, and unlikelihood of "babel-self-router-id: Should this be an opaque 64-bit value
massive expansion, I don't think so. But we can if someone wants instead of int?"
it.]
7. Closed as "No": Do we need a registry for the supported security
mechanisms? [Given the current limited set, and unlikelihood of
massive expansion, I don't think so. But we can if someone
wants it.]
8. This draft must be reviewed against draft-ietf-babel-rfc6126bis.
[I feel like this has been adequately done, but I could be
wrong.]
9. babel-interfaces-obj: Juliusz:"This needs further discussion, I
fear some of these are implementation details." [In the absence
of discussion, the current model stands. Note that all but
link-type and the neighbors sub-object are optional. If an
implementation does not have any of the optional elements then
it simply doesn't have them and that's fine.]
10. Would it be useful to define some parameters specifically for
security anomalies? [The 2 logs should be useful in identifying
security anomalies. If more is needed, someone needs to
propose.]
11. I created a basic security model. It's useful for single (or
no) active security mechanism (e.g., just HMAC, just DTLS, or
neither); but not multiple active (both HMAC and DTLS -- which
is not the same as HMAC of DTLS and would just mean that HMAC
would be used on all unencrypted messages -- but right now the
model doesn't allow for configuring HMAC of unencrypted messages
for routers without DTLS, while DTLS is used if possible). OK?
[No-one said otherwise.]
12. babel-external-cost may need more work. [if no comment, it will
be left as is]
13. babel-hello-[mu]cast-history: the Hello history is formated as
16 bits, per A.1 of 6126bis. Is that a too implementation
specific? [We also now have an optional-to-implement log of
received messages, and I made these optional. So maybe this is
ok?]
14. rxcost, txcost, cost: is it ok to model as integers, since
6126bis 2.1 says costs and metrics need not be integers. [I
have them as integers unless someone insists on something else.]
15. For the security log, should it also log whether the credentials
were considered ok? [Right now it doesn't and I think that's ok
because if you log Hellos it was ok and if you don't it wasn't.]
16. Should Babel link types have an IANA registry? [Agreed to do
this at IETF 102.]
Appendix B. Change Log Appendix B. Change Log
Individual Drafts: Individual Drafts:
v00 2016-07-07 EBD Initial individual draft version v00 2016-07-07 EBD: Initial individual draft version
v01 2017-03-13 Addressed comments received in 2016-07-15 email v01 2017-03-13: Addressed comments received in 2016-07-15 email from
from J. Chroboczek J. Chroboczek
Working group drafts: Working group drafts:
v00 2017-07-03 Addressed points noted with "oops" in v00 2017-07-03: Addressed points noted with "oops" in
https://www.ietf.org/proceedings/98/slides/slides-98-babel-babel- https://www.ietf.org/proceedings/98/slides/slides-98-babel-babel-
information-model-00.pdf information-model-00.pdf
v01 2018-01-02 Removed item from issue list that was agreed (in v01 2018-01-02: Removed item from issue list that was agreed (in
Prague) not to be an issue. Added description of data types under Prague) not to be an issue. Added description of data types under
Notation section, and used these in all data types. Added babel- Notation section, and used these in all data types. Added babel-
security and babel-trust. security and babel-trust.
v02 2018-04-05 v02 2018-04-05:
- changed babel-version description to babel-implementation- * changed babel-version description to babel-implementation-
version version
- replace optional babel-interface-seqno with optional babel- * replace optional babel-interface-seqno with optional babel-
mcast-hello-seqno and babel-ucast-hello-seqno mcast-hello-seqno and babel-ucast-hello-seqno
- replace optional babel-interface-hello-interval with optional * replace optional babel-interface-hello-interval with optional
babel-mcast-hello-interval and babel-ucast-hello-interval babel-mcast-hello-interval and babel-ucast-hello-interval
- remove babel-request-trigger-ack * remove babel-request-trigger-ack
- remove "babel-router-id: router-id of the neighbor"; note * remove "babel-router-id: router-id of the neighbor"; note that
that parameter had previously been removed but description had parameter had previously been removed but description had
accidentally not been removed accidentally not been removed
- added an optional "babel-cost" field to babel-neighbors * added an optional "babel-cost" field to babel-neighbors object,
object, since the spec does not define how exactly the cost is since the spec does not define how exactly the cost is computed
computed from rxcost/txcost from rxcost/txcost
- deleted babel-source-garbage-collection-time * deleted babel-source-garbage-collection-time
- change babel-lossy-link to babel-link-type and make this an
* change babel-lossy-link to babel-link-type and make this an
enumeration; added at top level babel-supported-link-types so enumeration; added at top level babel-supported-link-types so
which are supported by this implementation can be reported which are supported by this implementation can be reported
- changes to babel-security-obj to allow self credentials to be * changes to babel-security-obj to allow self credentials to be
one or more instances of a credential object; allowed trusted one or more instances of a credential object. Allowed trusted
credentials to include CA credentials; made some parameter name credentials to include CA credentials; made some parameter name
changes changes
- updated references and Introduction * updated references and Introduction
- added Overview section * added Overview section
- deleted babel-sources-obj * deleted babel-sources-obj
- added feasible Boolean to routes * added feasible Boolean to routes
- added section to briefly describe extending the information * added section to briefly describe extending the information
model. model.
- deleted babel-route-neighbor * deleted babel-route-neighbor
- tried to make definition of babel-interface-reference clearer * tried to make definition of babel-interface-reference clearer
- added security and message logs * added security and message logs
v03 2018-05-31 v03 2018-05-31:
- added reference to RFC 8174 (update to RFC 2119 on key words) * added reference to RFC 8174 (update to RFC 2119 on key words)
- applied edits to Introduction text per Juliusz email of * applied edits to Introduction text per Juliusz email of
2018-04-06 2018-04-06
- Deleted sentence in definition of "int" data type that said * Deleted sentence in definition of "int" data type that said it
it was also used for enumerations. Changed all enumerations to was also used for enumerations. Changed all enumerations to
strings. The only enumerations were for link types, which are strings. The only enumerations were for link types, which are
now "ethernet", "wireless", "tunnel", and "other". now "ethernet", "wireless", "tunnel", and "other".
- deleted [ip-address babel-mcast-group-ipv4;] * deleted [ip-address babel-mcast-group-ipv4;]
- babel-external-cost description changed * babel-external-cost description changed
- babel-security-self-cred: Added "any private key component of * babel-security-self-cred: Added "any private key component of a
a credential MUST NOT be readable;" credential MUST NOT be readable;"
- hello-history parameters put recent Hello in most significant
* hello-history parameters put recent Hello in most significant
bit and length of parameter is not constrained. bit and length of parameter is not constrained.
- babel-hello-seqno in neighbors-obj changed to babel-exp- * babel-hello-seqno in neighbors-obj changed to babel-exp-mcast-
mcast-hello-seqno and babel-exp-ucast-hello-seqno hello-seqno and babel-exp-ucast-hello-seqno
- added babel-route-neighbor back again; it was mistakenly * added babel-route-neighbor back again. It was mistakenly
deleted deleted
- changed babel-route-metric and babel-route-announced-metric * changed babel-route-metric and babel-route-announced-metric to
to babel-route-received-metric and babel-route-calculated- babel-route-received-metric and babel-route-calculated-metric
metric
- changed model of security object to put list of supported * changed model of security object to put list of supported
mechanisms at top level and separate security object per mechanisms at top level and separate security object per
mechanism; this caused some other changes to the security mechanism. This caused some other changes to the security
object object
v04 2018-10-15:
* changed babel-mcast-group-ipv6 to babel-mcast-group
* link type parameters changed to point to newly defined registry
* babel-ucast-hello-interval moved to neighbor object
* babel-ucast-hello-seqno moved to neighbor object
* babel-neighbor-ihu-interval deleted
* in log descriptions, included statement that there SHOULD be
ability to clear logs
* added IANA registry for link types
* added "ro" and "rw" to tables for read-write and read-only
* added metric computation parameter to interface
Author's Address Author's Address
Barbara Stark Barbara Stark
AT&T AT&T
Atlanta, GA Atlanta, GA
US US
Email: barbara.stark@att.com Email: barbara.stark@att.com
 End of changes. 149 change blocks. 
392 lines changed or deleted 581 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/