Subject: Re: [Roll] Triggering a new DODAG iteration

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Mar 2010 23:33:05 +0100

HI Robert :

This makes a lot of sense to me. Other root decisions like a source
route path selection could also benefit from such error/info reporting.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Assimiti
Sent: Thursday, March 18, 2010 1:24 PM
To: [email-masked]
Subject: [Roll] Triggering a new DODAG iteration

As you can imagine, triggering a new DODAG iteration in a wireless
subnet that scales to thousands of wireless nodes can be quite
disruptive to the operation of the subnet.

The criteria that will trigger a new DODAG iteration should (in my
opinion) be left to the implementation.

The decision of triggering a new DODAG iteration lies with the root. 

A well informed root can make better decisions than an un-informed root.

Hence I propose that we discuss additional standardized error messages
reported by the routers.

At this point nodes can flag rank and forwarding errors through the
usage of the 'R' and 'F' bits present in the flow label.

In my opinion, this is a very limited set of error messages. 

Since we are seeking interoperability,  we should define a new ICMPv6
error message that allows the nodes to report various DODAG
inconsistencies and discrepancies with more details and precision than
the 'R' and 'F' bits. 

Some suggestions for potential reported errors:

1.       Preferred parent not reachable

2.       Parent not reachable

3.       Parent set nears depletion

Etc ....etc

Armed with this information (sent in an interoperable manner) the root
is now capable of making a more informed decision when to trigger a new
DODAG iteration.

Any thoughts? Suggestions?

 

Robert Assimiti

Office: [678]-202-6859

Mobile: [404]-578-0205

[email-masked]

________________________________

This e-mail (including any attachments to it) is confidential,
proprietary, legally privileged, subject to copyright and is sent for
the personal attention of the intended recipient only. If you have
received this e-mail in error, please reply to advise us immediately,
delete it and destroy any printed copies of it. You are notified that
reading, disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited. No
employee is authorized to conclude any binding agreement on behalf of
NIVIS LLC with another party by e-mail without express written
confirmation by an officer of the company. Although we have taken
reasonable precautions to ensure no viruses are present in this e-mail,
we cannot accept responsibility for any loss or damage arising from the
viruses in this e-mail or attachments.

---

From: Robert Assimiti <[email-masked]>
Date: Fri, 19 Mar 2010 11:14:54 -0400

Hello Pascal,

It seems that we see eye to eye on this issue and that we both agree that this would be very useful for multiple reasons.

Should we start identifying a set of various error/info reporting messages?

Robert Assimiti
Office: [678]-202-6859
Mobile: [404]-578-0205

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 18, 2010 6:33 PM
To: [email-masked]
Subject: Roll Digest, Vol 26, Issue 46

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/roll

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Roll mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."

Today's Topics:

   1. Triggering a new DODAG iteration (Robert Assimiti)
   2. Re: Triggering a new DODAG iteration (Pascal Thubert (pthubert))

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

Message: 1
Date: Thu, 18 Mar 2010 16:24:28 -0400
From: Robert Assimiti <[email-masked]>
Subject: [Roll] Triggering a new DODAG iteration
To: "[email-masked]" <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

As you can imagine, triggering a new DODAG iteration in a wireless subnet that scales to thousands of wireless nodes can be quite disruptive to the operation of the subnet.

The criteria that will trigger a new DODAG iteration should (in my opinion) be left to the implementation.
The decision of triggering a new DODAG iteration lies with the root.
A well informed root can make better decisions than an un-informed root.

Hence I propose that we discuss additional standardized error messages reported by the routers.
At this point nodes can flag rank and forwarding errors through the usage of the 'R' and 'F' bits present in the flow label.

In my opinion, this is a very limited set of error messages.
Since we are seeking interoperability,  we should define a new ICMPv6 error message that allows the nodes to report various DODAG inconsistencies and discrepancies with more details and precision than the 'R' and 'F' bits.
Some suggestions for potential reported errors:

2.       Parent not reachable

Armed with this information (sent in an interoperable manner) the root is now capable of making a more informed decision when to trigger a new DODAG iteration.

Robert Assimiti
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]<mailto:[email-masked]>

________________________________
This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20100318/55450969/attachment.htm>

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

Message: 2
Date: Thu, 18 Mar 2010 23:33:05 +0100
From: "Pascal Thubert (pthubert)" <[email-masked]>
Subject: Re: [Roll] Triggering a new DODAG iteration
To: "Robert Assimiti" <[email-masked]>, <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

HI Robert :

Pascal

2.       Parent not reachable

Etc ....etc

 

Robert Assimiti

Office: [678]-202-6859

Mobile: [404]-578-0205

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20100318/7215573e/attachment.htm>

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

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

End of Roll Digest, Vol 26, Issue 46
************************************