Subject: Re: [Roll] Ticket 50

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Jun 2010 16:48:53 +0200

Hi:

I think we can follow Mathilde all the way though here:

1) leaf nodes would not send DIOs. When they are a router and decide to
become a leaf, they can poison as a router and then become a leaf. If
after that get packets they should route, they can reject in the data
plane (and ICMP for source route).

2) DIO without a T flag. Now that we have DAO Ack, there is no DAO loss
so maybe it's not needed oto cover DAO loss. For non storing, since we
send per hop transit info, there isi no need to tell the children that
the node has moved. So the mechanism is of little use in "normal"
conditions. It appears that the node could use the mechanism upon
inconsistency detection or after a local repair, for instance if a node
goes down and some children have grown up... 

Pascal

> -----Original Message-----
> From: JP Vasseur [mailto:[email-masked]]
> Sent: Monday, June 14, 2010 10:32 AM
> To: Pascal Thubert (pthubert)
> Subject: Re: Ticket 50
> 
> Could you drive and close with Mathilde ?
> That'd be great.
> 
> Thanks !
> 
> JP.
> 
> On Jun 14, 2010, at 8:43 AM, Pascal Thubert (pthubert) wrote:
> 
> > Hello Again
> >
> >> Ticker #50: while this is fresh in your mind could you point me the
> > new text
> >> that I can point to in the document to close the ticket:
> >> https://svn.tools.ietf.org/wg/roll/trac/ticket/50
> >>
> >
> > [Pascal] This one I'm unsure..
> >
> > Pascal

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 10:54:02 +0200

Mathilde,

Does that clarify ? Let know if we can close the ticket, you want some  
text somewhere, ...

Thanks.

JP.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 18 Jun 2010 10:46:23 +0200

Hi JP,

For 1) Section 7.5. "Operation as a Leaf Node" needs to be updated. Here is
a proposal:
------
In some cases a RPL node may attach to a DODAG as a leaf node only. One
example of such a case is when a node does not understand the RPL Instance's
OF or advertised path metric.  A leaf node does not extend DODAG
connectivity and as a consequence it must obey the following rules:

   1.  It MUST NOT transmit DIOs
   3.  It MAY transmit unicast DAOs as described in Section 8.2.
   4.  It MAY transmit multicast DAOs to the '1 hop' neighborhood as
       described in Section 8.10.

If a node that is a router wants to become a leaf node. It SHOULD first
poison its routes (advertising a Rank of INFINITE_RANK)
-------

For 2), changes are needed as well, both in the DIO format and in section
8.5. I'm still a bit unclear about the different use cases trade-off
concerning the DTSN / T bits and Tim just started a new thread on the topic
so I will bounce on his email.

Thanks,
Mathilde 

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: jeudi, 17. juin 2010 10:54
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: Tim Winter; ROLL WG
Subject: Re: Ticket 50

Mathilde,

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 11:02:25 +0200

Hi Mathilde,
This is exactly along the lines of what we were planning to add :-)
Thanks.

JP.

---

From: Tim Winter <[email-masked]>
Date: Sun, 20 Jun 2010 19:17:58 -0400

Hi Mathilde,

> poison its routes (advertising a Rank of INFINITE_RANK)

I think 'MUST NOT' transmit DIOs is too strong.  I think that the poisoning is good 
and useful in the optimistic case, but due to the lossy nature of LLN the poisoning 
may not be 100% effective.  In practice most leaf nodes might not be impacted by 
this, but in some cases there may be a leaf node that has prior children left over 
from an old DODAG, and at the very least should be allowed to send the DIO to repair 
the situation when an inconsistency is detected should one of those children forward 
to the leaf node.  I do agree with the motivation to suppress sending DIOs from leaf 
nodes in the general case.  How about this revised set of rules:

         Operation as a Leaf Node

         In some cases a RPL node may attach to a DODAG as a leaf node only.
         One example of such a case is when a node does not understand the RPL
         Instance's OF or advertised path metric.  A leaf node does not extend
         DODAG connectivity but in some cases still needs to advertise DIOs in
         order to participate in DODAG maintenance and repair.  A node
         operating as a leaf node must obey the following rules:

         1.  It MUST NOT transmit DIOs containing the DAG Metric Container.

         2.  Its DIOs MUST advertise a DAGRank of INFINITE_RANK.

         3.  It MAY suppress DIO transmission, except DIO transmission MUST
             NOT be supressed in the case where DIO transmission has been
             triggered due to detection of inconsistency when a packet is
             being forwarded.

         4.  It MAY transmit unicast DAOs as described in Section 8.2.

         5.  It MAY transmit multicast DAOs to the '1 hop' neighborhood as
             described in Section 8.10.

         A particular case that requires a leaf node to send a DIO is if that
         leaf node was a prior member of another DODAG and another node
         forwards a message assuming the old topology, triggering an
         inconsistency.  The leaf node needs to transmit a DIO in order to
         participate in the repair.  Note that due to the lossy nature of
         LLNs, even though the leaf node may have optimistically poisoned its
         routes by advertising a rank of INFINITE_RANK in the old DODAG prior
         to becoming a leaf node, that advertisement may have become lost and
         a leaf node must be capable to send a DIO later in order to repair
         the inconsistency.

         In general it is not expected that such a leaf node would advertise
         itself as a router.

---

From: Philip Levis <[email-masked]>
Date: Sun, 20 Jun 2010 17:30:07 -0700

On Jun 20, 2010, at 4:17 PM, Tim Winter wrote:

