Subject: Re: [Roll] how does a node get an IP address

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 5 May 2010 16:18:49 +0200

Hi Pascal,

I fully agree with you.
In my opinion anything spanning multiple IP hops should not be done by ND.

On a related topic....
6lowpan network have the particularity that you cannot use on-link prefix
due to the non-transitivity of the wireless links. This means we need to
tell routers how to reach neighboring IPv6 hosts. So essentially 6lowpan-ND
is using a registration mechanism to establish a "route" between the router
and the host.  
It is not clear to me whether this is the role of ND or of the routing
protocol. I think it could actually be both. 
Hence the questions: 
- Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is
used?
- Should IPv6 hosts be part of a RPL topology (as leaf node) or should IPv6
hosts use the 6lowpan-ND host-router spec?

Best,
Mathilde 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: jeudi, 29. avril 2010 09:01
To: [email-masked]; Richard Kelsey
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] how does a node get an IP address

Hi Zach:

I have yet to review the new ND-09 but my guts tell me that it is the wrong
place to do the job. Router to router is usually routing protocol land and
ND is definitely not a routing protocol.

The main question is how long can  a router advertise a prefix, and the
answer is, as long as it is in the same subnet of an authoritative router
that owns the prefix.
Asserting the continuous reachability of the authoritative router is a
routing protocol problem. Maintaining a subnet together is the job for a new
form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that.

Let see:

- Propagating the RA content is not an ND intrinsic  problem, it only comes
with route over. And route over comes with a routing protocol.
- the route over protocol should be able to tie the route over subnetwork
together so it is a SGP.

So why can't we just say in 6LoWPAN ND that you for those who use it in
route over we expect an SGP to tie the route over subnetwork together and
that the SGP should transport the RA content, maintaining the validity with
the reachability of the authoritative router? I can write that text if you
wish.

It seems that we have a reasonable consensus in this thread to do exactly
that in RPL anyway...

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Tuesday, April 27, 2010 10:36 PM
> To: Richard Kelsey
> Cc: [email-masked]
> Subject: Re: [Roll] how does a node get an IP address
> 
> Hi Everyone,
> 
> Let me jump into this thread - just to make things more interesting
;-) First, I
> recommend everyone goes and reads 6lowpan-nd-09 which was submitted 
> today. When it comes to ND, you need to separate two interfaces.
> 
> 1. The host-router interface
> 
> Hosts know absolutely nothing about RPL (nor should they). Thus in
this case
> ND* does the job, and RS/RA is used for obtaining a prefix and
initializing its
> addresses. I think some people in the thread are referring to this.
> 
> 2. The router-router interface
> 
> As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than
hosts in
> how they obtain prefix information (among other things). nd-09 does
include
> an optional technique for an authorative border router to disseminate
PIOs
> and CIOs (Context Information Options) between the border router and
all
> routers in the LoWPAN using RAs. It is actually a decent mechanism and 
> improved over early versions. The draft clearly states that it is
optional as a
> routing algorithm may already do this. So Pascal is correct in that
respect. I
> haven't followed the thread well enough to have an opinion if RPL
should do
> that.
> 
> Routers will also find other features of 6lowpan-nd-09 useful, for
example
> during initial bootstrapping, to maintain their default router and
neighbor
> caches, avoid the need for address resolution, and to perform NUD. The 
> draft (tries to) clearly state when features are required or optional
for a
> router.
> 
> Zach
> 
> 
> >> From: Michael Richardson <[email-masked]>
> >> Date: Tue, 27 Apr 2010 10:38:47 -0400
> >>
> >> >>>>> "Richard" == Richard Kelsey <[email-masked]>
writes:
> >>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
> >>     >> (pthubert)" <[email-masked]>
> >>     >>
> >>     >> The question here is that the authoritative routers need to
> >>     >> disseminate the PIO (and the RIO) to all routers in the
subnet.
> >>
> >>     Richard> How do other routing protocols (OSPF, IS-IS, AODV,
OLSR)
> >>
> >> I can only speak for OSPF and ISIS.
> >> Neither deal with multi-hop subnets or with any kind of address 
> >> assignment.
> >
> > Why should RPL be any different?  Yes, it will be run on multi-hop 
> > subnets, but I still do not see how this affects the routing.
> >
> >> Both were written when multicast was very new.
> >
> > I am not sure how RPL's handling of multicast matters here.
> > While RPL is required to route multi-hop multicasts, ND uses 
> > link-local multicasts, which do not require routing.
> >
> >> Richard> I understand that multi-hop subnets are a problem for ND, 
> >> Richard> but I don't see how the routing protocol is affected.
> >>
> >> RPL either requires 6lowpan, or it doesn't.
> >
> > RPL should work fine with ordinary ND.  Why would it require
6lowpan?
> >
> >> If it doesn't, then it has to provide for ND to work, or for
another
> >> protocol to replace it.
> >
> > ND works fine, using link-local, one-hop multicasts.  RPL need not
be
> > involved.
> >
> > If someone wants to run RPL on a node that uses neither ordinary ND
or
> > 6lowpan's version, then they will need some third variety of ND.  I
do
> > not see why this is an issue for RPL to address.  It seems quite out 
> > of scope.
> >
> >                               -Richard Kelsey 
> > _______________________________________________
> > Roll mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll
> >
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Wed, 5 May 2010 18:42:14 +0300

Hi,

> In my opinion anything spanning multiple IP hops should not be done by ND.

That logic doesn't work anymore with route-over LoWPANs. As the prefixes are spanning the whole LoWPAN there is a natural need for ND to help with that. In the case of RPL, the WG may decide to disseminate some things such as prefix information between routers in a LoWPAN using the routing protocol. 6lowpan-nd-09 states clearly that you may do that, so nothing stopping RPL there. What is this argument about? You are complaining about something that is not a problem? 

Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an optional mechanism of using RS/RA for disseminating prefix and context information between all routers in a LoWPAN that is routing protocol independent. Regardless of RPL, this will surely come in handy and some routing protocols may even specify to use this mechanism.  

Let me remind you of how RPL started by the way. In the beginning the idea was to piggyback RPL information on ND traffic as there were already similar flows. Eventually the WG decided to give RPL its own messages instead of piggybacking as ND options. Now it has gone to the extreme of RPL being the one and only protocol and everything must be carried on that.... Quite a change! Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and what the heck, let's go for DNS too... Starts to sound like a shopping-TV ad for a super-vegetable-processing-miracle doesn't it? 

> is using a registration mechanism to establish a "route" between the router

It is actually letting the host and router know about each other (router discovery), their reachability (NUD) and their L2 addresses (address resolution). These are all standard features of ND.

> - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is

Better be, or you just broke an important model of IPv6. I would say it MUST be possible for hosts to attach to a LoWPAN running RPL (and stay blissfully ignorant of RPL). 

> hosts use the 6lowpan-ND host-router spec?

ND is clearly the standard host-router interface regardless of IPv6 or 6LoWPAN. Forcing hosts to know anything about RPL would be insane... 

Zach

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

-- 
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 May 2010 17:44:28 +0200

> It is not clear to me whether this is the role of ND

The role of ND here is doing the host-router neighbor discovery.

> or of the routing
> protocol.

The role of RPL here is to disseminate the host route on towards other routers.

> I think it could actually be both.

Hosts should not need to speak routing protocols.

> - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is

I would consider it a major failure if RPL didn't support networks with hosts.
(Networks without hosts, i.e., all-router networks, are certainly possible, but in a constrained node/network we are talking about a relatively high lower bound on the complexity of nodes or a *very* simple routing protocol.
Of course, the routing protocol could distinguish three instead of two complexity classes of nodes, supporting something like a "stub router" [a router that cannot forward].  Still, that class would need to implement some parts of the routing protocol, imposing constraints either way or both.)

> hosts use the 6lowpan-ND host-router spec?

As I said, hosts shouldn't need to speak RPL.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 May 2010 19:24:42 +0200

Hi Mathilde:

All good questions :)

On top of Cartsen and Zach I  may add that  the router needs to know the
address to be redistributed and the instance(s) in which to redistribute
it.
At the moment, we could redistribute into RPL addresses learnt from ND
registrations (great) but we are missing the instanceID.

Cheers,

Pascal

> From: Mathilde Durvy (mdurvy)
> Sent: Wednesday, May 05, 2010 4:19 PM
> To: Pascal Thubert (pthubert); [email-masked]; Richard
Kelsey
> Subject: RE: [Roll] how does a node get an IP address
> 
> Hi Pascal,
> 
> I fully agree with you.
Of

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 May 2010 07:38:51 +0200

Hi Carsten:

Fact is, the latest 6LoWPAN ND draft does not support mesh under since
it lost the white board piece.
It does not support route over either since it is not compatible with
the only route over protocol in existence.

That's very far from what the group voted in Dublin when it elected the
backbone router draft as WG doc.

At the moment, I see 2 possible directions for 6LoWPAN ND:
- Pack it an Indiana Jones RFC and hide it in the midst of 6000 other
boxes where it will be mostly harmless.
- Roll back to where we were before Hiroshima and work closely with RPL
to build a consistent solution for route over.

The ball is in your camp.

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2010 5:44 PM
> To: Mathilde Durvy (mdurvy)
> Cc: Pascal Thubert (pthubert); [email-masked]; Richard
Kelsey;
> [email-masked]; [email-masked]
> Subject: Re: [6lowpan] [Roll] how does a node get an IP address
> 
> > On a related topic....
> > 6lowpan network have the particularity that you cannot use on-link
> > prefix due to the non-transitivity of the wireless links. This means
> > we need to tell routers how to reach neighboring IPv6 hosts. So
> > essentially 6lowpan-ND is using a registration mechanism to
establish
> > a "route" between the router and the host.
> > - Are IPv6 hosts possible in a 6lowpan network where the RPL
protocol
> > is used?
> (Networks without hosts, i.e., all-router networks, are certainly
possible, but
> in a constrained node/network we are talking about a relatively high
lower
> bound on the complexity of nodes or a *very* simple routing protocol.
> Of course, the routing protocol could distinguish three instead of two
> complexity classes of nodes, supporting something like a "stub router"
[a
> router that cannot forward].  Still, that class would need to
implement some
> parts of the routing protocol, imposing constraints either way or
both.)
> 
> > - Should IPv6 hosts be part of a RPL topology (as leaf node) or
should
> > IPv6 hosts use the 6lowpan-ND host-router spec?
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 May 2010 08:21:22 +0200

