Subject: [manet] Adoption of draft-berger-manet-dlep-ether-credit-extension as a WG document

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 15 Jul 2021 17:55:53 +0000

Hi MANET WG,

As was pointed out by Lou Berger and Rick Taylor in the MANET session at IETF-110, draft-berger-manet-dlep-ether-credit-extension had process-wise fallen behind three other I-Ds related to credit-based flow control, currently in WGLC, for no compelling reason whatsoever. An adoption call for this draft on a IEEE 802.1Q-aware credit-window flow control extension to DLEP has been running for a long time, with no responses in favor or against from WG participants so far. While I am well aware of the drawbacks of 'silence procedure', this is what I am going to resort to now to break the stalemate: if you are opposed to the adoption of draft-berger-manet-dlep-ether-credit-extension as a WG document, speak up before July 24th, 2021!

Thanks,
Ronald
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Rogge, Henning" <[email-masked]>
Date: Wed, 21 Jul 2021 06:41:12 +0000

Hi,

do I read this "extension" correctly that it doesn't define a single TLV? This feels like a strange way to convey an information. DLEP information should be in TLVs, not in Extensions... extensions only define what TLVs we are allowed to exchange.​

Henning Rogge

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Jul 2021 09:24:51 -0400

Hi Henning,

We're digging into history from > 4 years ago -- at the time the 
directions from the chairs/WG was to break up the documents so that no 
document included more than one extension and that shared objects (data 
items/Sub-data items) go in their own documents.  So this is why we have 
a very short 
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/ 
as well as draft-berger-manet-dlep-ether-credit-extension

Lou

On 7/21/2021 2:41 AM, Rogge, Henning wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Rogge, Henning" <[email-masked]>
Date: Wed, 21 Jul 2021 13:34:38 +0000

Hi,

the reason why I ask is something I call "Radio/Router Attributes/Capabilities" that I would like to see as a DLEP draft/RFC.

Something like "can transmit multicast" or "can receive multicast", boolean things to know about the other side of the DLEP connection.

Being able to handle VLAN tagged traffic and/or VLAN PCP sounds quite similar.

I think it would be not good if we put each of these boolean capabilities into an extension of its own.

Having one TLV which contains the supported (explicitly not supported things in a second TLV?) could solve this issue and the capability your draft wants to transmit could be the first one using such a TLV.

Henning

---------------------

Hi Henning,

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Jul 2021 10:40:04 -0400

Other protocols I've worked with use such capability 
advertisement/negotiation -- I raised this point (with Stan?) at the 
time of reviewing the base DLEP standard and was told that DLEP uses the 
extensions to advertise/negotiate capabilities.

Lou

---

From: "Rogge, Henning" <[email-masked]>
Date: Fri, 23 Jul 2021 06:02:39 +0000

I think that the DLEP extension mechanism should be used to negotiate DLEP extensions... 

but in this case its somehow different... the extension has no TLV at all, but I feel it has some effect on some of the "sub-data-items" dlep-traffic-classification. I am not even sure why the draft use "sub-tlvs" at all, they complicate the parsing of DLEP quite a bit.

shouldn't a "this flow/link-id/neighbor can be reached over VLAN-ID/Codepoint xyz" be a TLV of the "dlep-ether-credit-extension" ? because if a radio or router doesn't support this extension, it doesn't make sense to define flows according to VLAN.

Henning

________________________________________
Von: Lou Berger <[email-masked]>
Gesendet: Mittwoch, 21. Juli 2021 16:40
An: Rogge, Henning; [email-masked]
Betreff: Re: AW: [manet] Adoption of draft-berger-manet-dlep-ether-credit-extension as a WG document

Lou

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 26 Jul 2021 16:15:45 +0000

Hi Henning, Lou,

(inline)

> -----Original Message-----
> From: manet <[email-masked]> On Behalf Of Lou Berger
> Sent: woensdag 21 juli 2021 15:25
> To: [email-masked]
> Subject: Re: [manet] Adoption of draft-berger-manet-dlep-ether-credit-
> extension as a WG document
> 
> Hi Henning,
> 
> We're digging into history from > 4 years ago -- at the time the directions
> from the chairs/WG was to break up the documents so that no document
> included more than one extension and that shared objects (data items/Sub-
> data items) go in their own documents.  So this is why we have a very short

I concur with Lou on this. draft-berger-manet-dlep-ether-credit-extension is the companion / counterpart of draft-ietf-manet-dlep-da-credit-extension: a PCP-based versus a DSCP-based approach. The real (shared) 'meat' is in draft-ietf-manet-dlep-traffic-classification (TC Data Item and Sub-Data Items) and draft-ietf-manet-dlep-credit-flow-control (actual flow control messages and data items). The decision to split was, for better or for worse, indeed made a long time ago; let's not relitigate it unless we are forced to by post-WG-process feedback.  draft-ietf-manet-dlep-da-credit-extension has practically completed WGLC.

Ronald

> > do I read this "extension" correctly that it doesn't define a single
> > TLV? This feels like a strange way to convey an information. DLEP
> > information should be in TLVs, not in Extensions... extensions only
> > define what TLVs we are allowed to exchange.​
> >
> >
> > Henning Rogge