[manet] Re: I-D Action: draft-ietf-manet-dlep-channel-util ization-02.txt

On Thu, Jun 12, 2025 at 11:26 AM Abdussalam Baryun
<[email protected]> wrote:
>
> Hi draft-author and WG,
>
> My review AB-2  for the subject titled WG draft.
>
> Before any review just to say that this draft is not updating RFC8175, but this is an extension draft.

I am not sure if you are making any point here... as stated
practically everywhere this draft defines a dlep extension. I am not
sure how anyone could get the idea this draft updates RFC8175.

> >Active Time:Time in nanoseconds since the channel has been in use
>
> I agree with the definition of active time within the table 1, so I think this is the total time of the channel available for communication, so when we change in the draft as define as *used*  doesn't that mean busy channel. If yes please amend because I think the table 1 should be consistent within all draft

I disagree with this change... "busy" is more than just "used", busy
could (as an example) also mean that the channel had too much
noise/interference in it to be used for data transmission at a certain
time.

> This draft supports 8175, so the *dynamic-links* can be point-to-point or shared medium as mentioned in RFC8175.

"supports 8175" ? Are you making a point here?

> > Abstract>
> >This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel
>
>
> AB>amend to>Abstract>
> This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the radio channel utilization tlv to the peer router. The radio channel utilization provided measurements at the modem of the data plane radio channel for the router awareness.
>
> AB>reason> the abstract is short, and it needs to specify the extension is tlv_extension, and  we need not to exclude that some MANET may use separate data/control planes/channels per router-modems.

I disagree with this change. The whole reason the IETF defined RFC
8175 (DLEP) is to provide router awareness about the internal
knowledge of the radio. I see no reason to repeat this in the abstract
of an extension.

> AB>
>
> > draft>section 1> introduction>
> mentions the channel utilization (unicast traffic) between two routers,
> so is it only point-to-point  links this draft is specifying, Please advise?

Please read the sentence again... "the amount of airtime used by
management traffic of the radio is invisible to the router, as is
unicast traffic between two adjecant radios"

These are just two examples (management traffic and point-2-point
traffic between remote nodes) why the point of view of the router
about the radio channels utilization might be flawed.

> >draft>section 1>
>
> >A radio that is using independent channel resources for each neighbor (e.g. by beam forming) can also track and report channel usage time for each DLEP neighbor.
>
> AB> amend>  measurement how a radio channel time is used and how much time resources are available
> AB> reason> radio channel doesn't always/only mean time.

This draft specifies TLVs to transport the radio channel usage over
time... nothing more.

If you want to provide more detailed information, you are free to
write a new draft.

> AB>section 2>
> A radio that is using independent channel resources for each neighbor (e.g. by beam forming) can also track and report channel usage time for each DLEP neighbor.
>
> AB> the channel usage will be reported per used-beam, because  DLEP neighbor may have two beams per one radio-channel. There is a spatial usage added to the time resources.
>
> AB> does the draft consider the dynamic channel allocation issues?

No, it does not.

> AB> why not adding L1-channel/traffic type value?

If you have a specific thing in mind you should state it in your
emails. Or start writing a draft document that provides more explicit
knowledge that is generic enough to be provided by multiple radio
vendors.

Henning Rogge

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