Hi Zach:

> 
> > Hi Pascal,
> >
> > I fully agree with you.
> > In my opinion anything spanning multiple IP hops should not be done
by
> ND.
> 
> That logic doesn't work anymore with route-over LoWPANs. As the
prefixes
> are spanning the whole LoWPAN there is a natural need for ND to help
with
> that. In the case of RPL, the WG may decide to disseminate some things
such
> as prefix information between routers in a LoWPAN using the routing
> protocol. 6lowpan-nd-09 states clearly that you may do that, so
nothing
> stopping RPL there. What is this argument about? You are complaining
about
> something that is not a problem?
> 
> Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an
> optional mechanism of using RS/RA for disseminating prefix and context
> information between all routers in a LoWPAN that is routing protocol
> independent. Regardless of RPL, this will surely come in handy and
some
> routing protocols may even specify to use this mechanism.

[Pascal] 
Dissemination is the easy piece in the routing protocol. The hard piece
is maintenance.
If you try to maintain the connectivity within the subnet, you end up
building an SGP like RPL.
Do you really want to rediscover what we've been through?

> Let me remind you of how RPL started by the way. In the beginning the
idea
> was to piggyback RPL information on ND traffic as there were already
similar
> flows. Eventually the WG decided to give RPL its own messages instead
of
> piggybacking as ND options. Now it has gone to the extreme of RPL
being the

[Pascal] 
Both the ROLL fundamentals and the backbone router drafts extended ND. 
ROLL Fundamentals inherited from the NINA model that was a recursive
host to router model (NINA meant Network In Node).
The goal was to have a consistent host to router interface all the way
up the DAG. We split the work between 2 stove pipes and that spirit was
lost. 

> one and only protocol and everything must be carried on that.... Quite
a
> change! Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and
what
> the heck, let's go for DNS too... Starts to sound like a shopping-TV
ad for a
> super-vegetable-processing-miracle doesn't it?

[Pascal] This is the direct consequence of keeping 6LoWPAN and RPL
apart. None can refer to / depend on the other.
On the ROLL side: RPL needs all nodes to be routers so it can claim it
does not need ND. Truth is, a RPL node still requires ND for address
allocation.
On the 6LoWPAN side: ND is partial solution with no applicability in the
real world. Truth is, 6LoWPAN ND needs RPL for tying the subnet
together.

establish
> It is actually letting the host and router know about each other
(router
> discovery), their reachability (NUD) and their L2 addresses (address
> resolution). These are all standard features of ND.
> 
protocol
> > is used?
> 
> Better be, or you just broke an important model of IPv6. I would say
it MUST
> be possible for hosts to attach to a LoWPAN running RPL (and stay
blissfully
> ignorant of RPL).

[Pascal]. 
If you look at it, the IP header is the abstraction of a set of
instructions by the end point to the routing fabric.
The flow label is an integral part of that abstraction and RPL makes use
of it to select an instance.
This capability is much needed in a LLN a host connected to a RPL
network should be able to make use of it.
A given deployment can always resort to instance 0 to accept nodes that
are not RPL aware at all..
 
should
> ND is clearly the standard host-router interface regardless of IPv6 or
> 6LoWPAN. Forcing hosts to know anything about RPL would be insane...

[Pascal] Just as incorporating a routing protocol in ND would be.

6LoWPAN managed to work with ISA100. ROLL managed to work with ZigBee
IP.
Can't 6LoWPAN and ROLL manage to work together now?

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 May 2010 08:46:45 +0200

Pascal,

I presume you are talking about 
draft-ietf-6lowpan-nd-09.txt

Can you be a bit more specific?

> it lost the white board piece.

-09 has significantly less functionality than -08 had.
(This may be a bit disappointing to some of us, but it clearly was the result of IETF77.)
I'm not sure how that more focused functionality makes it "not support mesh under".
Did we lose some functionality that is required?
Please explain.

> the only route over protocol in existence.

Again, please explain.

> [...] work closely with RPL

Yes! (That's why I kept ROLL on the CC.)
If there is a technical issue, we need to understand it, so please explain.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 May 2010 09:02:28 +0200

Hi Carsten

> (This may be a bit disappointing to some of us, but it clearly was the
result of
> IETF77.) I'm not sure how that more focused functionality makes it
"not
> support mesh under".
[Pascal] this piece is not related to ROLL. This is about the multicast
issue in mesh under. 6LoWPAN elected the backbone router draft to
address that issue.

> > the only route over protocol in existence.

[Pascal] 6LoWPAN ND needs some addition to enable RPL aware hosts. In
particular around instance IDs. 

> Yes! (That's why I kept ROLL on the CC.) If there is a technical
issue, we need
> to understand it, so please explain.
> 
[Pascal] 
The RPL instance decision is end to end and matches the application
requirements. A device might send traffic over multiple instances and it
has to indicate that in the flow label.

What I'm proposing is to recognize that a LoWPAN and an LLN are quite
the same thing, and if they were not, make it so from now on.

At that point we can accept that ROLL and split the job between RPL and
ND, RPL doing the router to router piece and ND the interface to the
hosts.
 
On the RPL side, that means transporting RIO and PIO from the
authoritative router acting as root down the RPL fabric within DIO
messages. It's a simple replacement to the existing Destination Prefix
option in DIO, no harm done. You'll note that RPL actually USES that
information.

On the ND side, it means opening the messages to RPL parameters, in
particular the mapping between the flow label and the instance
information. RAs should be able to advertise which instance is available
from a given router for instance. We were almost there with ND 07. So
sad. Also sad that you took me off the draft btw, won't help me
internally.

And then, ND can defer to 'an SGP such as RPL' for PIO/RIO dissemination
and RPL routers can be configured to redistribute host information leant
from ND into the SGP.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 May 2010 10:04:14 +0200

On May 6, 2010, at 09:02, Pascal Thubert (pthubert) wrote:

> enable RPL aware hosts

Should we?

(Obviously, if a node really needs to know about RPL, it can always become a router.)

If I understand you correctly, this is about hosts selecting a specific RPL instance-ID for outgoing traffic.
Traditionally, IP has used the TOS byte (Traffic Class in IPv6) to select between different behaviors of the forwarding system.  What is it that the host wants to say by selecting a specific RPL instance ID?  Why can't the router make that selection, e.g. based on the Traffic Class and the destination address?

(Another interesting question is, for incoming traffic, how a host selects which instances it wants to be part of.  Is that even a useful thing to do?  Would that selection be made by the host, by its first-hop router, or by some configuration agent?)

It would be useful to get more information about how instance-IDs are intended to be used with RPL.

On the protocol side:
If there really is something that a host needs to know about RPL-specific information (instances or whatever), this could be delivered in an ND option that could very well be defined in an RPL-related document, no need to define it in 6LoWPAN-ND.  Another way to set up this information would be to configure it during commissioning or using a host configuration protocol like DHCP.

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 6 May 2010 10:49:29 +0200

Let me try one more time:

How much of this will I have to implement to be compliant with other
LLN/RPL nodes?

In a home control/building environment, the notion of a router nodes is
rather artificial.

I may have _host_nodes_. They are host nodes because they are sleeping
(battery operated)
and therefore they cannot participate in routing.
They still have to get an IP address to talk to other IP hosts.

Alternatively, I may have combined _host&router_nodes_ which serve a
purpose application-wise
and at the same time happen to be routing resources.
Do these hosts have to use another way of getting IP addresses just
because they happen to
be able to do routing?

>From a designer's standpoint it does not seem quite elegant that I have
to do use different
methods depending on the power model for my node. Am I missing something
here?

Thanks,
  Anders

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Thursday, May 06, 2010 10:04
> To: Pascal Thubert (pthubert)
> Cc: ROLL WG; [email-masked]; [email-masked]
> Subject: [6lowpan] RPL aware hosts (Re: [Roll] how does a 
> node get an IPaddress)
> 
> If I understand you correctly, this is about hosts selecting 
> a specific RPL instance-ID for outgoing traffic.
> Traditionally, IP has used the TOS byte (Traffic Class in 
> IPv6) to select between different behaviors of the forwarding 
> system.  What is it that the host wants to say by selecting a 
> specific RPL instance ID?  Why can't the router make that 
> selection, e.g. based on the Traffic Class and the 
> destination address?
> 
> (Another interesting question is, for incoming traffic, how a 
> host selects which instances it wants to be part of.  Is that 
> even a useful thing to do?  Would that selection be made by 
> the host, by its first-hop router, or by some configuration agent?)
> 
> It would be useful to get more information about how 
> instance-IDs are intended to be used with RPL.
> 
> On the protocol side:
> If there really is something that a host needs to know about 
> RPL-specific information (instances or whatever), this could 
> be delivered in an ND option that could very well be defined 
> in an RPL-related document, no need to define it in 
> 6LoWPAN-ND.  Another way to set up this information would be 
> to configure it during commissioning or using a host 
> configuration protocol like DHCP.
> 
> Gruesse, Carsten
>

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 06 May 2010 08:16:30 -0400

> Date: Thu, 6 May 2010 09:02:28 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 

Pascal, I disagree with "needs".  The ability to select an
instance ID for a particular message is an optional extra.
RPL works fine without it.  I am okay with limiting instance
ID selection to routers.

                                 -Richard Kelsey

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 May 2010 09:19:37 -0700 (PDT)

I agree with Zach.
IP over foo has been taken up by IETF for all sorts of "foo"s and 6lowpan ND is just doing that.

Regards,

Behcet

----- Original Message ----
> From: Zach Shelby <[email-masked]>
> To: Mathilde Durvy <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Sent: Wed, May 5, 2010 10:42:14 AM

On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote:

> 
> Hi Pascal,
> 
> I fully agree with you.
> In my opinion 
> anything spanning multiple IP hops should not be done by ND.

That logic 
> doesn't work anymore with route-over LoWPANs. As the prefixes are spanning the 
> whole LoWPAN there is a natural need for ND to help with that. In the case of 
> RPL, the WG may decide to disseminate some things such as prefix information 
> between routers in a LoWPAN using the routing protocol. 6lowpan-nd-09 states 
> clearly that you may do that, so nothing stopping RPL there. What is this 
> argument about? You are complaining about something that is not a problem? 
> 

> independent. Regardless of RPL, this will surely come in handy and some routing 
> protocols may even specify to use this mechanism.  

Let me remind 
> you of how RPL started by the way. In the beginning the idea was to piggyback 
> RPL information on ND traffic as there were already similar flows. Eventually 
> the WG decided to give RPL its own messages instead of piggybacking as ND 
> options. Now it has gone to the extreme of RPL being the one and only protocol 
> and everything must be carried on that.... Quite a change! Next we could 
> piggyback DHCPv6 on RPL, use RPL for DAD, and what the heck, let's go for DNS 
> too... Starts to sound like a shopping-TV ad for a 

> On a 
> related topic....

It is actually 
> letting the host and router know about each other (router discovery), their 
> reachability (NUD) and their L2 addresses (address resolution). These are all 
> standard features of ND.

> - Are IPv6 hosts possible in a 
> 6lowpan network where the RPL protocol is
> used?

Better be, or you 
> just broke an important model of IPv6. I would say it MUST be possible for hosts 
> to attach to a LoWPAN running RPL (and stay blissfully ignorant of RPL). 
> 

> should IPv6

ND is 
> clearly the standard host-router interface regardless of IPv6 or 6LoWPAN. 
> Forcing hosts to know anything about RPL would be insane... 
> 

Zach

> From: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked] [mailto:> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]] On Behalf 
> Of
> To: > href="mailto:[email-masked]">[email-masked]; Richard 
> Kelsey
> Cc: > href="mailto:[email-masked]">[email-masked]; > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
> Subject: Re: [Roll] 
> I 
> have yet to review the new ND-09 but my guts tell me that it is the 
> wrong
> The 
> main question is how long can  a router advertise a prefix, and the
> 
> Asserting the continuous 
> reachability of the authoritative router is a
> routing protocol problem. 
> Maintaining a subnet together is the job for a new
> form of Gateway 
> Protocol, a Subnet Gateway Protocol RPL is just that.
> 
> Let 
> see:
> 
> So why 
> can't we just say in 6LoWPAN ND that you for those who use it in
> route 
> over we expect an SGP to tie the route over subnetwork together and
> that 
> the SGP should transport the RA content, maintaining the validity with
> 
>> From: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked] [mailto:> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]] On Behalf
> 
> Of
>> > href="mailto:[email-masked]">[email-masked]
>> 
>> To: Richard 
>> Cc: > href="mailto:[email-masked]">[email-masked]
>> Subject: Re: [Roll] 
>> Hi 
> Everyone,
>> recommend everyone goes 
> and reads 6lowpan-nd-09 which was submitted 
>> today. When it comes to 
>> ND* does the 
> job, and RS/RA is used for obtaining a prefix and
> initializing 
> its
>> an optional technique for 
> an authorative border router to disseminate
> PIOs
>> and CIOs 
> (Context Information Options) between the border router and
> 
> all
>> routing algorithm may 
> already do this. So Pascal is correct in that
> respect. I
>> 
>> during initial 
> bootstrapping, to maintain their default router and
> neighbor
>> 
>>>> From: Michael Richardson 
> <> href="mailto:[email-masked]">[email-masked]>
>>>> 
>>>>>>>>> "Richard" == Richard Kelsey <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]>
> 
> writes:
>>>>>> (pthubert)" <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]>
>>>>>> 
> 
>>> Why 
> should RPL be any different?  Yes, it will be run on multi-hop 
> 
>>>> Richard> I 
> understand that multi-hop subnets are a problem for ND, 
>>>> 
>>> Roll mailing 
> list
>>> > href="mailto:[email-masked]">[email-masked]
>>> > href="https://www.ietf.org/mailman/listinfo/roll" target=_blank 
>> Roll mailing 
> list
>> > href="mailto:[email-masked]">[email-masked]
>> > href="https://www.ietf.org/mailman/listinfo/roll" target=_blank 
> Roll mailing 
> list
> > href="mailto:[email-masked]">[email-masked]
> > href="https://www.ietf.org/mailman/listinfo/roll" target=_blank 
> 6lowpan mailing 
> list
> > href="mailto:[email-masked]">[email-masked]
> > href="https://www.ietf.org/mailman/listinfo/6lowpan" target=_blank 

