[manet] Re: draft-ietf-manet-dlep-radio-band-01 early Rtgdir review

On Sat, May 3, 2025 at 5:33 PM Russ White via Datatracker
<[email protected]> wrote:
>
> Document: draft-ietf-manet-dlep-radio-band
> Title: DLEP Radio Band Extension
> Reviewer: Russ White
> Review result: Has Nits
>
> ==
> nit --
>
> The Item can be used in a neighbor specific message if the radio use
>    dedicated subcarriers to talk to neighbors.
>
> use/uses
>
> ==
> nit --
>
> Frequency selection is often controlled by the radios configuration.
>
> radios/radio's

both fixed in -02

> question --
>
> This might not apply here, but should it be possible to extend the signaling
> here to things like spread spectrum channels?

If you have a suggestion what would be needed to include spread
spectrum channels I would be happy to add this to the draft...

> ==
> question --
>
>    Request Link Characteristics message) be used to change the frequency
>    of the radio in a standardized way.
>
> This would seem to inlude frequency hopping support (?). Would there be any
> timing limits on how often a radio could swap channels (there may be timing
> limits later in the doc I've not hit yet)?

Yes, I think the usecase for frequency hopping could be included in a
DLEP extension, but I am not sure if it should be in this one or a
special extension of its own.

I am also not completely sure what we would need for a good frequency
hop TLV beyond a list of radio center frequencies to be used for
hopping. The hopping sequence itself would most likely be
pseudo-random. We might also need to differentiate between "frequency
range/bandwidth" the hopping pattern uses in total vs. the same value
for each hop.

I would really like to discuss this further, either for including it
into version -03 or maybe thinking about another draft.

> ==
> nit --
>
> The format of the Radio Band Data Item is:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Data Item Type                | Length                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Carrier Frequency                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Carrier Frequency                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Bandwidth                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Bandwidth                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Flags     |
>    +-+-+-+-+-+-+-+-+
>
> I find this format a little confusing, as it could indicate two different
> carrier frequency fields (?): I think a possibly easier to understand format
> might be something like:

Both carrier frequency and bandwidth are 64 bit in length... I will
mention this explicitly in the -02 revision.

> The format of the Radio Band Data Item is:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Data Item Type                | Length                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Carrier Frequency                       |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Bandwidth                           |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Flags     |
>    +-+-+-+-+-+-+-+-+
>
> ==
> question --
>
> The length of the Radio Bnd Data Item is set to 17. If this won't ever change
> (and the packet format seem to be set up to support fixed length values), does
> the length need to be included? Could the Flags field be moved to where the
> length is?

The length field must be included otherwise we break the parser... the
TLV (type/length/value) format allows to parse the datastream without
understanding all TLVs because you can just skip forward about things
you don't know about.

Henning Rogge


Henning Rogge

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]