Subject: [babel] proposed info model change

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 11 Feb 2021 20:54:22 +0000

Hi Babel WG,
Would anyone object to the following change for the router-id parameter?

FROM
The router-id value MUST NOT consist of all zeroes or all ones.
TO
The router-id value MUST be unique among all instances of Babel on a device.

Thx,
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 11 Feb 2021 22:13:04 +0100

> The router-id value MUST be unique among all instances of Babel on a device.

What's the rationale?

-Toke

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 11 Feb 2021 13:22:32 -0800

Hi Toke,

The rational has to do with what a data model like YANG does with router-id. To it the router-id is a key, in the form of a string. That string has to be unique. YANG does not prevent it being a string of zeros or ones, provided that string is unique. Thus the dropping of the "MUST NOT” and the addition of “MUST”.

Thanks.

> On Feb 11, 2021, at 1:13 PM, Toke Høiland-Jørgensen <toke=[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
[email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 11 Feb 2021 23:00:35 +0100

Mahesh Jethanandani <[email-masked]> writes:

> Hi Toke,
>
> The rational has to do with what a data model like YANG does with
> router-id. To it the router-id is a key, in the form of a string. That
> string has to be unique. YANG does not prevent it being a string of
> zeros or ones, provided that string is unique. Thus the dropping of
> the "MUST NOT” and the addition of “MUST”.

Right. I seem to recall there being some other reason why it shouldn't
be 0, but can't find the discussion now, and looking at the code that
doesn't seem to care. So no objection from me I guess :)

-Toke

---

From: David Schinazi <[email-masked]>
Date: Thu, 11 Feb 2021 19:09:36 -0800

We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00
and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to
reserve them for future extensibility. Also, banning all-zeroes allows
using that as a sentinel value in software.

Adding the uniqueness requirement sounds good to me, but removing the ban
on all-zeroes/all-ones could lead to problems. If the core protocol doesn't
allow it, why should the informational model allow it?

David

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 11 Feb 2021 21:55:51 -0800

Hi David,

> On Feb 11, 2021, at 7:09 PM, David Schinazi <[email-masked]> wrote:
> 
> We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00 and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to reserve them for future extensibility. Also, banning all-zeroes allows using that as a sentinel value in software.
> 
> Adding the uniqueness requirement sounds good to me, but removing the ban on all-zeroes/all-ones could lead to problems. If the core protocol doesn't allow it, why should the informational model allow it?

If the protocol banned it, that is a different question, and info model can reflect that. I just wanted to point out that it is not because of the data model.

Cheers.

> 
> David
> 
> On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=[email-masked] <mailto:[email-masked]>> wrote:
> Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> writes:
> 
> > Hi Toke,
> >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 12 Feb 2021 14:43:02 +0000

Just to be clear ...
An enabled Babel instance (that is sending and receiving Babel packets) already has a requirement for unique non-zero router-id. Where we were having a problem was with not-enabled Babel instances that weren’t actively running the protocol (had maybe just been installed). I think it was babeld that was just using a default of all zeroes until it was enabled; at which time it generated its unique router-id. With this not-enabled “zero” default, the possibility exists for multiple not-enabled Babel instances to be defaulted to zero, which would lead to YANG having a problem with having a unique router-id to identify them by.

The fact that the Babel protocol forbids zero valued router-ids doesn’t mean not-enabled instances can’t have that as a default; and it doesn’t prevent there from being multiple not-enabled instances with a default value.

TR-181 doesn’t have a problem with this, because it uses a unique key distinct from the router-id. The Babel protocol spec already has what it needs to make sure the router-id for enabled instances are unique (and the data/info model doesn’t need to be involved in policing this). So this really is just about making sure the language is suitable to ensure YANG can use this parameter as a unique key, without putting constraints on the protocol. If YANG were fine with a Babel instance that started with router-id zero and then changed to something else once the protocol started running, then zero wouldn’t be a problem if there is just a single instance with that zero value.
Barbara

From: Mahesh Jethanandani <[email-masked]>
Sent: Thursday, February 11, 2021 11:56 PM
To: David Schinazi <[email-masked]>
Cc: Toke Høiland-Jørgensen <toke=[email-masked]>; STARK, BARBARA H <[email-masked]>; [email-masked]
Subject: Re: [babel] proposed info model change

Hi David,

On Feb 11, 2021, at 7:09 PM, David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:

Cheers.

David

On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=[email-masked]<mailto:[email-masked]>> wrote:

-Toke

_______________________________________________
babel mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/babel<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: David Schinazi <[email-masked]>
Date: Sat, 13 Feb 2021 13:53:08 -0800

Ah I see, thanks for the explanation! I'm fine with the change then.

David

On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H <[email-masked]> wrote:

> Just to be clear ...
>
> An enabled Babel instance (that is sending and receiving Babel packets)
> already has a requirement for unique non-zero router-id. Where we were
> having a problem was with not-enabled Babel instances that weren’t actively
> running the protocol (had maybe just been installed). I think it was
> babeld that was just using a default of all zeroes until it was enabled;
> at which time it generated its unique router-id. With this not-enabled
> “zero” default, the possibility exists for multiple not-enabled Babel
> instances to be defaulted to zero, which would lead to YANG having a
> problem with having a unique router-id to identify them by.
>
>
>
> The fact that the Babel protocol forbids zero valued router-ids doesn’t
> mean not-enabled instances can’t have that as a default; and it doesn’t
> prevent there from being multiple not-enabled instances with a default
> value.
>
>
>
> TR-181 doesn’t have a problem with this, because it uses a unique key
> distinct from the router-id. The Babel protocol spec already has what it
> needs to make sure the router-id for enabled instances are unique (and the
> data/info model doesn’t need to be involved in policing this). So this
> really is just about making sure the language is suitable to ensure YANG
> can use this parameter as a unique key, without putting constraints on the
> protocol. If YANG were fine with a Babel instance that started with
> router-id zero and then changed to something else once the protocol started
> running, then zero wouldn’t be a problem if there is just a single instance
> with that zero value.
>
> Barbara
>
>
>
> *From:* Mahesh Jethanandani <[email-masked]>
> *Sent:* Thursday, February 11, 2021 11:56 PM
> *To:* David Schinazi <[email-masked]>
> *Cc:* Toke Høiland-Jørgensen <toke=[email-masked]>; STARK,
> BARBARA H <[email-masked]>; [email-masked]
> *Subject:* Re: [babel] proposed info model change
>
>
>
> Hi David,
>
>
>
> If the protocol banned it, that is a different question, and info model
> can reflect that. I just wanted to point out that it is not because of the
> data model.
>
>
>
> Cheers.
>
>
>
>
>
> David
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>
>
>
>
> Mahesh Jethanandani
>
> [email-masked]
>
>
>
>
>
>
>
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 17 Feb 2021 21:17:34 +0000

I’d like to circle back around to Mahesh, then, to see if this change is really a good idea from his perspective. If we do this change, then it means an implementation could start with an all-zero router-id before its enabled and then generate a “real” router-id when enabled. Which was what the original all-zero prohibition was trying to prevent. If this is acceptable for YANG (to have a changing router-id), then I see no need for any prohibition in the info model (because the protocol spec will ensure uniqueness when the “real” router-id is generated).  If not acceptable, then it seems to me we need to keep the current info model all-zero prohibition.
Barbara

David

On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
Just to be clear ...
An enabled Babel instance (that is sending and receiving Babel packets) already has a requirement for unique non-zero router-id. Where we were having a problem was with not-enabled Babel instances that weren’t actively running the protocol (had maybe just been installed). I think it was babeld that was just using a default of all zeroes until it was enabled; at which time it generated its unique router-id. With this not-enabled “zero” default, the possibility exists for multiple not-enabled Babel instances to be defaulted to zero, which would lead to YANG having a problem with having a unique router-id to identify them by.

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 11:56 PM
To: David Schinazi <[email-masked]<mailto:[email-masked]>>
Cc: Toke Høiland-Jørgensen <toke=[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [babel] proposed info model change

Hi David,

Cheers.

David

-Toke

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 18 Feb 2021 09:26:08 -0800

Hi Barbara,

Thanks for circling back on the question of router-id and its impact on the YANG model.

Based on the discourse on this thread, it is clear that the “router-id” has meaning when the protocol is enabled. The YANG model can therefore add a conditional statement, i.e. a must statement, that allows the read of the “router-id” only if the protocol is enabled via the “enable” flag. 

Is the WG acceptable of the change?

> On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <[email-masked]> wrote:
> 
> On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H <[email-masked] <mailto:[email-masked]>> wrote:
> Just to be clear ...
> From: Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> 
> To: David Schinazi <[email-masked] <mailto:[email-masked]>>
> Cc: Toke Høiland-Jørgensen <toke=[email-masked] <mailto:[email-masked]>>; STARK, BARBARA H <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Feb 11, 2021, at 7:09 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://www.ietf.org/mailman/listinfo/babel <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>
>  
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Feb 2021 17:30:00 +0000

Hi Mahesh,
Would this still allow the YANG model to use the router-id as a unique key?
Barbara

Hi Barbara,

On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:

David

Hi David,

Cheers.

David

-Toke

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 18 Feb 2021 10:26:11 -0800

Hi Barbara,

Good question.

First a correction. Looking at the info-model, it is clear that there is support for one instance, i.e. one “router-id" on a given router at any particular time, and that there will NOT be multiple instances running on a router at the same time. I am specifically looking at the following line in the info-model.

binary                    ro babel-self-router-id;

I was therefore wrong in implying that the “router-id” acts as a key, as there is only one instance of the protocol on a given router.

If that is the case, the only thing we need from a modeling perspective is to make sure the “router-id” is valid, which is what the must statement allows us to do.

HTH. Thanks.

> On Feb 18, 2021, at 9:30 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> Hi Mahesh,
> On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <[email-masked] <mailto:[email-masked]>> wrote:
>  
Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Feb 2021 19:10:58 +0000

The info model only defines what a single instance looks like. In TR-181 I have the choice of supporting multiple instances (of this single instance) or not at the hierarchical level above where I put the Babel objects. I’ve chosen not to, consistent with how other routing protocols are modeled in TR-181 and because it doesn’t seem particularly valuable to support multiple instances on a single device.

So I’m quite OK with the YANG model supporting just a single instance and not needing to index on the router-id.

But this brings me to my next question. Since the router-id is read-only and its value is completely controlled by normative behavior defined in RFC 8966, do we need to say anything in the info model? Can we simplify the router-id to description to just be “The router-id used by this instance of the
      Babel protocol to identify itself.  [RFC8966<https://tools.ietf.org/html/draft-ietf-babel-information-model-12#ref-I-D.ietf-babel-rfc6126bis>] describes this as an arbitrary string of 8 octets.”  ?

Barbra

Hi Barbara,

Good question.

HTH. Thanks.

On Feb 18, 2021, at 9:30 AM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mahesh,

Hi Barbara,

David

Hi David,

Cheers.

David

-Toke

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 18 Feb 2021 16:19:15 -0800

Hi Barbara,

Yes, I am fine with dropping the last sentence in the description that has reference to the fact that it cannot be all zeros or ones. 

Thanks 

Mahesh Jethanandani 
[email-masked]

> On Feb 18, 2021, at 11:11 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> 
>       Babel protocol to identify itself.  [RFC8966] describes this as an arbitrary string of 8 octets.”  ?
>  
> Barbra
>  
> Hi Barbara,
>  
> Good question.
>  
> On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=[email-masked]> wrote:

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Feb 2021 20:21:35 +0100

> The router-id value MUST be unique among all instances of Babel on a device.

RFC 8966 Section 4.1.3 says:

   A router-id is an arbitrary 8-octet value.  A router-id MUST NOT
   consist of either all binary zeroes (0000000000000000 hexadecimal) or
   all binary ones (FFFFFFFFFFFFFFFF hexadecimal).

The rationale for that is that an all-zero value is useful as an internal
sentinel value, e.g. in order to mark that the router-id is not known
or that a data structure hasn't been initialised yet.

As to unicity, Babel assumes that router-ids are unique.  More exactly,
bad things will happen if the same prefix is announced by two routers with
the same router-id unless seqnos are synchronised.  I believe that you may
safely assume unicity, at least until such time when people try to
optimise the protocol by synchronising seqnos between distinct routers.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Feb 2021 20:26:54 +0100

> An enabled Babel instance (that is sending and receiving Babel packets) already
> has a requirement for unique non-zero router-id. Where we were having a problem
> was with not-enabled Babel instances that weren’t actively running the protocol
> (had maybe just been installed). I think it was babeld that was just using a
> default of all zeroes until it was enabled; at which time it generated its
> unique router-id. With this not-enabled “zero” default, the possibility exists
> for multiple not-enabled Babel instances to be defaulted to zero, which would
> lead to YANG having a problem with having a unique router-id to identify them
> by.

It's not an implementation problem, it's a protocol issue.

In the protocol, the router-id only appears on the wire when a router
redistributes (originates) a route.  If a router is not originating
routes, because it is only connected to transit networks, it does not need
a router-id.

So in this case, the information model would be imposing a slightly
stronger requirement on implementations than the core protocol: in order
to implement the information model, a router would need to draw a router-id
for itself even if it is only connected to transit networks.

I don't find this requirement too onerous, and I don't mind the
information model making it.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Feb 2021 22:22:43 +0000

Hi Juliusz,
We actually ended up figuring out that YANG didn't need to use it as a unique key and we removed all constraints in the -13 revision. It's a read-only parameter, so it's totally up to the Babel implementation to set a value. And the info / data models won't care or police.
Barbara