-- 
Zach Shelby, 
> Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On 
> the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless 
> Embedded Internet"
Mobile: +358 40 
> 7796297

6lowpan 
> mailing list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/6lowpan" target=_blank

---

From: Robert Cragie <[email-masked]>
Date: Thu, 06 May 2010 18:38:09 +0100

Hi Zach,

I agree with some of what you say but not all of it. See inline 
comments. In a nutshell:

    * We need ND for bootstrapping hosts and routers and to maintain
      hosts. I think nd-09 supports this well
    * Hosts do not need to know anything about routing protocol used in
      the wider network
    * There is nothing wrong with using RPL's (or any other routing
      protocol) implicit multicast mechanism for disseminating lowpan
      wide information

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 05/05/2010 4:42 PM, Zach Shelby wrote:
> That logic doesn't work anymore with route-over LoWPANs. As the prefixes are spanning the whole LoWPAN there is a natural need for ND to help with that.
<RCC>(1) I repeat - classic ND has no concept over this, so there isn't 
a natural need for ND to help with this. There has been a choice to add 
in a mechanism but that mechanism is a 'multicast' mechanism which 
implicitly has to define propagation. Propagation is not the domain of 
ND but is the domain of the associated routing protocol</RCC>
>   In the case of RPL, the WG may decide to disseminate some things such as prefix information between routers in a LoWPAN using the routing protocol. 6lowpan-nd-09 states clearly that you may do that, so nothing stopping RPL there. What is this argument about? You are complaining about something that is not a problem?
>    
<RCC>The way it is worded in nd-09 is fine with me, so I have no 
argument :-)</RCC>
> Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an optional mechanism of using RS/RA for disseminating prefix and context information between all routers in a LoWPAN that is rout…
<RCC>See comment (1) above</RCC>
> Let me remind you of how RPL started by the way. In the beginning the idea was to piggyback RPL information on ND traffic as there were already similar flows. Eventually the WG decided to give RPL its own messages instead of piggybacking as ND options.
<RCC>Piggybacking RPL options on ND was never going to work as it is 
back-to-front, same as comment (1) above.<RCC>
> Now it has gone to the extreme of RPL being the one and only protocol and everything must be carried on that.... Quite a change! Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and what the heck, let's go for DNS too... Starts to sound like a shopping-TV ad for a super-vegetable-processing-miracle doesn't it?
>    
<RCC>What is 'it' ("Now it has gone..."). RPL provides a natural 
propagation mechanism to all routers so please tell me what is wrong 
with utilising that to disseminate network-wide information?</RCC>

> It is actually letting the host and router know about each other (router discovery), their reachability (NUD) and their L2 addresses (address resolution). These are all standard features of ND.
<RCC>I agree here - we need ND for host - router interaction and indeed 
for bootstrapping a router onto the lowpan</RCC>
> Better be, or you just broke an important model of IPv6. I would say it MUST be possible for hosts to attach to a LoWPAN running RPL (and stay blissfully ignorant of RPL).
<RCC>I agree too</RCC>
> ND is clearly the standard host-router interface regardless of IPv6 or 6LoWPAN. Forcing hosts to know anything about RPL would be insane...
<RCC>I agree. Hosts should not need to know anything about which routing 
protocol is in use in the wider lowpan</RCC>
>>>>> From: Michael Richardson<[email-masked]>
>>>>>>>>>> "Richard" == Richard Kelsey<[email-masked]>
>>>>>>>>>>                      
>> writes:
>>      
>>>>>>> (pthubert)"<[email-masked]>
>>>>>>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 06 May 2010 18:48:22 +0100

+1

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 06/05/2010 1:16 PM, Richard Kelsey wrote:
>> From: "Pascal Thubert (pthubert)"<[email-masked]>
>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 06 May 2010 18:47:46 +0100

Hi Anders,

Totally agree. From a bootstrapping point of view, in my mind there is 
no distinction between host and router. You could argue that if a 
network is formed dynamically, natural RA propagation in the forming 
tree structure might be enough if the first node is the ABR. However, I 
think there also needs to be a mechanism to propagate options throughout 
the network generally. For this piece, and I stress this piece *only*, I 
believe that ND is probably not the right place to specify this.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 May 2010 19:55:12 +0200

> RPL works fine without it.  I am okay with limiting instance

Richard,

this is very useful input.  Thank you.
(And thank you for the +1, Robert.)

Now the next step is to find out whether there is consensus on this point.
Those of you who have an idea what you want to use multiple RPL instances for:
Would you be happy with limiting support for instance selection to routers?

Gruesse, Carsten

---

From: Kris Pister <[email-masked]>
Date: Thu, 06 May 2010 14:27:01 -0700

Anders - there are many commercial networks (even in buildings and 
homes) where battery operated nodes are routers.  I don't think that we 
should confuse the line/battery power issue with the host/router issue.
There are many reasons why a node might choose or be designated to be a 
host not a router, so your question still stands.  But it's not a power 
issue.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 May 2010 08:08:10 +0200

