Re: [babel] Example configuration

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 07 August 2019 00:19 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5C1200B1 for <babel@ietfa.amsl.com>; Tue, 6 Aug 2019 17:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlwwGKZYaHcR for <babel@ietfa.amsl.com>; Tue, 6 Aug 2019 17:19:42 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5989912009C for <babel@ietf.org>; Tue, 6 Aug 2019 17:19:42 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id m30so42417622pff.8 for <babel@ietf.org>; Tue, 06 Aug 2019 17:19:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zdGs+817Ban5qDlhjKlB0v5kzyjikGa01rYEVhci8h0=; b=LL3EHHoaUdUgnkh3G2KGaUoYX4+48ebg3F3Z9mdDBshdL8GEhKku3hoHfPKgGO/MSv cRbqvlMrUa7dGcQnNdKwizTu9rgkmASLBAj9oHQuu+w7YMC3XqmECXWHP1i5jMWcB+hT rany6wgBuPVAypfhSC+BP+TxEVI4MFYi0F0djSGLNukg7VNMtNqy3Oo5gCkwEjovG/YG 84CVi9KGvTDDuUrK1loCrl8H0hfHh4p3YZPKrnFUKyBw9goGKOAwejyosqk/Fit7J4f/ Vzn/MBFmaHW82w1Iai0s7+LBvoYOG+milspK0WQ2r9LHnHPqTIi8i+3fxhB7JVz4+tz1 OROg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zdGs+817Ban5qDlhjKlB0v5kzyjikGa01rYEVhci8h0=; b=Mz+jxh/4Pp+XW5lhI6QEnMNKQxRVva6AYiWEAxVCK/DYoAz9pUxRVE7jbhx3cgzQuI 1NXWAD+wNnoBLUWr64caLOlLH45Jw7/bh4RPs/eFfTDb1dCjCzLLA06Em4VcKZbCMMLN aIUkINkfEW2x8GL94TFIXD7OhcuiJK7RLmRO5Co/nrD5f/aZKszJHxiyXJAxSeUX3Zx0 bNHIfIf7BQ+GYquIYG9h11qbNG4pilMEGkTIe6ChPKekVSvzDe0ntLmJdpclZQKdTrrP qZg3ctKMvL67F9PE+BSWKusnvvBV9Kjt1ainaVk4Q4XDHLGutVLwO+D+D9EHoJZztpxD ORxA==
X-Gm-Message-State: APjAAAV7hslSYCijFJ+TYs6a9GzwqNILXgHDsezzP8+6UejaeJpKdwvD 2LM5PZTzkGv0K2K4WSFV3ug=
X-Google-Smtp-Source: APXvYqwF5zeJWTTND2MK+oIPnfM1JjEiMkAZvvKI8AEgsgD/Ur+Zi50JIjg1XuL0gP1ezg9ZqERj4g==
X-Received: by 2002:aa7:9786:: with SMTP id o6mr6293014pfp.222.1565137181755; Tue, 06 Aug 2019 17:19:41 -0700 (PDT)
Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id v10sm87114093pfe.163.2019.08.06.17.19.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 17:19:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <8736ieasm6.wl-jch@irif.fr>
Date: Tue, 06 Aug 2019 17:19:39 -0700
Cc: Babel at IETF <babel@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF249683-1BB0-4686-A77A-847E64E4EA50@gmail.com>
References: <E726ED50-6D90-4537-B237-6E52D375F50B@gmail.com> <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/SOc7f5fLJr_nefCrYbtKprnvp-M>
Subject: Re: [babel] Example configuration
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 00:19:45 -0000


