Re: [babel] [netmod] NULL value for uint16

[Jürgen Schönwälder <[e-mail]>]

Hi Mahesh,

management interface usually do not change protocol semantics (for the
simple reason that protocol engines do not necessarily know which
management interfaces control them and their peers).

Does the Babel RFC reserve the special sequence number 0? If not, does
this document formally update the Babel RFC to reserve the sequence
number 0? And will implementations and deployments follow on or will
we see "old" and "updated" implementations in the wild causing
operational trouble?

/js

On Mon, Sep 13, 2021 at 12:49:33PM -0700, Mahesh Jethanandani wrote:
> [Bringing in babel WG, instead of maintaining two threads]
> 
> 
> Hi Juergen,
> 
> 
> > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder <[e-mail]> wrote:
> > 
> > On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> > 
> >> and it references an RFC that says:
> >> 
> >>      This is a 16-bit unsigned integer;
> >>      if the data model uses zero (0) to represent NULL values for
> >>      unsigned integers, the data model MAY use a different data type
> >>      that allows differentiation between zero (0) and NULL.
> > 
> > We are talking about RFC 9046? RFC 9046 repeats this sentence several
> > times but I find it difficult to infer the intended meaning. If 0 is a
> > legal value, you can't have it represent "NULL" at the same time.
> 
> There are five definitions in the Babel YANG model <https://www.ietf.org/archive/id/draft-ietf-babel-yang-model-11.html> that use NULL to represent a special meaning.
> 
> With ‘babel-route-received-metric’, and ‘babel-route-calculated-metric’ values use NULL or 0 to represent that a route was NOT received. A non-zero value indicates that a route was received and subsequently advertised.
> 
> With ‘babel-expo-mcast-hello-seqno’, and ‘babel-exp-ucast-hello-seqno’ a value of NULL or 0 is used to represent that a multicast, or unicast hello packets respectively are NOT expected or processing of multicast/unicast packets is not enabled. Although not explicit stated, it also means that the sequence number cannot be a 0.
> 
> Finally, with ‘babel-ucast-hello-seqno’ a value of NULL or 0 is used to represent a unicast hello is not being sent. A non-zero value reflects the current sequence number in use for unicast hellos. Again, although not explicit, it also means that the sequence number cannot be a 0.
> 
> > 
> > In YANG, we tend to not instantiate leafs that do not have a value.
> > Anyway, if a YANG author wants to report a special value to indicate
> > that there is no value, then you have design for it and reserve and
> > set aside a special value from the number space or use a union.
> 
> This YANG model reserves the value of 0 to indicate that these leafs are not set or the particular attribute is not enabled.
> 
> Thanks.
> 
> > 
> > RFC 9046 uses the same text for things like sequence numbers. Skimming
> > RFC 8966, it seems sequence numbers are 16-bit integers:
> > 
> >   Sequence numbers (seqnos) appear in a number of Babel data
> >   structures, and they are interpreted as integers modulo 2^(16).
> > 
> > The text in the context makes me believe they are an unsigned 16-bit
> > integers. If so, there simply is no way to use 0 to indicate that a
> > sequence number is absent. The problem really might be the text in RFC
> > 9046.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>