Hi Robert and Richard:

We designed instances to enable to support multiple sorts of traffic
with different requirements.

The instance is the network response to the application needs. The
application resides in the host, even if routers sometimes play both
roles.

The application needs to signal the instance one way or another in its
packets, and we use flow labels for that. So far so good. 

What's missing:

-          The host also needs to join the RPL networks that support the
instances that it needs. That must be signaled in the router to host
interface.

-          The host also needs to be advertised in the RPL networks that
support the instances that it needs. That must be signaled in the host
to router interface.

>From there I think you've got the logic reverse:

You're correct that ROLL supports a host with no RPL extension using
instance 0 / flow label 0.

But still the host to router interface needs to be augmented for an
application residing on the host to benefit from ROLL instances. 

What I'm reading below is "a host MUST be a router in order to comply
with the ROLL MUST of supporting multiple types of traffic".

Well, -1.

Pascal

From: Robert Cragie [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 7:48 PM
To: Richard Kelsey
Cc: Pascal Thubert (pthubert); [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Roll] [6lowpan] how does a node get an IP address

+1

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

	Date: Thu, 6 May 2010 09:02:28 +0200
	From: "Pascal Thubert (pthubert)" <[email-masked]>
<mailto:[email-masked]> 
	 
	[Pascal] 6LoWPAN ND needs some addition to enable RPL aware
hosts. In
	particular around instance IDs. 

 
                                 -Richard Kelsey

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 7 May 2010 09:02:30 +0200

Kris,
 
> But it's not a power issue
 
Agreed. This was meant to be an example only ;-)
 
- Anders

________________________________

	From: Kris Pister [mailto:[email-masked]] 
	Sent: Thursday, May 06, 2010 23:27
	To: Anders Brandt
	Cc: ROLL WG; [email-masked]
	Subject: Re: [Roll] [6lowpan] how does a node get an IPaddress

	Anders - there are many commercial networks (even in buildings
and homes) where battery operated nodes are routers.  I don't think that
we should confuse the line/battery power issue with the host/router
issue.
	There are many reasons why a node might choose or be designated
to be a host not a router, so your question still stands.  But it's not
a power issue.
	
	ksjp
	
	Anders Brandt wrote: 

		How much of this will I have to implement to be
compliant with other
		LLN/RPL nodes?
		
		In a home control/building environment, the notion of a
router nodes is
		rather artificial.
		
		I may have _host_nodes_. They are host nodes because
they are sleeping
		(battery operated)
		and therefore they cannot participate in routing.
		They still have to get an IP address to talk to other IP
hosts.
		
		Alternatively, I may have combined _host&router_nodes_
which serve a
		purpose application-wise
		and at the same time happen to be routing resources.
		Do these hosts have to use another way of getting IP
addresses just
		because they happen to
		be able to do routing?
		
		From a designer's standpoint it does not seem quite
elegant that I have
		to do use different
		methods depending on the power model for my node. Am I
missing something
		here?
		
		Thanks,
		  Anders

			-----Original Message-----
			From: [email-masked] 
			[mailto:[email-masked]] On Behalf Of
Carsten Bormann
			Sent: Thursday, May 06, 2010 10:04
			To: Pascal Thubert (pthubert)
			Cc: ROLL WG; [email-masked];
[email-masked]
			Subject: [6lowpan] RPL aware hosts (Re: [Roll]
how does a 
			node get an IPaddress)
			
			On May 6, 2010, at 09:02, Pascal Thubert
(pthubert) wrote:

				enable RPL aware hosts

			Should we?
			
			(Obviously, if a node really needs to know about
RPL, it can 
			always become a router.)
			
			If I understand you correctly, this is about
hosts selecting 
			a specific RPL instance-ID for outgoing traffic.
			Traditionally, IP has used the TOS byte (Traffic
Class in 
			IPv6) to select between different behaviors of
the forwarding 
			system.  What is it that the host wants to say
by selecting a 
			specific RPL instance ID?  Why can't the router
make that 
			selection, e.g. based on the Traffic Class and
the 
			destination address?
			
			(Another interesting question is, for incoming
traffic, how a 
			host selects which instances it wants to be part
of.  Is that 
			even a useful thing to do?  Would that selection
be made by 
			the host, by its first-hop router, or by some
configuration agent?)
			
			It would be useful to get more information about
how 
			instance-IDs are intended to be used with RPL.
			
			On the protocol side:
			If there really is something that a host needs
to know about 
			RPL-specific information (instances or
whatever), this could 
			be delivered in an ND option that could very
well be defined 
			in an RPL-related document, no need to define it
in 
			6LoWPAN-ND.  Another way to set up this
information would be 
			to configure it during commissioning or using a
host 
			configuration protocol like DHCP.
			
			Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 May 2010 16:33:41 +0200

Hi Robert:

Your +1 could be misinterpreted then... I think Carsten did.

The flow label helps the router select the instance for a packet. It
does not help a host that needs to select a router that serves that
instance. A plain host (that does not support RPL) will need to find
that in RAs. In a same fashion, it will need to place what it's looking
for in RS (like we'll do in DIS). And the new ND registration will have
to indicate into which instances the registration must be injected as a
DAO.

Do you agree so far?

The DODAG ID is not  the appropriate information for the host, unless it
is concerned with DAG multihoming and such, which I would not expect.

The router can and will switch DODAG within the instance and the host
will not care, since its applications will be served either way. 

When the router leaves the instance entirely, then the node will care,
and it needs to know. At worst, we can achieve that with a new
unreachable code.

Finally, a root might use the same DODAG ID in multiple instances. So
the router could be confused if the host only indicated a DODAG ID...

Still in agreement?

On the side, we discussed for P2P  about making local instances that
actually depend on the DODAG ID so that the fully qualified instance ID
would really be the tupple (DODAG ID, instanceID). That's still in limbo
though I do think we need it. 

What's your take on this?

Pascal

From: Robert Cragie [mailto:[email-masked]] 
Sent: Friday, May 07, 2010 1:41 PM
To: Pascal Thubert (pthubert)
Cc: Richard Kelsey; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Roll] [6lowpan] how does a node get an IP address

Hi Pascal,