> On Aug 6, 2019, at 2:31 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> I am also not clear on the underlying properties. If the interface is eth1,
>> its underlying property will be of a wired 802.3 like interface. I thought the
>> whole idea of specifying the type was an indication that eth1 is an Ethernet
>> bridged to a wireless radio. How would you derive a ‘wireless’ like
>> information from the underlying property?
> 
> The protocol doesn't know about interface types.  From the point of view
> of the protocol, there are a number of algorithms that can optionally be
> selected or enabled on a given interface.  These include:
> 
>  - link-quality estimation (2-out-of-3 or ETX);
>  - split-horizon (on or off);
>  - RTT estimation (draft-ietf-babel-rtt);
>  - use of unicast instead of multicast;
>  - ...
> 
> The choice of parameters requires intimate knowledge of the protocol and
> the implementation.  For that reason, the babeld implementation packages
> useful combinations within the interface type parameter
> 
>  "type wired" is a shortcut for "link-quality 2-out-of-3 split-horizon true"
>  "type wireless" is a shortcut for "link-quality etc split-horizon false"
>  "type tunnel" is a shortcut for "link-quality 2-out-of-3 max-rtt-penalty 96"
> 
> However, other combinations are possible, and some of them are actually
> useful -- "link-quality 2-out-of-3 split-horizon false" makes perfect
> sense for an NBMA network.  Therefore, the interface type cannot in
> general be synthesized from the configuration parameters of the interface.
> 
> So what's the information model to do?  My opinion is to consider the
> interface type as a UI issue, and put the underlying parameters in the
> information model, which is what Barbara has implemented in -08.  Other
> solutions are possible, of course, and I'm quite open to considering them
> if someone has a plan.

In -08 version of the draft, all references to wired, wireless, tunnel and others are gone. That in addition to babel-link-properties. If they are underlying parameters, they are truly invisible :-). That means there is no way to specify most of the link properties that you describe above, with the exception of split-horizon, which is lone link property under babel-interace-obj.

I understand that it is difficult for an operator without intimate knowledge to know how to configure these properties. And that is why these should be optional properties. However, without them, there is no way for an operator to influence how the protocol works. 

My suggestion would be that the link properties be moved into an obj of their own, something like a list of babel-link-properties-obj. We can document the examples you have above. They do not have to be specified by default. Operators that do want to, can define any combination of link properties, like you do above with wired, wireless and tunnel. They can call them whatever they want. One item in this list in then referenced by the babel-interface-obj which tells it which link properties if any have been specified for that interface. Something like this:

object {
           ….
           [babel-link-properties   rw babel-link-properties<0..*>;]

} babel-information-obj;

object {
          [reference                      rw  babel-link-properties;]
           …..
} babel-interface-obj;

object {
          string                             rw name;
          [string                            rw babel-link-quality;]
          [boolean                        rw babel-split-horizon;]
          [uint                               rw babel-max-rtt-penalty;]
          [boolean                        rw babel-unicast;]
} babel-link-properties;

Tomorrow, if we want to add more properties, the babel-link-properties obj can be extended. 


> 
>> Just to confirm. Both babel-mcast-hello-interval and babel-update-interval
>> need to be read-write (configurable) properties.
> 
> Aye.
> 
>>    Filters are a separate kind of entity, and need not contain an interface
>>    entry.  For example, one may say
> 
>>     in ip 10.0.0.0/8 metric 128
> 
>>    in which case the filter applies to all routes with a destination in 10/8.
> 
>> In other words, a global configuration that applies across all routes with
>> that destination. I am not aware of any way to do this with our current
>> information model. We are looking at an addition to the information model.
> 
> Here's what other YANG models do:
> 
>  - the RIP YANG model ignores filtering, although most RIP
>    implementations support it;
>  - the BGP YANG model imports draft-ietf-rtgwg-policy-model.

Ok. Let me follow up on the separate e-mail thread that you started with describing Babel filtering and routing policies. If it becomes too complex, we can drop it.

Thanks.

> 
> I suggest we follow the lead of RIP, and consider filtering as out of
> scope for the YANG model.  Filtering is a complex beast, it tends to grow
> over time (it's the cleanest place to add implementation-specific hooks),
> and I don't think we have the manpower to do a good job.
> 
>> * Change babel-mcast-hello-interval and babel-update-interval to rw property.
> 
> Yes.
> 
>> * Add global level filter capability
> 
> Not necessarily.  See above.
> 
>> * Add a way to mark an interface for unicast-preferred (please feel free to
>>  suggest a better name), and unicast-only as boolean configurable properties.
> 
> Babeld calles the former simply "unicast".  The latter is not implemented
> yet, so please don't define it yet, it might never happen.
> 
>> * Add a capability to specify a link-local address for a neighbor.
> 
> Not quite -- it's about defining a static neighbour for unicast-only
> operation.  Again, it might never happen.
> 
> -- Juliusz

Mahesh Jethanandani
mjethanandani@gmail.com