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

Abdussalam Baryun <[email protected]>
Newsgroups gmane.ietf.manet
Message-ID <CADnDZ8-tyJ4UjfS0c4a-edgj_KUPTpTKLXPCsG+T3J1LGezS6Q@mail.gmail.com>
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.

Firstly, this new draft has some changes due to reviewer-discuss, so I
would like to discuss with you those changes

>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

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

> 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.


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?

>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.

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?
AB> why not adding L1-channel/traffic type value?


Best Regards

AB


On Mon, May 12, 2025 at 9:30 AM <[email protected]> wrote:

> Internet-Draft draft-ietf-manet-dlep-channel-utilization-02.txt is now
> available. It is a work item of the Mobile Ad-hoc Networks (MANET) WG of
> the
> IETF.
>
>    Title:   DLEP Radio Channel Utilization Extension
>    Author:  Henning Rogge
>    Name:    draft-ietf-manet-dlep-channel-utilization-02.txt
>    Pages:   8
>    Dates:   2025-05-12
>
> Abstract:
>
>    This document defines an extension to the Dynamic Link Exchange
>    Protocol (DLEP) to provide the utilization of a radio channel.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-channel-utilization/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-manet-dlep-channel-utilization-02.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-manet-dlep-channel-utilization-02
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> manet mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.