Subject: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 14:02:18 -0500

Authors/WG,

The current version of DLEP contains two negotiations as part of a
Session Initialization transaction:
1) <Extensions Supported> is included in both the <Session
Initialization> and <Session Initialization Response> messages
2) the optional data items, <Resources> and <Relative Link Quality>

Both have parallel allocation policies:

   +-------------+-----------------------------------------------------+
   | Type Code   | Description                                         |
   +-------------+-----------------------------------------------------+
   | 0           | Reserved                                            |
   | 1           | Status (Section 10.1)                               |
     ...
   | 20          | Relative Link Quality (Transmit) (RLQT) (Section    |
   | 21-65407    | Reserved for future extensions                      |
   | 65408-65534 | Private Use. Available for experiments              |
   | 65535       | Reserved                                            |
   +-------------+-----------------------------------------------------+

                       Table 2: DLEP Data Item types

   +-------------+-----------------------------------------------------+
   | Code        | Description                                         |
   +-------------+-----------------------------------------------------+
   | 0           | Reserved                                            |
   | 1           | Credit Windowing                                    |
   | 2-65519     | Reserved for future extensions                      |
   | 65520-65534 | Private Use. Available for experiments              |
   | 65535       | Reserved                                            |
   +-------------+-----------------------------------------------------+

                       Table 4: DLEP Extension types

It seems to me that given the current definition, one of these two
should suffice.  I don't have a strong opinion on which, but do strongly
believe that a single approach should be selected to facilitate
interoperability.

To be clear, the following spells out the options:

Option A: Extensions (aka capabilities) based
  Any optional or new data item or message would need to be indicated
  in <Extensions Supported> to be used.  To cover the current optional
  data items the following would need to be defined:
    | 1 | Resources |
    | 2 | Relative Link Quality |
    | 3 | Credit Windowing |
  <Session Initialization Response> could still contain the optional
  data items, if the corresponding type is present in <Extensions
  Supported>

  Note that other messages will still use optional data items.

Option B: Data item based.
  An optional or new data item must be both Session Initialization
  messages to be used. To allow/enable <Resources> and <Relative Link
  Quality>, they would need to be included in both the <Session
  Initialization> and <Session Initialization Response> messages.

  To enable the Credit Windowing extension, the three credit-related
  state items, <Grant>, <Window Status>, and <Request> would need to be
  included in both session init messages for the full extension to be
  used.

Option C: keep both
  Keep current text

While I like Option A and have seen similar approaches in other
protocols, e.g., BGP Capabilities, I actually have a slight preference
for B.  The reason for this is DLEP uses optional data items in other
places and implementations will already need to handle this, so it seems
like option B will probably require smaller incremental code.

Either way, I think Option C is much less desirable then either of the
other options.

Thoughts? Opinions?

Lou

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 14:20:14 -0500

Lou,

> Both have parallel allocation policies:
Well, I disagree. Extensions defines a process whereby multiple data items,
and/or new *messages*, can be added to DLEP. The other two data items you
mention (Resources and Link Quality) are just optional (not required)
metrics. They are two different things.

> Either way, I think Option C is much less desirable then either of the

Before I did that, I'd be more inclined to pursue an "Option D":
1. All of the metric data items (e.g. - MDRR, MDRT, CDRR, CDRT, Latency,
RLQR, RLQT, RESR, REST) are listed, with no mention as to whether they are
mandatory or optional - they are just the pool of metrics that MAY be used
by an implementation.
2. In the Peer Init/Peer Init ACK, the peers list the metrics from the
available set that they are going to use. If peers cannot agree, the
session doesn't get established.

... and we're done. Again, the Extensions stuff is for new data
items/messages that might come along (with Credit Windowing being the
first).

Regards,
Stan

>
> Lou
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 15:01:52 -0500

Stan,

On 12/9/2015 2:20 PM, Stan Ratliff wrote:
> Lou, 
>
> On Wed, Dec 9, 2015 at 2:02 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Authors/WG,
>
>        | 0           | Reserved                                       
>         |
>        | 65535       | Reserved                                       
>         |
>        | Code        | Description                                   
>          |
>        | 0           | Reserved                                       
>         |
>        | 1           | Credit Windowing                               
>         |
>        | 65535       | Reserved                                       
>         |
> Well, I disagree. Extensions defines a process whereby multiple data
> items, and/or new *messages*, can be added to DLEP. The other two data
> items you mention (Resources and Link Quality) are just optional (not
> required) metrics. They are two different things.

I understand that their motivation is different, but the end result is
that code needs to be written (and tested!) to cover both.  So if
there's a way to eliminate two ways to do the same function, it's good
design to do so.

> 1. All of the metric data items (e.g. - MDRR, MDRT, CDRR, CDRT,
> Latency, RLQR, RLQT, RESR, REST) are listed, with no mention as to
> whether they are mandatory or optional - they are just the pool of
> metrics that MAY be used by an implementation.

Right, and this means that implementations need to dynamically track
which data items are in use on a per session, destination, and IP
basis.  This is a fair bit of mechanism already, and exactly why (a) I
raised this topic and (b) favor Option B.

> session doesn't get established.

Peer = session and ACK = response, right?  Yup, this is why I say use
this same mechanism for future extension too.  Again, different
motivation doesn't have to mean different mechanisms.

Lou

>     [email-masked] <mailto:[email-masked]>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 15:14:23 -0500

> >     Both have parallel allocation policies:

An implementation can chose to not support an extension. An implementation
can also chose not to support Resources and/or Link Quality. I guess I'm
missing something, because I'm not following this line of logic. If you
want to use the extension, or the extra metrics, then great - write and
test the code. If you don't, that's great, too.

> raised this topic and (b) favor Option B.

The current draft states that all metrics supported MUST be announced at
the peer level. I don't see a need to dynamically track at the destination
level, and we really don't have an IP basis.

> motivation doesn't have to mean different mechanisms.

If what you're advocating is that all optional, and extension-based, data
items be announced in the Peer exchange, then my question would be - what
about new, extension-based messages?

Regards,
Stan

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 15:55:30 -0500

Stan,

On 12/9/2015 3:14 PM, Stan Ratliff wrote:
>
>
> On Wed, Dec 9, 2015 at 3:01 PM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Authors/WG,
>     >
> An implementation can chose to not support an extension. An
> implementation can also chose not to support Resources and/or Link
> Quality. I guess I'm missing something, because I'm not following this
> line of logic. If you want to use the extension, or the extra metrics,
> then great - write and test the code. If you don't, that's great, too.

The point is there are different mechanisms that essentially do the same
function, so why not use one?

e.g., to indicate use of Resources and/or Link Quality, they are
included in the Session Init Response. (Which parallels use optional
data items in other messages.)  but to indicate use of Credit data
items, an extension value is used.

My point is that rather than coding two ways of 'negotiating' use of
options, it would be easier to define/use just one.

>     >       state items, <Grant>, <Window Status>, and <Request> would
>     need
>     >     to be
>     >     places and implementations will already need to handle this,
>     so it
>     >     seems
> The current draft states that all metrics supported MUST be announced
> at the peer level. I don't see a need to dynamically track at the
> destination level, and we really don't have an IP basis. 
>  
Not that it's critical, but if the destination mac is of the router and
they are always announced/updated together, you essentially do. 

> If what you're advocating is that all optional, and extension-based,
> data items be announced in the Peer exchange, then my question would be
This is option B.

> - what about new, extension-based messages?
Then either it can be implicit based on a negotiated data item, or less
cleanly, it can just be sent and ignored.

Lou

>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 16:52:43 -0500

Lou,

> options, it would be easier to define/use just one.

The point of putting the metrics in the Session Init/Session Init ACK
sequence was two-fold:  (1) to announce metrics in use for this radio, and
(2) to provide radio-specific defaults for those metrics. That way,
subsequent DLEP messages could focus only on metrics that had changed.
That's all documented in Section 3. So it wasn't really a negotiation, it
was an announcement and initialization of the metric values.

In the case of credit windowing, the same "announcement and init" notion
could apply, but in general, I'm opposed to just listing all Data Items in
the Session Init/Session Init ACK sequence - future, documented
enhancements to the protocol is what Extensions is for. But thinking about
this *did* lead me to something I perceive as a problem with the protocol:

Let's assume that someone comes up with an Extension that is a collection
of metric data items. Theoretically, that set of metric items would be
documented in the WG, discussed, approved, and a registry entry assigned.
So far, so good. But, on initialization, implementations would need to:
1. Announce support for the extension, via the "Extensions Supported" data
item, *and*
2. Announce the defaults, by plopping the new data items into the Session
Init/Session Init ACK sequence.

But, since there are *no* restrictions on ordering of Data Items in the
messages, I could well encounter the defaults *before* I encounter the
Extensions Supported data item - hence, I may (or may not) recognize those
new default metric data items as valid...

To clean up the misunderstanding, I propose that we add a new message (and
the corresponding ACK) to the sequence. Default metrics would be removed
from the Session Init/Session Init ACK sequence. After that exchange, the
modem issues the new message (I propose calling it the Session Metric
Initialization message) with the defaults for the metrics to be used. That
message is acknowledged, and then the router and modem drop into the
"In-Session" state.

Oh, and we can (and I think we should) remove the restrictions on what
metric items are MANDATORY... If an implementation receives the Session
Metric Initialization message, and it (for example) indicates "I'm only
going to use Resources-Transmit", there needs to be a status code for
"Well, in that case, you are a silly implementation, and I will not
continue with you". Followed, of course, by Session Termination.

WG participants? Thoughts? Flames?

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 9 Dec 2015 23:00:30 +0100

On Wed, Dec 9, 2015 at 10:52 PM, Stan Ratliff <[email-masked]> wrote:
> the Session Init/Session Init ACK sequence - future, documented enhancements
> to the protocol is what Extensions is for. But thinking about this *did*
> lead me to something I perceive as a problem with the protocol:
>
> Let's assume that someone comes up with an Extension that is a collection of
> metric data items. Theoretically, that set of metric items would be
> documented in the WG, discussed, approved, and a registry entry assigned. So
> far, so good. But, on initialization, implementations would need to:

A TLV (type length value) parser should not depend on the order of the TLVs...

so either you have to temporarily store all default metrics, or you
just do a two-stage parsing of the same message.

> going to use Resources-Transmit", there needs to be a status code for "Well,
> in that case, you are a silly implementation, and I will not continue with
> you". Followed, of course, by Session Termination.

We only have a few mandatory metrics (link speed related things,
right?)... I am not sure I am good with dropping them too.

This gives a router at least a chance to determine what this radio is
useful for.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 17:09:08 -0500

On Wed, Dec 9, 2015 at 5:00 PM, Henning Rogge <[email-masked]> wrote:

> enhancements

Yeah... two-stage parsing... don't know about you, but I'd like to avoid
that.

> "Well,

> This gives a router at least a chance to determine what this radio is

IMO, being able to negatively acknowledge the Session Metrics Init message
does the same thing, I think - a router has the opportunity to look at the
metrics being advertised by a modem, and make the determination you speak
of. Just for the record - I think a modem implementation that doesn't
announce link speed is pretty silly. But then, I don't claim to understand
each and every possible use case. Something that is totally absurd to us
might actually work for someone...

Regards,
Stan

P.S. In an earlier email on this thread, you mentioned "Alien Space Bats".
You're not going to write that up as a DLEP extension, are you? ;-) ;-) ;-)

---

From: Henning Rogge <[email-masked]>
Date: Wed, 9 Dec 2015 23:22:42 +0100

> Yeah... two-stage parsing... don't know about you, but I'd like to avoid

What I am doing at the moment is having a place to store every data
item I support... this way its possible to do a single-stage parsing.

Default values are only delivered by the radio to the router if I
remember it correctly, which happens after the router tells the radio
what it supports.

This means the router can instantly drop the session if it gets a
metric it does not support.

> might actually work for someone...

In fact its even "okay" to report both link speed and maximum link
speed once at a constant... so this should be EASY for any kind of
implementation.

Link speed is hard to measure for the router... lets keep it in there.

Henning

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 17:28:12 -0500

Stan,

On 12/9/2015 4:52 PM, Stan Ratliff wrote:
> But, since there are *no* restrictions on ordering of Data Items in
> the messages, I could well encounter the defaults *before* I encounter
> the Extensions Supported data item - hence, I may (or may not)
> recognize those new default metric data items as valid... 
>
I don't see this is a big deal, just means your code has to first parse
for syntax and then semantics.  Having implement similar (lack of)
ordering requirements before, it's not a big deal to code.

> To clean up the misunderstanding, I propose that we add a new message
> (and the corresponding ACK) to the sequence. Default metrics would be
> removed from the Session Init/Session Init ACK sequence. After that
> exchange, the modem issues the new message (I propose calling it the
> Session Metric Initialization message) with the defaults for the
> metrics to be used.

If you're trying to solve other issues, sure, but if you're just dealing
with the parsing issue, I'd simply highlight this possibility in the
text to help implementers.  Better to have two pass processing of one
message than two message exchanges. 

> That message is acknowledged, and then the router and modem drop into
> the "In-Session" state. 
>

I still think there may be holes in the protocol state machine, but
haven't had the time to do the full state analysis.

Lou

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Dec 2015 10:44:41 +0100

> You're not going to write that up as a DLEP extension, are you? ;-) ;-) ;-)

Might become useful for satellite communication, right? ^^

Henning

---

From: Rick Taylor <[email-masked]>
Date: Thu, 10 Dec 2015 10:18:41 +0000

I have previously used a Session Update message to carry extension data
items after Session Init.  Rather than include 'unknown' data items too
early (check my dlep destination service announcement draft)

I must admit to not being keen on adding an extra Init step to the state
machine with another message.

There might be some cross-over here however.  If we handle 'unexpected
data item' as a 'continue' status code, rather than a 'terminate', then
the issue disappears (apart from the 2-pass parse, but it's only at
session init, so I don't care about performance here).

Rick (still on vacation...)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 Dec 2015 10:20:57 +0000

I commented (and so far I've had one comment on one detail I noted, nothing else) on that the draft makes reference to an extensions register, and then really doesn't specify it.

I think part of this issue is that what an extension is needs more specification.

Is an extension defined completely by a list of new messages and/or data items that it consists of?

If no, what else? (Yes of course a new message requires new processing, but is that fully defined by the message type?)

If yes, why not drop the extensions register, and just list the messages and data items directly? OK, then there's an issue of what needs listing? And then you end up at Lou's comment, just list everything you are using. (Which needs to interact correctly with indicating default values.)

This does depend on the yes/no question above - and I think that regardless, the draft needs to be clearer on what an extension is to allow it to be answered.

There might be an issue with listing lots of items. Except you need to do this anyway for default values if I understand correctly.

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 09 December 2015 19:02
To: [email-masked]; MANET IETF
Subject: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Authors/WG,

The current version of DLEP contains two negotiations as part of a Session Initialization transaction:
1) <Extensions Supported> is included in both the <Session
Initialization> and <Session Initialization Response> messages
2) the optional data items, <Resources> and <Relative Link Quality>

It seems to me that given the current definition, one of these two should suffice.  I don't have a strong opinion on which, but do strongly believe that a single approach should be selected to facilitate interoperability.

Option C: keep both
  Keep current text

While I like Option A and have seen similar approaches in other protocols, e.g., BGP Capabilities, I actually have a slight preference for B.  The reason for this is DLEP uses optional data items in other places and implementations will already need to handle this, so it seems like option B will probably require smaller incremental code.

Either way, I think Option C is much less desirable then either of the other options.

Thoughts? Opinions?

Lou

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Dec 2015 12:25:08 +0100

> I commented (and so far I've had one comment on one detail I noted, nothing else) on that the draft makes reference to an extensions register, and then really doesn't specify it.

Maybe it should be something like an "extension id" registry?

> Is an extension defined completely by a list of new messages and/or data items that it consists of?

Not necessarily.

> If no, what else? (Yes of course a new message requires new processing, but is that fully defined by the message type?)

We don't know... that is why it is an extension... to add protocol
functionality we don't know yet.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 Dec 2015 12:33:00 +0000

I think it's worth just thinking about this. Can you suggest a plausible example where you need more information than just new message and data item types? It can be an alien space bats example ;)

(Of course there's more needed implicitly - such as what to do with a new message type. But the required information can be carried by just the new message type number.)

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 10 December 2015 11:25
To: Dearlove, Christopher (UK)
Cc: Lou Berger; [email-masked]; MANET IETF
Subject: Re: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

Not necessarily.

> If no, what else? (Yes of course a new message requires new 
> processing, but is that fully defined by the message type?)

We don't know... that is why it is an extension... to add protocol functionality we don't know yet.

> If yes, why not drop the extensions register, and just list the 
> messages and data items directly? OK, then there's an issue of what 
> needs listing? And then you end up at Lou's comment, just list 
> everything you are using. (Which needs to interact correctly with 
> indicating default values.)
>

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Dec 2015 13:39:03 +0100

> (Of course there's more needed implicitly - such as what to do with a new message type. But the required information can be carried by just the new message type number.)

We might have different kinds of "flow control" extensions using the
same kind of message.

Someone write "Flow Control Extension A"... and from the experiments
we learned that we can do a bit better than it, but its still a mutual
exclusive choice. So the author writes "Flow Control Extension B"
which reuse the messages he designed for A.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 Dec 2015 13:15:15 +0000

I'm not convinced by that example. Two extensions operating the way you describe is a potential interoperability nightmare. Different algorithms for calculating the flow control is already an issue - but is the same extension.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 10 December 2015 12:39
To: Dearlove, Christopher (UK)
Cc: Lou Berger; [email-masked]; MANET IETF
Subject: Re: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

On Thu, Dec 10, 2015 at 1:33 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> I think it's worth just thinking about this. Can you suggest a 
> plausible example where you need more information than just new 
> message and data item types? It can be an alien space bats example ;)
>
> (Of course there's more needed implicitly - such as what to do with a 
> new message type. But the required information can be carried by just 
> the new message type number.)

We might have different kinds of "flow control" extensions using the same kind of message.

Someone write "Flow Control Extension A"... and from the experiments we learned that we can do a bit better than it, but its still a mutual exclusive choice. So the author writes "Flow Control Extension B"
which reuse the messages he designed for A.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 10 Dec 2015 08:57:07 -0500

Chris,

First up, I'm in the process of looking at your review comments - I've just
been buried by the other threads, along with the day job.

On Thu, Dec 10, 2015 at 5:20 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I commented (and so far I've had one comment on one detail I noted,
> nothing else) on that the draft makes reference to an extensions register,
> and then really doesn't specify it.
>

The short answer is Yes. An extension could be a group of data items,
and/or new messages to the protocol.

>
> If no, what else? (Yes of course a new message requires new processing,
> but is that fully defined by the message type?)
>
> If yes, why not drop the extensions register, and just list the messages
> and data items directly? OK, then there's an issue of what needs listing?
> And then you end up at Lou's comment, just list everything you are using.
> (Which needs to interact correctly with indicating default values.)
>

The idea with the currently documented mechanism is that new functionality,
whether that's a collection of Data Items (potentially strewn about
multiple existing messages), and/or new messages, is grouped according to
functionality and assigned an extension number. As I envision it, an
extension number would map one-to-one with a DLEP follow-on draft. The
extension, regardless of its component make-up, is either supported (it
appears in Extensions Supported) or it's not.

If you simple list *everything* (both Data Items and messages), then it's
up to the receiver to make sure that the "everything" listed actually works
- for example, if I create an extension that has 4 new messages, but your
implementation lists only 3 of them, now what? It seems easier to me to
write up a spec and introduce it into the MANET WG, talk about the 4 new
messages (because the 4 messages make up a logical function that I want to
accomplish), then add the whole logical function as an Extension.
Implementations then either support it, or they don't.

>
> This does depend on the yes/no question above - and I think that
> regardless, the draft needs to be clearer on what an extension is to allow
> it to be answered.
>
> There might be an issue with listing lots of items. Except you need to do
> this anyway for default values if I understand correctly.
>

The default notion only applies to metrics. Right now, there are 9:
MDRR/MDRT
CDRR/CDRT
Latency
RESR/REST
RLQR/RLQT

That's why I'm proposing to add the "Session Metric Initialization" message
- to clear up some of the confusion, let's not use the session init to both
(a) establish the protocol level with Extensions Supported, and (b)
establish default values for metrics that are to be flowed over the
session. Let's let the Session Init establish the effective protocol level
and "bells & whistles" in play (the Extensions), and then explicitly set
the default metric values.

Regards,
Stan

> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> It seems to me that given the current definition, one of these two should
> suffice.  I don't have a strong opinion on which, but do strongly believe
> that a single approach should be selected to facilitate interoperability.
>
> While I like Option A and have seen similar approaches in other protocols,
> e.g., BGP Capabilities, I actually have a slight preference for B.  The
> reason for this is DLEP uses optional data items in other places and
> implementations will already need to handle this, so it seems like option B
> will probably require smaller incremental code.
>

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Thu, 10 Dec 2015 14:37:29 +0000

Extensions can add status codes too.

I can see a use for an extension that does not add any signals/messages,
data items, or status codes; it just adds behavior.  In particular, it
allows new combinations of the protocol elements that were previously
disallowed.  For example, an extension could allow an existing data item
on an existing signal.  dlep-17 appears to allow this, section 6 paragraph
1: 

    Such extensions are defined as *additional rules of behaviour,*
    messages, data items and/or status codes that are not defined in this
    document.

I've been thinking about this because of the discussion about which data
items (if any) should be allowed to appear on a Destination Up coming from
the router.  Let's say the result of that discussion is that we clamp down
hard and don't allow any data items other than the MAC address, and that
MAC address MUST represent a multicast address.  However, someone :) would
like the router to be able to advertise IP addresses and subnets that it
provides access to so that the modem can propagate this to the other side
(using a non-DLEP protocol).  So, we could add an extension that relaxes
Destination Up and Update to allow 1) unicast MAC addresses coming from
the router (the router would put its own MAC address), and 2) IP address
and IP subnet data items.  The extension would of course define what this
new combination means.  It adds no new messages or data items, but it's a
useful extension (to us).

You could certainly do this with a new message too, but a small tweak to
the allowed data items seems cleaner and easier to deal with to me.

David

On 12/10/15, 8:15 AM, "manet on behalf of Dearlove, Christopher (UK)"
<[email-masked] on behalf of [email-masked]> wrote:

>I'm not convinced by that example. Two extensions operating the way you
>describe is a potential interoperability nightmare. Different algorithms
>for calculating the flow control is already an issue - but is the same
>extension.
>
>Someone write "Flow Control Extension A"... and from the experiments we
>learned that we can do a bit better than it, but its still a mutual

---

From: Rick Taylor <[email-masked]>
Date: Fri, 11 Dec 2015 05:27:09 +0000

> the allowed data items seems cleaner and easier to deal with to me.

I completely agree here.  This is exactly how I see extensions being used.