Subject: [manet] DLEP-17 comments, part 3

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Dec 2015 16:18:06 +0000

A quick one, just sections 6 and 7.

Section 6, first line. I wouldn't write this (WG etc.) but that's a style issue.

Section 6, first paragraph, additional rules of behaviour. Those are tricky. New rules because of new messages, OK. But new rules in existing situations, that's a compatibility issue. I would suggest making it clear that's not intended. (You can't actually ban it, because an update could remove the ban ...)

Section 6, third paragraph. Not Reserved, that has a different meaning. See RFC 5226. All uses of Reserved in the document need review accordingly.

Section 7, line one. The specificity of thousands makes me want to ask for details.

Section 7, line 4, is this an RFC 2119 RECOMMENDED?

Section 7. This one paragraph covers two topics, which should be different paragraphs. The first is having lots of destinations. The second is managing each destination so as to not produce excessive data. (Actually, there's really a third, flapping isn't a DLEP problem, it's a use by the router of the data problem.) Only the first of these is scalability, the second is a different efficiency issue.
********************************************************************
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: Stan Ratliff <[email-masked]>
Date: Thu, 3 Dec 2015 14:28:31 -0500

Chris,

One item, inline:

On Thu, Dec 3, 2015 at 11:18 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Section 6, first line. I wouldn’t write this (WG etc.) but that’s a style
> issue.
>
>
>
> Section 6, first paragraph, additional rules of behaviour. Those are
> tricky. New rules because of new messages, OK. But new rules in existing
> situations, that’s a compatibility issue. I would suggest making it clear
> that’s not intended. (You can’t actually ban it, because an update could
> remove the ban …)
>
>
>
> Section 6, third paragraph. Not Reserved, that has a different meaning.
> See RFC 5226. All uses of Reserved in the document need review accordingly.
>
>
>
> Section 7. This one paragraph covers two topics, which should be different
> paragraphs. The first is having lots of destinations. The second is
> managing each destination so as to not produce excessive data. (Actually,
> there’s really a third, flapping isn’t a DLEP problem, it’s a use by the
> router of the data problem.) Only the first of these is scalability, the
> second is a different efficiency issue.
>

I think the flapping actually is a DLEP problem - a flapping station on the
far-end of an RF connection could well produce a storm of corresponding
'Destination Up/Destination Down' messages. The text is intended to say
that those types of issues need to be considered.

Regards,
Stan

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

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Dec 2015 20:33:15 +0000

Fair point. I was considering the flapping as inducing routing algorithm instability. That's a worse problem in term in that a linear increase in number of changes may do much worse than that to the routing. That isn't a DLEP problem, as the router in turn can smooth and/or use hysteresis. But just simply that putting every change on the wire is, as you say, a DLEP issue.

(There are solutions that aren't exactly smoothing or hysteresis, but that's up to the modem, not DLEP.)

I don't have DLEP in front of me to re-read and consider if/how I'd suggest a change in wording. But that I didn't pick that up says something, though whether about DLEP or my reading I don't know.

(I'm hoping to finish looking at the draft tomorrow, but no guarantees.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 3 Dec 2015, at 19:28, Stan Ratliff <[email-masked]> wrote:
> 
> Chris, 
> 
> One item, inline: 
> 
>> On Thu, Dec 3, 2015 at 11:18 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> Section 6, first line. I wouldn’t write this (WG etc.) but that’s a style issue.
>> 
>>  
>> 
>> Section 6, first paragraph, additional rules of behaviour. Those are tricky. New rules because of new messages, OK. But new rules in existing situations, that’s a compatibility issue. I would suggest making it clear that’s not intended. (You can’t actually ban it, because an update could remove the ban …)
>> 
>>  
>> 
>> Section 7. This one paragraph covers two topics, which should be different paragraphs. The first is having lots of destinations. The second is managing each destination so as to not produce excessive data. (Actually, there’s really a third, flapping isn’t a DLEP problem, it’s a use by the router of the data problem.) Only the first of these is scalability, the second is a different efficiency issue.
>> 
> 
> I think the flapping actually is a DLEP problem - a flapping station on the far-end of an RF connection could well produce a storm of corresponding 'Destination Up/Destination Down' messages. The text is intended to say that those types of issues need to be considered. 
> 
> Regards,
> Stan
> 
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Dec 2015 21:59:44 +0100

> that's up to the modem, not DLEP.)

Could you please explain?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Thu, 3 Dec 2015 22:03:25 +0100

> Could you please explain?

Rate limitation maybe?

Only allow a certain number of up/down events per neighbor per "time interval"?

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Dec 2015 21:04:43 +0000

Off the top of my head, you can for example set a minimum change that you allow, suppressing values that are within that margin of the last value. Or you can set a maximum rate of updates. I'm sure other strategies can be devised.

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 3 Dec 2015 21:22:58 +0000

Yeah.  Here's an example of event dampening from Cisco: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_ipevdp.html 

Regards,
Stan

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
> Sent: Thursday, December 03, 2015 4:03 PM
> To: Juliusz Chroboczek <[email-masked]>
> Cc: Christopher Dearlove <[email-masked]>;
> [email-masked]
> Subject: Re: [manet] DLEP-17 comments, part 3
> 
> On Thu, Dec 3, 2015 at 9:59 PM, Juliusz Chroboczek <[email-masked]
> diderot.fr> wrote:

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________