Re: [babel] proposed info model change

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi Mahesh,
> Would this still allow the YANG model to use the router-id as a unique key?
> Barbara
>  
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 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
>  
> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 
> Sent: Thursday, February 11, 2021 11:56 PM
> To: David Schinazi <[e-mail] <mailto:[e-mail]>>
> Cc: Toke Høiland-Jørgensen <toke=[e-mail] <mailto:[e-mail]>>; STARK, BARBARA H <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [babel] proposed info model change
>  
> Hi David,
>  
> 
> On Feb 11, 2021, at 7:09 PM, David Schinazi <[e-mail] <mailto:[e-mail]>> 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=[e-mail] <mailto:[e-mail]>> wrote:
> Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> 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
> 
> _______________________________________________
> babel mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/babel <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>
>  
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
>  
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
Mahesh Jethanandani
[e-mail]