> I think 'MUST NOT' transmit DIOs is too strong.  I think that the  
> poisoning is good and useful in the optimistic case, but due to the  
> lossy nature of LLN the poisoning may not be 100% effective.  In  
> practice most leaf nodes might not be impacted by this, but in some  
> cases there may be a leaf node that has prior children left over  
> from an old DODAG, and at the very least should be allowed to send  
> the DIO to repair the situation when an inconsistency is detected  
> should one of those children forward to the leaf node.  I do agree  
> with the motivation to suppress sending DIOs from leaf nodes in the  
> general case.  How about this revised set of rules:
>
>         Operation as a Leaf Node
>

Tim, I agree with your text. It's important for a leaf to be able to  
send DIOs, e.g., if it needs to poison routes from when it used to be  
a router. This could happen if a root suddenly changes the metrics or  
constraints for an abstract OF.

Phil

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 21 Jun 2010 09:23:42 +0200

Hi Tim, 

I agree with your text as well. However, in my mind some nodes might also be
configured as leaf node from the start. In such a case, no DIO sending will
ever be needed and probably the DIO sending code won't even be included in
the image. I'm not sure if we need to make this case more explicit...

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: lundi, 21. juin 2010 02:30
To: Tim Winter
Cc: ROLL WG
Subject: Re: [Roll] Ticket 50

Phil

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jun 2010 13:20:02 +0200

Hi Mathilde:

I love this thread because as far as I can say, you are all correct. The
thing is, a node that reboots may not know that it has been a router in
a past life...
But it can discover that other nodes think so:

- An (ex)child sends a packet up via the leaf:
  the leaf can reject on a per node basis in the datapath 

- An (ex)parent sends a packet down via the leaf:
  the leaf can reject on a per node basis in the datapath 

- the node sends a DAO
  The leaf can reply with a negative DAO

- An (ex)child advertises the leaf as a source route parent, and the
leaf gets a source routed packet
  the leaf rejects the SR with an ICMP, the root cleans up but the child
keeps advertising the wrong transit info.

It seems that we're mostly covered, but in the source route case.
In most cases, an additional poisoning could calm down other children
and thus save resources.
So it appears to be a good idea to allow a leaf to poison on any event
where it's mistaken for a router...

BTW I think that Tim's text is really good.

Pascal

> Mathilde Durvy (mdurvy)
> Sent: Monday, June 21, 2010 9:24 AM
> To: Philip Levis; Tim Winter
> Cc: ROLL WG
> I agree with your text as well. However, in my mind some nodes might
also
> be configured as leaf node from the start. In such a case, no DIO
sending will
> ever be needed and probably the DIO sending code won't even be
included
> in the image. I'm not sure if we need to make this case more
explicit...
> >> For 1) Section 7.5. "Operation as a Leaf Node" needs to be updated.
> >> Here is a proposal:
> >> ------
> >> DODAG connectivity and as a consequence it must obey the following
> >> rules:
> >>
> >> If a node that is a router wants to become a leaf node. It SHOULD
> >> first poison its routes (advertising a Rank of INFINITE_RANK)
> >
from
> > an old DODAG, and at the very least should be allowed to send the
DIO
> > to repair the situation when an inconsistency is detected should one
> > of those children forward to the leaf node.  I do agree with the
> > motivation to suppress sending DIOs from leaf nodes in the general
> > case.  How about this revised set of rules:
> >
> >         Operation as a Leaf Node
> >
> >         In some cases a RPL node may attach to a DODAG as a leaf
node
> > only.
> >         One example of such a case is when a node does not
understand
> > the RPL
> >         Instance's OF or advertised path metric.  A leaf node does
not
> > extend
> >         DODAG connectivity but in some cases still needs to
advertise
> > DIOs in
> >         3.  It MAY suppress DIO transmission, except DIO
transmission
> > MUST
> >             triggered due to detection of inconsistency when a
packet
> > is
> >         inconsistency.  The leaf node needs to transmit a DIO in
order
> > to
> >         participate in the repair.  Note that due to the lossy
nature
> > of
> >         routes by advertising a rank of INFINITE_RANK in the old
DODAG
> > prior
send DIOs,
> e.g., if it needs to poison routes from when it used to be a router.
This could
> happen if a root suddenly changes the metrics or constraints for an
abstract
> OF.

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Jun 2010 11:01:10 -0400

> Date: Sun, 20 Jun 2010 19:17:58 -0400
> From: Tim Winter <[email-masked]>
> 
>
> cases there may be a leaf node that has prior children left over from
> an old DODAG, and at the very least should be allowed to send the DIO

This looks good to me, with one addition below.

>           [...]

Also, a DIO sent in response to a unicast DIS MUST NOT be
suppressed.
                                 -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jun 2010 17:40:32 +0200

Perfect : )

Pascal

> Richard Kelsey
> Sent: Monday, June 21, 2010 5:01 PM
> To: Tim Winter
> Cc: [email-masked]
> > > One example of such a case is when a node does not understand the
> > > RPL Instance's OF or advertised path metric.  A leaf node does not
> > > extend DODAG connectivity and as a consequence it must obey the
> following rules:
> > >
from
DIO
> >          3.  It MAY suppress DIO transmission, except DIO
transmission MUST
> >              triggered due to detection of inconsistency when a
packet is
> >              being forwarded.
> 
> Also, a DIO sent in response to a unicast DIS MUST NOT be suppressed.
>                                  -Richard Kelsey