I understand what you're saying and agree that in the case of multiple
RPL instances, whereby each RPL instance is characterized by potentially
different metrics (that's the point of them, right?), you would need
some sort of qualification at the packet originator as to which RPL
instance it ends up choosing for its route to its destination. This is
done using the flow label.

On the other hand, a DODAG is, as its name implies, a destination
oriented DAG. Therefore the DODAG ID is the general discriminator within
a RPL instance for which route a packet takes based on its destination.
There is no need for any other additional information, surely? So that's
what the +1 was for.

The spec. seems a little confused on this anyway. In section 7.2 it says
the RPLInstanceID field is an "8-bit field indicating the DODAG instance
along which the packet is sent". But the DODAG instance is an instance
within a RPL instance. Can you clarify this? In general, I find the
instances confusing, as they are often considered as a tuple (RPLID,
DODAGID, DODAGSeqNum). However, transitioning from (1,1,1) to (1,1,2) is
not the same as transitioning from (1,1,1) to (1,2,1) and this is not
clear in the specification.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 07/05/2010 7:08 AM, Pascal Thubert (pthubert) wrote: 

Hi Robert and Richard:

What's missing:

The host also needs to join the RPL networks that support the instances
that it needs. That must be signaled in the router to host interface.

The host also needs to be advertised in the RPL networks that support
the instances that it needs. That must be signaled in the host to router
interface.

	But still the host to router interface needs to be augmented for
an application residing on the host to benefit from ROLL instances. 

	What I'm reading below is "a host MUST be a router in order to
comply with the ROLL MUST of supporting multiple types of traffic".

	Well, -1.

	Pascal

	Cc: Pascal Thubert (pthubert); [email-masked];

	+1

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

		 
		[Pascal] 6LoWPAN ND needs some addition to enable RPL
aware hosts. In
		particular around instance IDs. 

	 
	                                 -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 07 May 2010 10:52:11 -0400

> Date: Fri, 7 May 2010 16:33:41 +0200
> The flow label helps the router select the instance for a packet.

"Helps"?  Doesn't the flow label tell the router exactly
which instance to use?

> It does not help a host that needs to select a router that serves that
> instance.

The trouble I have with this is that "select a router"
sounds a lot like routing.  We already have a mechanism
for selecting which router to send a packet to: DIOs.
If a device wants to select between next hops based on
routing metrics then it should be a router.

Why is this such a burden?  Listening to DIOs and making
routing decisions based on them does not require sending
DIOs or forwarding packets for others.

                              -Richard Kelsey

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 7 May 2010 17:26:58 +0200

Hi Richard, 

> The flow label helps the router select the instance for a packet.

"Helps"?  Doesn't the flow label tell the router exactly which instance to
use?

The trouble I have with this is that "select a router"
sounds a lot like routing.  We already have a mechanism for selecting which
router to send a packet to: DIOs.
If a device wants to select between next hops based on routing metrics then
it should be a router.

Why is this such a burden?  Listening to DIOs and making routing decisions
based on them does not require sending DIOs or forwarding packets for
others.

[Mathilde] What you are describing looks like a RPL leaf node but does not
really need the IPv6 router functionalities i.e. forwarding, sending RA,
etc. This is exactly what I was trying to point out when I was asking if a
RPL leaf node could be an IPv6 host...

Best,
Mathilde

---

From: Robert Cragie <[email-masked]>
Date: Sat, 08 May 2010 13:49:15 +0100

Hi Pascal,

I'm sending this just to ROLL as the ND part is waning. Comments inline, 
bracketed by <RCC></RCC>.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 07/05/2010 3:33 PM, Pascal Thubert (pthubert) wrote:
> that in RAs. In a same fashion, it will need to place what it's 
> looking for in RS (like we'll do in DIS). And the new ND registration 
> will have to indicate into which instances the registration must be 
> injected as a DAO.
>
> Do you agree so far?
>
<RCC>Yes</RCC>
>
> The DODAG ID is not  the appropriate information for the host, unless 
> it is concerned with DAG multihoming and such, which I would not expect.
>
<RCC>If you mean switch selection of DODAG based on destination at the 
point of packet ingress, and keep the same notion of ID (presumably 
carrying it in the flow label?) whilst it propagates, yes. But I don't 
see how it can switch from router to router or else we could end up with 
the looping problem.</RCC>
> the router could be confused if the host only indicated a DODAG ID...
<RCC>Yes - I see the combination of RPL instance ID to select the 'QoS' 
(for want of a better expression) for the packet and the DODAG ID to 
select which DODAG pertinent to the destination.</RCC>
> actually depend on the DODAG ID so that the fully qualified instance 
> ID would really be the tupple (DODAG ID, instanceID). That's still in 
> limbo though I do think we need it.
>
<RCC>I am not sure if we need to distinguish another instance within a 
DODAG for these 'skinny' P2P DAGs which were are discussing, simply 
because, as far as I can see, the DODAG ID pertains to its destination. 
Therefore providing we allocate a DODAG ID to the 'skinny' P2P DAGs then 
I believe it will work in the same way. But I guess this needs further 
discussion.</RCC>
>
> Pascal
>
> *From:* Robert Cragie [mailto:[email-masked]]
> *Sent:* Friday, May 07, 2010 1:41 PM
> *To:* Pascal Thubert (pthubert)
> *Cc:* Richard Kelsey; [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* Re: [Roll] [6lowpan] how does a node get an IP address
>
> Hi Pascal,
>
> RPL instances, whereby each RPL instance is characterized by 
> potentially different metrics (that's the point of them, right?), you 
> would need some sort of qualification at the packet originator as to 
> which RPL instance it ends up choosing for its route to its 
> destination. This is done using the flow label.
>
> oriented DAG. Therefore the DODAG ID is the general discriminator 
> within a RPL instance for which route a packet takes based on its 
> destination. There is no need for any other additional information, 
> surely? So that's what the +1 was for.
>
> The spec. seems a little confused on this anyway. In section 7.2 it 
> says the RPLInstanceID field is an "8-bit field indicating the DODAG 
> instance along which the packet is sent". But the DODAG instance is an 
> instance within a RPL instance. Can you clarify this? In general, I 
> find the instances confusing, as they are often considered as a tuple 
> (RPLID, DODAGID, DODAGSeqNum). However, transitioning from (1,1,1) to 
> (1,1,2) is not the same as transitioning from (1,1,1) to (1,2,1) and 
> this is not clear in the specification.
>
> Robert
>
> The host also needs to join the RPL networks that support the 
> the instances that it needs. That must be signaled in the host to 
> router interface.
>
>     *From:* Robert Cragie [mailto:[email-masked]]
>     *Sent:* Thursday, May 06, 2010 7:48 PM
>     *To:* Richard Kelsey
>     *Cc:* Pascal Thubert (pthubert); [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Roll] [6lowpan] how does a node get an IP address
>
>     +1
>
>         From: "Pascal Thubert (pthubert)"<[email-masked]>  <mailto:[email-masked]>
>
>           
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 May 2010 18:27:23 +0200

Hi Robert:

The purpose of the local instance ID is to enable a node to form an
instance ID that does not have to be unique in the subnet. A node A that
needs to form a DODAG to talk to node B under specific constraints would
pick one of its addresses as DADOGID, and autoconf an instanceID without
the need to agree with anyone.

This comes with the assumption that globally unique instance IDs will be
scarce resource and might involve some work to get assigned, whereas an
instance ID that is only locally unique (for a DODAGID) is a lot easier
to get. If some P2P flows require quick set up, this might come handy...

Cheers,

Pascal

From: Robert Cragie [mailto:[email-masked]] 
Sent: Saturday, May 08, 2010 2:49 PM
To: Pascal Thubert (pthubert)
Cc: Richard Kelsey; [email-masked]; [email-masked]
Subject: Re: [Roll] [6lowpan] how does a node get an IP address

Hi Pascal, 

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert:

Do you agree so far?

<RCC>Yes</RCC>

Still in agreement?

 

 

Pascal

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert and Richard:

What's missing:

	Well, -1.

	Pascal

	+1

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

		 

	 
	                                 -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 May 2010 18:41:12 +0200

Hi Richard

> "Helps"?  Doesn't the flow label tell the router exactly which
instance to use?

At the moment you're correct, it's one to one. I've heard voices (was
that Kris and Phil?) asking for a more complex stateful mapping at the
RPL network ingress, and a new field in the new RPL option for the
instance. My vote is to leave the instance ID in the flow label where it
is today, since it is end to end application data.  While I agree that
the loop avoidance data  fits very well in a hop by hop option long as
the option stays contained in the RPL network. Which is what Jonathan's
draft does for all I understand so I'm fully happy there.

> based on them does not require sending DIOs or forwarding packets for

In the host world, there is such a thing as a default router list. The
host builds that list listening to RAs, and applies its best practice to
select the router it will use for a given packet out. A number of
considerations will influence that decision, like the age information,
Mobile IP information, multihoming information, etc...

RFC 4191 is an obvious such consideration that provides guidance to
proactively setup a table that redirects would have setup reactively
anyway. You'll note that RFC 4191 is very voluntarily NOT a routing
protocol thing, and really a router to host to interface. The key here
is that the preference IS NOT a distance. Other hints come from the
mechanics used (RA most usually is router to host though it's been
extended to R2R sometimes like in MIPv6).

In a same fashion as routing information can be transformed into a RFC
4191 RIO, instance information should be made available to the host.

Pascal

> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 4:52 PM
> Cc: [email-masked]; [email-masked];
> References:
> <[email-masked]><4BD58ED9.8070401@gridmerg
> e.com><[email-masked]
> .local><[email-masked]><0a9b01cae5a3$79d6a320$6d83
> e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-
> AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-
> ws.hq.ember.com><[email-masked]><87bpd42
> 9wp.fsf@kelsey-
> ws.hq.ember.com><[email-masked]
> .fi>	<6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-
> 107.cisco.com>	<8A977BDC5A7B0E429B0F521E8D6F91EE01F6D1F9@XMB-
> AMS-103.cisco.com>	<[email-masked]>
> 	<6A2A459175DABE4BB11DE2026AA50A5D01CD91C0@XMB-AMS-
> 107.cisco.com>	<[email-masked]>
> 	<6A2A459175DABE4BB11DE2026AA50A5D01CD91F1@XMB-AMS-
> 107.cisco.com> <[email-masked]>
> <[email-masked]>
> <6A2A459175DABE4BB11DE2026AA50A5D01D605A8@XMB-AMS-
> 107.cisco.com> <[email-masked]>
> <6A2A459175DABE4BB11DE2026AA50A5D01D608E0@XMB-AMS-
> 107.cisco.com>
> X-OriginalArrivalTime: 07 May 2010 15:01:59.0538 (UTC)
> FILETIME=[3E3CA520:01CAEDF6]
> Return-Path: [email-masked]
> 
> "Helps"?  Doesn't the flow label tell the router exactly which
instance to use?

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 10 May 2010 10:42:02 +0200

Erik,

> But fundamentally I don't understand why a working group like 
> ROLL that seems keen on building small and simple networking 
> devices at the same time feel a requirement to add bells and 
> whistles like this. Seems to be counter to designing a simple 
> and robust network infrastructure.

+1

- Anders

> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Monday, May 10, 2010 10:30
> On 05/10/10 01:24 AM, Pascal Thubert (pthubert) wrote:
> > Hi Erik:
> >
> > OSPFv3 has similar instances.
> 
> How does a host know which "instance" to use in the case of OSPFv3?
> Why doesn't ROLL use the same mechanism?
> 
> > Traffic Engineering is all about mapping flows of traffic 
> onto complex 
> > topologies that are designed for those flows.
> >
> > So nothing real new. RPL just makes that a bit less manual, 
> because we 
> > have harder constraints in terms of scalability and so-called 
> > autonomicity.
> >
> > RPL dynamically builds its TE topologies and specifies the 
> flow label 
> > interaction a bit deeper to automate the mapping of the flows onto 
> > those topologies.
> >
> > I see that as extension or evolution, but not revolution. A 
> survival 
> > trait for the Internet Architecture, really.
> 
> If there is a need to evolve the Internet Architecture, it is 
> best not done in a narrowly focused IETF working group.
> 
> I suggest that be discussed in the INT-AREA WG to begin with.
> 
> But fundamentally I don't understand why a working group like 
> ROLL that seems keen on building small and simple networking 
> devices at the same time feel a requirement to add bells and 
> whistles like this. Seems to be counter to designing a simple 
> and robust network infrastructure.
> 
>     Erik

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 10 May 2010 10:51:55 +0200

> Where can I find the architectural definition of "an RPL instance"?
> 
> Is it in essence akin to a VLAN on an Ethernet?

It sounds like the same to me. With the difference that VLAN was created
to
simulate individual media over one wired infrastructure.
With individual DODAGIDs this is already possible in RPL (?)

If the rest of the Internet can live without this complex mechanism, why
do
we want to put that burden on much smaller nodes?
My take is we should leave all this flow label stuff for the future if
it
appears that there really is a need for it.
Internally RPL already has the OCP to do the same.

just my $0.05

> Sent: Monday, May 10, 2010 09:01
> To: [email-masked]
> On 05/ 6/10 12:02 AM, Pascal Thubert (pthubert) wrote:
> 
> > requirements. A device might send traffic over multiple 
> instances and 
> > it has to indicate that in the flow label.
> 
> Where can I find the architectural definition of "an RPL instance"?
> 
> Is it in essence akin to a VLAN on an Ethernet?
> 
> This sounds like a significant departure from the existing 
> Internet architecture.
> 
>     Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 May 2010 11:06:53 +0200

Hi Erik

Please see below:

> I think you are mistaken.
> Mesh under works with just RFC 2461, since it is the layer 2 mesh that
has to
> solve all the hard problems, essentially making things look like an
Ethernet to
> IP.

[Pascal] Assumptions, assumptions.

I think you're confusing the 802.11 infrastructure mode and the larger
world of mesh under.
You'll note that 11S does not go far trying to extend the concept to a
real mesh. 
What about other well-known mesh under topologies like Frame Relay?

> 
> You might be confusing mesh-under with the notion of having a wired
> backbone be part of the lowpan without participating in the lowpan
routing
> protocols. While I think the best way to handle such physical
topologies is to
> make the wired backbone be part of the lowpan routing protocol domain,
> 6lowpan-nd carries sufficient information in the case of mesh-under
for the
> 6LBR to track all the IPv6 addresses that are registered.

[Pascal] The big question is whether the routing domain is an IGP or an
SGP.

If it is an IGP, then you've split the mesh into multiple mesh an eluded
the question. On the way, you've lost the capability to move seamlessly
and that is not acceptable.
So it must be an SGP. But then it's a route-over solution, even if
you're routing only in the backbone. If you do that, why not do it
throughout? 

> Which RFC contains that 'only protocol'? ;-)

[Pascal] Please, I really wish to make progress. I do.
 
> I'm pretty sure I can build a route over solution using RIPv2 or OSPF
which are
> existing IETF RFCs. It might be far from optimal, but it does indicate
that the
> separation between the host-to-router interaction and the
router-to-router
> is in the right place.

[Pascal] I'm pretty sure that we can extend those to make decent SGPs
for networks where they are fit. They will not be fit inside the
LoWPANs, though. Just figure deploying OSPF/P2MP. You'd having to set up
a dominating set of routers, and then suffer the bows and arrows of
outrageous multicasts. We made that study and decided to work on RPL.

What they are missing is the notion of "keeping things together" which
relates to the concept of root or authoritative router. Once you have
this concept, it's only fair to propagate PIO and RIO as we propose to
do in RPL.

I do not think I am mistaken. I am certainly unclear. Let's see:

The backbone router that was elected in Dublin as WG doc for 6LoWPAN ND
was mostly concerned with mesh under. The idea behind was that any
route-over (== routing within the subnet)  specific problem that would
come on top would have to be managed as part of the router-over
solution, which we (try to) do in RPL by the way. 

The expectation of the 6LoWPAN WG when we elected the backbone router
draft over Samita's draft was to radically eliminate multicast. The
backbone router draft takes a number of measures to get there. The most
obvious is the use of NS/NA as a registration mechanism, and I'm very
happy that this core idea is still present in the current draft, though
the original author somewhat disappeared by some black magic that's
quite unusual to the IETF.

I claim that the current proposed solution still does not work on mesh
under because it does not fulfill that expectation. For instance, I do
not see how multicast is avoided in mesh under when there are more than
one router in the subnet, without involving routing protocols, which
would be route-over. From the backbone router draft till ND-07, we
answered that question at the ND level using a whiteboard registrar as a
backend to the registration. Please do not confuse that question with
the use of a backbone where admittedly, either an SGP or ND proxy could
work.
 
I'll add that it is pretty hard to complete the registration mechanism
before we know what the registration bask end is. You demonstrated that
ND-08 could not be used to front end DHCP. I demonstrated that it cannot
be used to front end RPL either. And it's broken for mesh under because
it is incomplete. I cannot see how the whole picture works from either
this draft alone, or any combination of drafts on the works today. 

For all I know ND 09 is broken while ND 07 was not. My suggestion to
resolve the issues I see:

- put the whiteboard interaction back in the base spec so the spec is
standing on its own 2 feet.
- let the route over problem propagation to RPL (that's the PIO/RIO
propagation)
- make a separate spec for the ND proxy piece. We have already text from
Zach, Carsten and I that can be used

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 May 2010 11:19:14 +0200

Hi Erik

> I think the terminology and use is more confused than that.

[Pascal] terminology is a actually a incredibly hard problem because all
words are so overloaded already, and differently for different persons
> 
> The descriptions I've seen of the use of ROLL instances talk of
differentiating
> things for the low delay vs. high throughput packets.
> This used to be called "ToS routing" back when OSPF supported it (I
think it
> was removed because nobody used it.) One could envision something
similar
> for ROLL using the Traffic Class field in the data packets, and
building a
> separate tree for each traffic class.
> 
> But Pascal referred to OSPFv3 instances, which is merely a local
identifier on
> one link to enable multiple OSPF ships in the night sharing e.g., one
Ethernet.
> Thus that instance ID does not span multiple router hops. That has
similar
> effect to having the OSPF control plane run on separate VLANs on that
> Ethernet.

[Pascal] RPL instances are exactly that: ship in the night instances
operating on the same subnet, and that's why we pick the term.
Obviously we extended the concept to a multilink subnet, but that's the
topology we have to live with. And that's the closest abstraction we had
that we could extend to the route over world. 
You'll note that RPL instances, like OSPFv3 instances, are often but not
necessarily used to map traffic classes. They are used to map flows
which can have an arbitrary application meaning.
One of the results of having an instance is that the edge router can
have policies as to where a given instance is redistributed. For
instance, VPN(s) serving metering companies.

> I have no problem keeping the first RFC of a protocol as simple as
possible. If
> the protocol gets widely deployed one can consider extending it later.

[Pascal] RPL describes the operation within one instance. For that
reason, the concept does not make the spec any more complex.
As opposed to ND-09, the spec stands on its own 2 feet with instance 0.
The instance management for other instances is left out.

Cheers,

Pascal

---

From: Zach Shelby <[email-masked]>
Date: Mon, 10 May 2010 12:55:01 +0300

Pascal,

I think you're being a bit paranoid here. Let me try to correct some misunderstandings. 

Again, I think you are fighting yourself here with regard to prefix dissemination. We have already agreed that nothing in nd-09 prevents RPL from disseminating the PIOs. In fact, it specifically says that if the routing protocol does that already, then great. Other routing protocol might need the prefix dissemination option in nd-09, thus the spec "stands on its own feet". So as far as the 6lowpan WG is concerned there is nothing to discuss. It is up to the ROLL working group to discuss if and how it wants to disseminate prefix information to RPL routers. 

Regarding InstanceIDs and other RPL specific host issues, there is nothing in nd-09 preventing that either. Nor can a 6lowpan document specify something for a host to do which is RPL related. If RPL wants to specify some ND option to be carried in RAs with regard to flow labels - then go for it. But don't complain about ND here... 

Regarding the extended LoWPAN functionality you are referring to below. The WG consensus after Hiroshima was to split the ND draft into a base draft (which was done in nd-08 already!) and a separate Extended LoWPAN draft. As I have told you, you need to find the time to write that extended LoWPAN draft (let's do it) and explain how to achieve these kinds of topologies. I'm happy to help, but my hands are full right now.

The WG consensus in Anaheim was to make a clean re-write of the WG document integrating the NS/NA mechanism from nd-simple and the base mechanism of address registration from nd-08. This is what we did. I believe the result of this is a very good draft which specifies the host-router interface and definitely stands on its own feet as it is mesh-under, route-over and routing protocol independent as it should be.

On May 10, 2010, at 12:06 , Pascal Thubert (pthubert) wrote:
> 
> For all I know ND 09 is broken while ND 07 was not.

The WG consensus was the opposite, sorry. 

> My suggestion to

nd-09 does have the ability to do DAD to the edge of the LoWPAN... 

> - let the route over problem propagation to RPL (that's the PIO/RIO

It DOES!!!! Remember RPL is not *the* only routing protocol. I can implement DYMO on a LoWPAN and it will need the prefix dissemination method from nd-09. 

> Zach, Carsten and I that can be used

Pascal, you know very well that is your AP. This was also already decided by the working group already after Hiroshima.

Argh,
Zach

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2010 12:17:42 +0200

On May 10, 2010, at 11:55, Zach Shelby wrote:

> We have already agreed that nothing in nd-09 prevents RPL from disseminating the PIOs. In fact, it specifically says that if the routing protocol does that already, then great. Other routing protocol might need the prefix dissemination option in nd-09, thus the spec "stands on its own feet". So as far as the 6lowpan WG is concerned there is nothing to discuss. It is up to the ROLL working group to discuss if and how it wants to disseminate prefix information to RPL routers. 

+1.

However, please note also that a LoWPAN needs more information disseminated than the PIOs.
Unless RPL is extended to carry compression context as well, it seems more logical to do all this network configuration dissemination in 6LoWPAN-ND.
(No, you don't *need* compression context in a LoWPAN, but it gets significantly less efficient without it.
And it breaks spectacularly if the compression context gets inconsistent between nodes.)

Both compression context and prefix information is likely to change on relatively slow timescales (days/weeks), which is another reason why it seems appropriate to use a configuration protocol for the dissemination of both, rather than a routing protocol operating in terms of seconds/minutes.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 May 2010 12:38:59 +0200

Zach,

You're not addressing my question. My question is how do you do mesh
under with 2 routers and the answer cannot be route over. So?
If the draft does not answer that question and cannot point on a draft
that does, then, no, it does not stand on its feet, sorry.

The vote that lead to 08 was based on the assumption that we could make
a front end that could be common to multiple backend techniques, DHCP,
whiteboard, etc...
This assumption was wrong. Erik demonstrated that it already failed with
DHCP before we even tried to make it work for whiteboard. So it's
simply moot. I think the draft needs the complete picture and that
includes the registrar. 

The desire to separate the ND proxy piece is different because there are
alternate ways like an SGP over the backbone, so I understand that split
a lot better. The whiteboard is not tied with the ND proxy. It comes
with mesh under as a solution to resolve a device address and do DAD.
Something that the router registration cannot do as soon as you have 2
routers.

Finally, I've not seen a consensus to rewrite ND from 08 to what it is
today. I've seen Geoff at the mike in favor, and you saying don't worry
I'll work with the author of ND simple and sort that out. Hardly a
consensus to me. Anyway, I consider the outcome, think that you could
have sorted better, and propose ins and outs. If you're so sure you
don't need feedback, just ignore it.

Cheers,

Pascal

> From: Zach Shelby [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 11:55 AM
> Cc: Erik Nordmark; [email-masked]; [email-masked];
> [email-masked]
> Again, I think you are fighting yourself here with regard to prefix
> dissemination. We have already agreed that nothing in nd-09 prevents
RPL
> from disseminating the PIOs. In fact, it specifically says that if the
routing
> protocol does that already, then great. Other routing protocol might
need
> the prefix dissemination option in nd-09, thus the spec "stands on its
own
> feet". So as far as the 6lowpan WG is concerned there is nothing to
discuss. It
> is up to the ROLL working group to discuss if and how it wants to
disseminate
> prefix information to RPL routers.
> 
> Regarding InstanceIDs and other RPL specific host issues, there is
nothing in
> nd-09 preventing that either. Nor can a 6lowpan document specify
> something for a host to do which is RPL related. If RPL wants to
specify some
> ND option to be carried in RAs with regard to flow labels - then go
for it. But
> don't complain about ND here...
> 
> Regarding the extended LoWPAN functionality you are referring to
below.
> The WG consensus after Hiroshima was to split the ND draft into a base
draft
> (which was done in nd-08 already!) and a separate Extended LoWPAN
draft.
> As I have told you, you need to find the time to write that extended
LoWPAN
> draft (let's do it) and explain how to achieve these kinds of
topologies. I'm
> happy to help, but my hands are full right now.
> 
> The WG consensus in Anaheim was to make a clean re-write of the WG
> document integrating the NS/NA mechanism from nd-simple and the base
> mechanism of address registration from nd-08. This is what we did. I
believe
> the result of this is a very good draft which specifies the
host-router interface
> and definitely stands on its own feet as it is mesh-under, route-over
and
> routing protocol independent as it should be.
> 
> It DOES!!!! Remember RPL is not *the* only routing protocol. I can
> implement DYMO on a LoWPAN and it will need the prefix dissemination
> method from nd-09.
> 
> > - make a separate spec for the ND proxy piece. We have already text
> > from Zach, Carsten and I that can be used
> 
> Pascal, you know very well that is your AP. This was also already
decided by
> the working group already after Hiroshima.
> 
> Argh,
> Zach
> 
> --

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 May 2010 04:45:32 -0700

> that does, then, no, it does not stand on its feet, sorry.

Are you talking about having two 6LBRs?
Or is this a concern about the wired backbone? Please be specific.

For the case of two 6LBRs it is done the same way as having two routers 
on an Ethernet: both routers are configured with the same prefix(es) 
which will be advertised in the Router Advertisements.

The only added thing in 6lowpan-nd is the Context option for header 
compression. That implies that the two routers need to be configured 
with the same compression information.

Note that the hosts will register with both of the routers, hence both 
have the full information about all the hosts.

What do you see as missing in 6lowpan-nd-09 for the case of 6LBRs?

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 May 2010 14:41:41 +0200

Hi Erik:

I think Zach and I came up with a common understanding. My concern had
not to do with a backbone. It has to do with 2 routers in a same mesh
under topology, and without the assumption that any node can reach any
other node using the mesh under technology.

To illustrate this, say you use the ND base draft in a Frame Relay
network. You build a hub and spoke with the router at the hub. The
router is at a central office, and there are DTEs at the branch office.
I agree, the draft works great! The router can resolve any incoming
packet because it has a proactive registration for it. Then we want to
place a second router. We place a switch between those and we split the
DLCIs in half between the routers. So each of the routers get half of
the registrations. There is simply no DLCI for the hosts to register to
the other router. 

In a same fashion, you do not want a node to register to all routers and
receive multicast from all routers in a LoWPAN that grows to the
thousands.
 
So with the draft alone, if router 1 gets a packet for a node attached
to router B, the registration does not help. So the router will either
multicast, which we wanted to avoid, or drop. That's my concern, that's
why I've been telling you it was broken for mesh under. Zach and I
agreed we could resolve this question by saying that 2 routers is
already an extended LoWPAN, that will be addressed by the spec left to
be done. Would you agree with that resolution?

Continuing on the FR image,  the deployment may choose either:

- route over. define an OSPFv3 instance and connect those 2 routers as
P2MP. Describing this is sort of operation out of scope for 6LoWPAN.
- whiteboard. Both routers write onto the subnet white board which nodes
they own, and let the mesh under figure out how they can reach one
another, can be using PVC or calling out an SVC... This would be what
extended does.

Extending further the model, it can either:

- larger route over. Extend your OSPFv3 instance in P2MP mode, or setup
a number of them if you need to meet different needs, and we end up with
something similar to what RPL does.
- proxy ND. This can be done for specific topologies, like trees, or in
the simplest expression, a backbone link, that would be point to point
between 2 routers or a fully meshed core, wherever multicast can be
emulated at a reasonable cost.  Just like ND itself, ND proxy  model
seems more appropriate for transit networks than for NBMA. 

I hope it's clearer now,

Pascal

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 1:46 PM
> Cc: Zach Shelby; [email-masked]; [email-masked];
> [email-masked]
> For the case of two 6LBRs it is done the same way as having two
routers on
> an Ethernet: both routers are configured with the same prefix(es)
which will
> be advertised in the Router Advertisements.
> 
with
> the same compression information.
> 
have
> the full information about all the hosts.
>

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 10 May 2010 06:41:36 -0700

Hi Pascal,

Everything you wrote below on ND-09 IS THE EXACT OPPOSITE of the WG
consensus from Anaheim.

Did you attend the 6LowPAN Anaheim session?

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Monday, May 10, 2010 2:07 AM
To: Erik Nordmark; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] [6lowpan] how does a node get an IP address

Hi Erik

has to
Ethernet to

routing
topologies is to
for the

 
which are
that the
router-to-router

 

Cheers,

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 09 May 2010 23:58:01 -0700

I think you are mistaken.
Mesh under works with just RFC 2461, since it is the layer 2 mesh that 
has to solve all the hard problems, essentially making things look like 
an Ethernet to IP.

You might be confusing mesh-under with the notion of having a wired 
backbone be part of the lowpan without participating in the lowpan 
routing protocols. While I think the best way to handle such physical 
topologies is to make the wired backbone be part of the lowpan routing 
protocol domain, 6lowpan-nd carries sufficient information in the case 
of mesh-under for the 6LBR to track all the IPv6 addresses that are 
registered.

I'm pretty sure I can build a route over solution using RIPv2 or OSPF 
which are existing IETF RFCs. It might be far from optimal, but it does 
indicate that the separation between the host-to-router interaction and 
the router-to-router is in the right place.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 May 2010 01:30:22 -0700

> Traffic Engineering is all about mapping flows of traffic onto complex
> So nothing real new. RPL just makes that a bit less manual, because we
> RPL dynamically builds its TE topologies and specifies the flow label
> interaction a bit deeper to automate the mapping of the flows onto those
> topologies.
>
> I see that as extension or evolution, but not revolution. A survival

If there is a need to evolve the Internet Architecture, it is best not 
done in a narrowly focused IETF working group.

But fundamentally I don't understand why a working group like ROLL that 
seems keen on building small and simple networking devices at the same 
time feel a requirement to add bells and whistles like this. Seems to be 
counter to designing a simple and robust network infrastructure.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 May 2010 02:01:29 -0700

The descriptions I've seen of the use of ROLL instances talk of 
differentiating things for the low delay vs. high throughput packets. 
This used to be called "ToS routing" back when OSPF supported it (I 
think it was removed because nobody used it.) One could envision 
something similar for ROLL using the Traffic Class field in the data 
packets, and building a separate tree for each traffic class.

But Pascal referred to OSPFv3 instances, which is merely a local 
identifier on one link to enable multiple OSPF ships in the night 
sharing e.g., one Ethernet. Thus that instance ID does not span multiple 
router hops. That has similar effect to having the OSPF control plane 
run on separate VLANs on that Ethernet.

The industry also seems to be using terms like routing instances for the 
cases when there are multiple set of interconnected (virtual) routers 
that e.g., provide a service for different customers.

Thus ROLL could benefit from clearer terminology and staying away from 
the term "instances"; if it is about Traffic Class then it makes sense 
to call it that.

I have no problem keeping the first RFC of a protocol as simple as 
possible. If the protocol gets widely deployed one can consider 
extending it later.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 May 2010 02:04:58 -0700

On 05/10/10 05:41 AM, Pascal Thubert (pthubert) wrote:
> place a second router.

OK

> We place a switch between those and we split the

But that isn't how nd-09 works. See section 5.5.
(The hosts register with more than one default router.)

> receive multicast from all routers in a LoWPAN that grows to the

If applications want to do multicast in a lowpan then the hosts would 
use MLD. That is orthogonal to the nd-09 registration option.

> be done. Would you agree with that resolution?

Might make sense for you to read nd-09, since it doesn't work that way.

    Erik

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 11 May 2010 17:02:33 -0700

Agree 100% on the following message below.

Architecturally, it is clean, portable, compatible with multiple routing
protocols if configuration and bootstrapping mechanisms such as addressing,
context transfer etc. are separated from the functions of a routing
protocol. RPL may be the only protocol being discussed currently at IETF,
but as mentioned previously by others that there are other ad-hoc or IGP
routing protocols that can be tweaked to run on a low-power and lossy
networks for different configurations and applications.

So, I completely disagree that RPL routing protocol carry the bootstrapping
information. 
Also, for easy deployment and initial adoption of the technology, RPL would
be better off if does not make itself complicated by trying to address all
the possible permutation and combination of situations in LLN.

Thanks,
-Samita

> > We have already agreed that nothing in nd-09 prevents RPL from
> disseminating the PIOs. In fact, it specifically says that if the routing
> protocol does that already, then great. Other routing protocol might need
> the prefix dissemination option in nd-09, thus the spec "stands on its own
discuss.
> It is up to the ROLL working group to discuss if and how it wants to
> disseminate prefix information to RPL routers.
> 
> +1.
> 
> However, please note also that a LoWPAN needs more information
disseminated
> than the PIOs.
> Unless RPL is extended to carry compression context as well, it seems more
> logical to do all this network configuration dissemination in 6LoWPAN-ND.
> Both compression context and prefix information is likely to change on
> relatively slow timescales (days/weeks), which is another reason why it
> seems appropriate to use a configuration protocol for the dissemination of
> both, rather than a routing protocol operating in terms of
seconds/minutes.

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 11 May 2010 17:51:44 -0700

Hi Pascal,

draft
> over Samita's draft was to radically eliminate multicast. The backbone
[SC>] 
 For the fact check and remembering the 6lowpan-ipv6-nd evolution:

draft-chakrabarti-6lowpan-ipv6-nd-00 was  published in Feb, 2006 co-authored
by Erik and I. This draft introduced the concept optimization of IPv6
multicast signaling into unicast ones for IEEE 802.15.4 in mesh-under
configuration.
At Dublin, 2008, authors/chairs decided to merge v05 of this draft,
draft-hui-6lowpan-nd,
draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00 to add
route-over and registration mechanism and produced 
draft-shelby-6lowpan-nd-* which was then adopted as wg draft.

So no draft was particularly chosen over another draft. IMHO, that was the
beginning
 of all-purpose (aka. Kitchen sink) 6lowpan-ND protocol which has had
trouble in the wg as folks needed to implement unnecessary code for corner
cases and unwanted usage. 6lowpan working group decided to split nd-07 to
have a base draft.

Nd-simple in Anaheim was an attempt to fix that problem. Wg welcomed the
draft and ND-09 was created on the base idea of ND-simple and part of ND-08.

ND-09 is not broken as claimed below. ND-09 is developed to address basic
auto-configuration, minimal multicast and neighbor discovery with
reliability while staying as close to RFC 4861 as possible for minimal code
change.
 The white-boarding , backbone and extended lowpans etc. are not part of
basic necessity in most applications in 6LoWPAN. The best way to handle them
is to write a separate draft on them and move forward.

Regards,
-Samita

> router draft takes a number of measures to get there. The most obvious is
> the use of NS/NA as a registration mechanism, and I'm very happy that this
> core idea is still present in the current draft, though the original
author
> somewhat disappeared by some black magic that's quite unusual to the IETF.
> 
under
> because it does not fulfill that expectation. For instance, I do not see
how
> multicast is avoided in mesh under when there are more than one router in
> the subnet, without involving routing protocols, which would be
route-over.
> From the backbone router draft till ND-07, we answered that question at
the
> ND level using a whiteboard registrar as a backend to the registration.
> Please do not confuse that question with the use of a backbone where
> admittedly, either an SGP or ND proxy could work.
> 
be
> used to front end RPL either. And it's broken for mesh under because it is
> incomplete. I cannot see how the whole picture works from either this
draft
> alone, or any combination of drafts on the works today.
> 
resolve
> the issues I see:

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 12 May 2010 10:16:27 +0200

>  The white-boarding , backbone and extended lowpans etc. are 
> not part of basic necessity in most applications in 6LoWPAN. 
> The best way to handle them is to write a separate draft on 
> them and move forward.

+1 

> [mailto:[email-masked]] On Behalf Of Samita Chakrabarti
> Sent: Wednesday, May 12, 2010 02:52
> To: [email-masked]; 'Pascal Thubert (pthubert)'; 'Erik 
> Nordmark'; [email-masked]
> draft-chakrabarti-6lowpan-ipv6-nd-00 was  published in Feb, 
> 2006 co-authored by Erik and I. This draft introduced the 
> concept optimization of IPv6 multicast signaling into unicast 
> ones for IEEE 802.15.4 in mesh-under configuration.
> At Dublin, 2008, authors/chairs decided to merge v05 of this 
> draft, draft-hui-6lowpan-nd, 
> draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00 
> to add route-over and registration mechanism and produced
> So no draft was particularly chosen over another draft. IMHO, 
> that was the beginning  of all-purpose (aka. Kitchen sink) 
> 6lowpan-ND protocol which has had trouble in the wg as folks 
> needed to implement unnecessary code for corner cases and 
> unwanted usage. 6lowpan working group decided to split nd-07 
> to have a base draft.
> 
> Nd-simple in Anaheim was an attempt to fix that problem. Wg 
> welcomed the draft and ND-09 was created on the base idea of 
> ND-simple and part of ND-08.
> 
> 
> ND-09 is not broken as claimed below. ND-09 is developed to 
> address basic auto-configuration, minimal multicast and 
> neighbor discovery with reliability while staying as close to 
> RFC 4861 as possible for minimal code change.
>  The white-boarding , backbone and extended lowpans etc. are 
> not part of basic necessity in most applications in 6LoWPAN. 
> The best way to handle them is to write a separate draft on 
> them and move forward.
> 
> Regards,
> -Samita
> 
> > router draft takes a number of measures to get there. The 
> most obvious 
> > is the use of NS/NA as a registration mechanism, and I'm very happy 
> > that this core idea is still present in the current draft, 
> though the 
> > original
> author
> > because it does not fulfill that expectation. For instance, 
> I do not 
> > see
> how
> > multicast is avoided in mesh under when there are more than 
> one router 
> > in the subnet, without involving routing protocols, which would be
> route-over.
> > From the backbone router draft till ND-07, we answered that 
> question 
> > at
> the
> > used to front end RPL either. And it's broken for mesh 
> under because 
> > this

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 May 2010 13:31:23 +0200

Hi Anders;

The current ND draft has a white board, though it calls it a neighbor
cache. Sometimes, renaming things is good. In this instance, I do not
know. Clearly, standard neighbor cache entries must not be confused with
the ones gleaned for the registration process, because only the latter
can be fed into the backbone mechanism, be it route over or mesh under. 

The White Board conceptually differs from the traditional Neighbor
Cache:

- The WB is a table as opposed to a cache. A neighbor cache entry can
stay STALE for a very long time after the node is gone. A neighbor cache
entry can be flushed to make room anytime. So a neighbor cache entry
does not represent the node accurately enough to be redistributed in a
routing protocol or proxied over a backbone. 

- It is fed proactively using a registration as opposed to reactively to
traffic. The registration and timely reregistration guarantees the
presence of the node proactively. NUD is reactive, depends on traffic.
It is nice to have but not mandatory as long as you have a registration.
In a very constrained node, I'm not sure you really want to implement
the additional 10 pages of specs that this represents. You should tell
us.

The original backbone router draft has the exact same white board as the
current ND-09, and uses ND proxy over a backbone to allow for multiple
routers in the subnet. For more complex topologies that include route
over and complex meshes with no backbone, the WG doc evolved the concept
to add a centralized registrar for the purpose of DAD and such.

I got the message loud and clear that the group does not want that
latter piece in the base spec:
- which works if the spec is specific in which topologies it supports
and which topologies it does not. That was clear in ND 08 section 2.2
but is gone from 09. 
- which is good to speed up adoption of the registration, which is a
great progress for ND at large .

Cheers,

Pascal

> From: Anders Brandt [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2010 10:16 AM
> To: Samita Chakrabarti; Pascal Thubert (pthubert)
> Subject: RE: [6lowpan] [Roll] how does a node get an IP address
> 
> 
> >  The white-boarding , backbone and extended lowpans etc. are not
part
> > of basic necessity in most applications in 6LoWPAN.
> > The best way to handle them is to write a separate draft on them and
> > move forward.
> 
> +1
> 
> > To: [email-masked]; 'Pascal Thubert (pthubert)'; 'Erik Nordmark';
> > 2006 co-authored by Erik and I. This draft introduced the concept
> > optimization of IPv6 multicast signaling into unicast ones for IEEE
> > 802.15.4 in mesh-under configuration.
> > So no draft was particularly chosen over another draft. IMHO, that
was
> > the beginning  of all-purpose (aka. Kitchen sink) 6lowpan-ND
protocol
> > which has had trouble in the wg as folks needed to implement
> > unnecessary code for corner cases and unwanted usage. 6lowpan
working
> > group decided to split nd-07 to have a base draft.
> >
> > Nd-simple in Anaheim was an attempt to fix that problem. Wg welcomed
> > the draft and ND-09 was created on the base idea of ND-simple and
part
> > of ND-08.
> >
> >
> > ND-09 is not broken as claimed below. ND-09 is developed to address
> > basic auto-configuration, minimal multicast and neighbor discovery
> > with reliability while staying as close to RFC 4861 as possible for
> > minimal code change.
> >  The white-boarding , backbone and extended lowpans etc. are not
part
> > of basic necessity in most applications in 6LoWPAN.
> > The best way to handle them is to write a separate draft on them and
> > move forward.
> >
> > Regards,
> > -Samita
> >

---

From: Philip Levis <[email-masked]>
Date: Wed, 12 May 2010 14:59:41 -0700

Pascal,

I still don't understand how this could possibly work. I'm an application on the Internet. I want to send packets to a RPL node. How am I supposed to set the flow label? You are assuming an out-of-band communication mechanism to set the label. This requires a sender to know that the endpoint is a RPL node; does this really seem like a good idea? Instance IDs MUST work when a sender does not know the destination runs RPL. RPL therefore MUST solve the case where the sender does not set a flow label. Otherwise only nodes that are aware of RPL and can determine the instance ID can communicate with RPL nodes. This does not seem like a good idea to me...

The current proposed mechanism is that there is an optional RPL IPv6 header that specifies the instance ID. If that header is not present, then RPL can assume the instance ID is in the flow label.

Phil