Subject: [Roll] Formation of a Routing Protocol Design Team for ROLL

From: JP Vasseur <[email-masked]>
Date: Wed, 1 Apr 2009 09:57:34 +0200

Dear WG,

We have formed a new Design Team in the ROLL Working Group. Please  
find below the charter and team members.

Since some of you may not be familiar with the concept of a Design  
Team, I would like to remind a few points:

* The work produced by a Design Team has no special status in the WG  
and is subject to WG consensus as any other individual submission
* We ask the Design Team to request for input from the WG and to  
provide regular updates on the progress: please send input requests to  
the mailing list, post regular updates of the document to get a chance  
to everybody to comment, ...
* All: please provide input to the Design Team and copy the mailing  
list.

Design Team Members
###################
	Tim Winter (Editor)
	Pascal Thubert
	Stephen Dawson
	Kris Pister
	Thomas Clausen
	Jonathan Hui

(Thanks to the DT members)

Charter
######

The charter is fairly simple: produce an IPv6 routing solution for LLN  
(one of our new WG item) in light of the four application-specific  
routing requirements documents:
	* draft-ietf-roll-urban-routing-reqs
	* draft-ietf-roll-industrial-routing-reqs
	* draft-ietf-roll-home-routing-reqs
	* draft-ietf-roll-building-routing-reqs

The routing solution may either be based on an extension of an  
existing routing protocol or a new protocol. In the former case, the  
design team is expected to interact with the WG that is responsible  
for the development of the protocol.

Please make sure to be aligned with the ROLL terminology document and  
provide input to their authors should new terms be introduced.

According to our charter, it is asked to pay a particular attention to  
the security and manageability aspects of the routing solution.

The Design Team is not tasked to produce a MIB for the routing solution.

Milestones
#########

May 1: produce a first draft of the routing solution document
IETF-75 meeting: produce a more complete version of the document by  
the cut-off submission date for the IETF-75 meeting.

The Design Team will be dissolved once the WG will have adopted a  
routing solution document as a WG document (should it be the one  
proposed by the WG or not).

It is strongly encouraged to produce new version as the document  
progress (each time a substantial change is made to the document).

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Apr 2009 10:07:40 +0200

JP Vasseur a écrit :
[...]
> The routing solution may either be based on an extension of an existing 
> routing protocol or a new protocol. In the former case, the design team 
> is expected to interact with the WG that is responsible for the 
> development of the protocol. 

And in the latter case?...  is the DT free to not interact with the WG 
and go ahead design a new protocol?

Who makes the choice new vs existing?  Is it the DT making that choice?

Alex

> IETF-75 meeting: produce a more complete version of the document by the 
> cut-off submission date for the IETF-75 meeting.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Wed, 1 Apr 2009 10:15:36 +0200

Hi Alex,

On Apr 1, 2009, at 10:07 AM, Alexandru Petrescu wrote:

> JP Vasseur a écrit :
> [...]
>> Charter
>> ######
>> The charter is fairly simple: produce an IPv6 routing solution for  
>> LLN (one of our new WG item) in light of the four application- 
>> specific routing requirements documents:
>> existing routing protocol or a new protocol. In the former case,  
>> the design team is expected to interact with the WG that is  
>> responsible for the development of the protocol.
>
> And in the latter case?...

There is nothing specific to this WG: when a WG specify a protocol,  
the WG will have to decide whether or not interacting with a existing  
WG is necessary or not.

>  is the DT free to not interact with the WG and go ahead design a  
> new protocol?
>

As pointed out in the email:

"* The work produced by a Design Team has no special status in the WG  
and is subject to WG consensus as any other individual submission"

The DT will make that choice - Anyone is free to make any proposal.

JP.

>
> Alex
>
>> Please make sure to be aligned with the ROLL terminology document  
>> and provide input to their authors should new terms be introduced.
>> According to our charter, it is asked to pay a particular attention  
>> to the security and manageability aspects of the routing solution.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 2 Apr 2009 05:32:14 +0200

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: April 1, 2009 9:57:34 AM CEDT
> To: ROLL WG <[email-masked]>
> Subject: [Roll] Formation of a Routing Protocol Design Team for ROLL
>
> Dear WG,
>
> provide regular updates on the progress: please send input requests  
> to the mailing list, post regular updates of the document to get a  
> chance to everybody to comment, ...

	   Anders Brandt

---

From: Philip Levis <[email-masked]>
Date: Wed, 8 Apr 2009 14:11:33 -0700

> * All: please provide input to the Design Team and copy the mailing  

JP,

How does one join the design team? I would like to join.

Phil

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Fri, 10 Apr 2009 15:59:47 +0900

Hi JP,

It' my pure question about design team.
I only saw the case that WG decides to make a design team for a
certain WG item when people agreed to have a design team in the
meeting. And, chairmen askes volunteers for the DT.
I never saw that DT has been just announced in the mailing list.
(Well, i have only 10years experience in the ietf. Maybe it's possible
but i never saw the case like this so far. Thus I feel a bit that
there is inner-circle discussion in ROLL WG, which normal participants
cannot share.)

Please don't misunderstand me. I think the current design team members
are great and
I think the members are the best choice what ROLL could have for a
ROLL routing solution.

-eunah

On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis <[email-masked]> wrote:
>> We have formed a new Design Team in the ROLL Working Group. Please find
>> below the charter and team members.
>>
>> Since some of you may not be familiar with the concept of a Design Team, I
>> would like to remind a few points:
>>
>> * The work produced by a Design Team has no special status in the WG and
>> is subject to WG consensus as any other individual submission
>> * We ask the Design Team to request for input from the WG and to provide
>> regular updates on the progress: please send input requests to the mailing
>> list, post regular updates of the document to get a chance to everybody to
>> comment, ...
>> * All: please provide input to the Design Team and copy the mailing list.
>
> JP,
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 10 Apr 2009 09:09:50 +0200

Hi Eunah,

> there is inner-circle discussion in ROLL WG, which normal participants

Not at all. We (co-chair) came up with a list of names. Such a process  
is not
unusual at all. Should you be interested you please look at Section  
6.5 of RFC 2418

> I think the members are the best choice what ROLL could have for a

Thanks for the feed-back.

Something really important: as pointed out in my first email the DT  
has no special status
and nobody should feel "excluded" ! We do need to contribution of all  
ROLL contributors.
Furthermore, the DT will regularly poll the other members for feed- 
back, advise, ... and in
addition everybody is free to post its own proposal of course.

Last but not least: there are many very valuable contributors of ROLL  
that are purposely not part
of the DT: it is also extremely important to have non DT members  
providing inputs, contribution, ...

Hope this help.

Thanks.

JP.

>>> provide

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 13:10:08 +0200

JP, I must say I was also a bit surprised to see a declaration of
forming a DT... without it been mentioned at the last WG meeting.

I doubt it is clear what the DT is going to produce, what is its goal,
what is the starting document.

The individual proposal documents (HYDRO, and thubert-fundamentals) that
I think are related to this DT have _very_ few things in common.  I am
not sure there is any other proposal document which is supposed to be
part of the DT scope.

Another less clear aspect is the 6lowpan relationship: 6lowpan does link
(but also 6lowpan ND does 'multi-hop'), and ROLL does routing (but also
HYDRO does NS/NA)...

What is the base doc of the DT?

What are the docs considered by the DT?

I also mean to say that I generally think that the DT as presented does
seem to correspond to the IETF procedure, _is_ subject to the WG
remarks, and may produce a good output, IMHO.

Alex

JP Vasseur a écrit :
>> It' my pure question about design team. I only saw the case that WG
>>  decides to make a design team for a certain WG item when people 
>> agreed to have a design team in the meeting. And, chairmen askes 
>> volunteers for the DT. I never saw that DT has been just announced 
>> in the mailing list. (Well, i have only 10years experience in the 
>> ietf. Maybe it's possible but i never saw the case like this so 
>> far. Thus I feel a bit that there is inner-circle discussion in 
>> ROLL WG, which normal participants cannot share.)
> 
> Not at all. We (co-chair) came up with a list of names. Such a 
> process is not unusual at all. Should you be interested you please 
> look at Section 6.5 of RFC 2418
> 
>> 
>> Please don't misunderstand me. I think the current design team 
>> members are great and I think the members are the best choice what 
>> ROLL could have for a ROLL routing solution.
>> 
> 
> has no special status and nobody should feel "excluded" ! We do need 
> to contribution of all ROLL contributors. Furthermore, the DT will 
> regularly poll the other members for feed-back, advise, ... and in 
>  that are purposely not part of the DT: it is also extremely 
> important to have non DT members providing inputs, contribution, ...
> 
> Hope this help.
> 
> Thanks.
> 
> JP.
> 
>> -eunah
>> 
>> 
>>>> We have formed a new Design Team in the ROLL Working Group. 
>>>> Please find below the charter and team members.
>>>> 
>>>> Since some of you may not be familiar with the concept of a 
>>>> Design Team, I would like to remind a few points:
>>>> 
>>>> * The work produced by a Design Team has no special status in 
>>>> the WG and is subject to WG consensus as any other individual 
>>>> submission * We ask the Design Team to request for input from 
>>>> the WG and to provide regular updates on the progress: please 
>>>> send input requests to the mailing list, post regular updates 
>>>> of the document to get a chance to everybody to comment, ... * 
>>>> All: please provide input to the Design Team and copy the 
>>>> mailing list.
>>> 
>>> JP,
>>> 
>>> Phil _______________________________________________ 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: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 13:12:17 +0200

JP,

Other IETF Design Teams have their email list public read access 
(private write access) - this is pretty much useful to follow up what's 
going on.  Is it the case of the ROLL DT?  Are the archives available 
somewhere?

Thanks,

Alex

JP Vasseur a écrit :
> unusual at all. Should you be interested you please look at Section 6.5 
> of RFC 2418
> 
>>
> Something really important: as pointed out in my first email the DT has 
> no special status
> Furthermore, the DT will regularly poll the other members for feed-back, 
> advise, ... and in
>>>> and

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Apr 2009 13:51:22 +0200

> (but also 6lowpan ND does 'multi-hop'), and ROLL does routing (but  

Well, let's work on this relationship then.

6lowpan-nd strictly is about maintaining the router-host relationship.
(Some confusion about this previously well-defined term may come in  
when a router wants to bootstrap in a host role before going router.)

6lowpan-nd mentions "multi-hop" in two places:

-- in the definitions of "6LoWPAN node", "mesh-under" and "route- 
over", and related explanatory introductions.
-- in the "Multi-Hop Information Option".

The latter provides for an optimization that "allows for the full set  
of prefix information options to be sent only periodically in  
unsolicited RAs".  You could argue whether the name of the option is  
that great; the point here is that ND information has to percolate  
through the whole LoWPAN and not just on a single link, and that  
adding a sequence number can make this percolation much more efficient.

There is also a discussion in 6lowpan-nd about a way for a router to  
indicate to hosts some form of preference in an RA.  There were  
proposals to make this depend on a hop-count (which would work best  
with routing protocols where hop-counts are an important metric), but  
I think we are arriving at a more general solution.

I think some confusion may come from the term "neighbor".
In ND this really means "peer on the link that I (want to) know the L2  
address and liveliness of".
In routing protocols that means "node I can directly communicate with  
and may want to exchange routing information with".
Historically, those two meanings were very close.
With the more complex link models we are going to, there is a big  
difference.
MANET has started calling the second kind of relationship  
"neighborhood" in order to have two different terms.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 15:44:28 +0200

Hi, let me take advantage of this to talk about the 6lowpan ND document.

[...]
> -- in the definitions of "6LoWPAN node", "mesh-under" and
> "route-over", and related explanatory introductions. -- in the
> "Multi-Hop Information Option".
> 
> unsolicited RAs".

But the full set of PIOs is _always_ sent periodically in unsolicited 
RAs, anyways.

Does it mean some options are sent some times, and some other options
other times?  If yes - what does this have to do with 'multi-hop' at all.

> You could argue whether the name of the option is that great;

YEs - I argue.  By your explanation it should be better called "sequence 
number tagging information option" and less a "multi-hop information 
option".

> the point here is that ND information has to percolate through the
> whole LoWPAN and not just on a single link, and that adding a
> sequence number can make this percolation much more efficient.

But I thought the entire lowpan is a subnet is a link (the link-scope 
multicast covers the entire lowpan subnet).  Whereas you seem to mean 
the whole LoWPAN is not just a single link...

The 'percolation' seems to be new.

Some contradictory but sparsed paragraphs:
>  This document also specifies the seamless integration of an extended
>    LoWPAN and multiple edge routers on a shared backbone link (e.g.
>    Ethernet) to form a single IPv6 subnet.

So both the entire lowpan and the ER's egress interface form a single 
IPv6 subnet.

> The link-local scope is defined by a LoWPAN link, which
>    includes nodes reachable over a single radio transmission at each
>    instant.

But a single IPv6 subnet is the link-local scope, and Ethernet is wired, 
so does the link-local scope cover the Ethernet as well?

>  As a result,
>    we extend ND as specified in [RFC4861] to operate over an entire
>    LoWPAN subnet, rather than a single IP link.

"Rather"?  But I thought the entire link is an IP subnet is an IP link.

> In mesh under, each intermidiate
>       node performs multi-hop forwarding at L2.  In route over, each
>       intermidiate node serves as a LoWPAN router performing IP routing.

It is not clear if the text means by IP routing a typical routing 
between two subnets with a routing table and a longest-prefix match 
search and two interfaces, or a _new_ "IP" routing.

> Note that routers only exist
>    in route over networks, and in mesh under networks nodes are on the
>    same link with edge routers.

... and route over networks are routing between subnets, whereas here we 
only have one subnet.  Can one "IP route" between a single IP subnet?

>    With the backhaul model, in a mesh under network the link and subnet
>    are equivalent as the link spans the entire LoWPAN.

But do you mean when there's no backhaul model the link and subnet are 
not equivalent?

>    In this document, a LoWPAN subnet is defined to be a collection of
>    LoWPAN links interconnected by routers that have the same subnet
>    prefix.

Let's exemplify collection with two members:

How does a router connect two links, yet has a single interface, and has 
the same subnet prefix on both (on both "what")?  Is that a "bridge" 
actually?  Is that a dumb repeater?  Is that an application-layer (UDP) 
repeating all packets it receives? (no routing table entry, only one 
interface).

Alex

PS: paragraphs below worth discussing one day:
C. Bormann wrote:
> I think some confusion may come from the term "neighbor". In ND this
> really means "peer on the link that I (want to) know the L2 address
> and liveliness of". In routing protocols that means "node I can
> directly communicate with and may want to exchange routing
> information with". Historically, those two meanings were very close. 
> difference. MANET has started calling the second kind of relationship

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Apr 2009 19:00:42 +0200

> Hi, let me take advantage of this to talk about the 6lowpan ND  

Well, we should have the detailed discussion of the ND specific  
aspects on the 6lowpan list, please.

However, we do need to have agreement between the ROLL WG (as a  
purveyor of routing protocols) and the 6lowpan WG on this point about  
the model we are using:

>  Can one "IP route" between a single IP subnet?

Yes.  That is a result of the definition of "subnet" and "route-over"  
that we have arrived at.
This is the point of section 5 of draft-ietf-6lowpan-nd-02.

(If you think that routing within a subnet is not something that  
immediately comes to mind when hearing "route-over", I'm with you, but  
again that is the current terminology.)

> But do you mean when there's no backhaul model

(I don't tend to think about the case where there is no Edge Router --  
is that what you mean?)

> the link and subnet are not equivalent?

In a pure mesh-under world (which the cited text is talking about),  
they are equivalent -- making them equivalent is exactly the job of a  
full mesh-under protocol.
In a route-over world (with or without embedded mesh-under islands),  
they aren't.

> How does a router connect two links, yet has a single interface, and  
> has the same subnet prefix on both (on both "what")?

("Two links" sounds as if the extent of a "link" is independent from  
one's point of view, which in a radio network it isn't.  A 6lowpan  
node typically has exactly one interface and thus one link.)
By making the on-link decision (i.e., L2-address the host via ND vs.  
L2-address the next-hop router via the routing protocol) based on the  
routing information instead of just using the prefix.

> Is that a "bridge" actually?

No.  No MAC address learning is involved.

> Is that a dumb repeater?

No.  Forwarding of a packet received is based on L2 address matching  
(possibly followed by reassembly) followed by a consultation of the L3  
FIB.

> Is that an application-layer (UDP) repeating all packets it  
> receives? (no routing table entry, only one interface).

No.  The forwarding is at L3, e.g., no interpretation of IPv6 fragment  
headers or destination options headers is involved in the forwarding.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 20:12:32 +0200

Carsten,

Thank you for the clarifications mentioned below (single-interface 
router is not a bridge/repeater and with the definition of subnet 
arrived at).

I will try to clarify further on the 6lowpan list.

Alex

Carsten Bormann a écrit :
> Well, we should have the detailed discussion of the ND specific aspects 
> on the 6lowpan list, please.
> 
> However, we do need to have agreement between the ROLL WG (as a purveyor 
> of routing protocols) and the 6lowpan WG on this point about the model 
> we are using:
> 
> In a pure mesh-under world (which the cited text is talking about), they 
> are equivalent -- making them equivalent is exactly the job of a full 
> mesh-under protocol.
> one's point of view, which in a radio network it isn't.  A 6lowpan node 
> typically has exactly one interface and thus one link.)
> (possibly followed by reassembly) followed by a consultation of the L3 FIB.
> 
>> Is that an application-layer (UDP) repeating all packets it receives? 
>> (no routing table entry, only one interface).
>

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 10 Apr 2009 16:01:20 -0400

From: Carsten Bormann <[email-masked]>
   Date: Fri, 10 Apr 2009 19:00:42 +0200

   (I don't tend to think about the case where there is no
    Edge Router -- ...)

I have a question on this, stemming from my lack of
familiarity with the details of IP routing.

Suppose I have a 6LowPAN/ROLL network being used for energy
management in a home.  The network includes the electric
meter, which has a backhaul connection back to the utility.
The utility, being very protective of its backhaul network,
has a firewall in the meter to keep out everything except
the utility's own traffic.  Given the presence of the
firewall, does it still make sense to use the meter as an
Edge Router?
                            -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 10 Apr 2009 16:44:35 -0400

From: Geoff Mulligan <[email-masked]>
   Date: Fri, 10 Apr 2009 14:11:11 -0600

   > firewall, does it still make sense to use the meter as an

   yes as an edge router for the in home devices connected to the utilities
   network.

Thanks for the quick response.

>From the LLN Routing Fundamentals draft, the meter would
then make itself the root of a grounded tree.  Would it set
the Default flag in the TIO?  What if another Edge Router
with a less-restrictive backhaul, via an ISP perhaps, is
added to the home network?  As long as the meter is the
only Edge Router it makes sense to have it be the default.
What happens when the second one is added isn't clear to
me.

I expect this may turn out to be a common arrangement, with
the second Edge Router being a third-party energy management
device.

                                  -Richard Kelsey

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 22:53:47 +0200

> firewall, does it still make sense to use the meter as an

I don't think it would make much sense because Edge Router as currently 
specified by 6LoWPAN ND seems to not be doing any routing at all - but a 
sort of bridging, and firewalls are very much rules on the IP fields, 
and less if at all rules on the MAC fields.

I doubt Utility would be happy with Client meter bridging all sensor 
traffic into the backhaul, or otherwise filtered by huge tables of MAC 
filter rules...

Alex

---

From: Zach Shelby <[email-masked]>
Date: Sat, 11 Apr 2009 10:11:00 +0300

Hi,

> and less if at all rules on the MAC fields.

That is not true. In 6LoWPAN the edge router is an IP router just like 
any other, and is a natural place to use a firewall. The same goes for 
Border Routers in ROLL. I think the terminology actually needs to be 
synchronized - we should call it a Border Router also in 6LoWPAN?

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Zach Shelby <[email-masked]>
Date: Sat, 11 Apr 2009 10:18:52 +0300

Hi,

> What happens when the second one is added isn't clear to

As both the meter, and the router of the ISP are attached to the 
Internet in different places, each will have a different IPv6 prefix to 
advertise on their ROLL interface. Thus they are two different networks, 
each having its own grounded tree. Sensor nodes will just have to choose 
which it wants to attach to using the information in the RA. Both ERs 
would be default, but the depth and metric to them will be different.

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 11 Apr 2009 09:22:38 +0200

On Apr 11, 2009, at 09:11, Zach Shelby wrote:

> Border Router

In general usage, Border Routers are typically the ones that have to  
handle cross-domain issues.
A 6lowpan Edge Router may have that role in certain cases, but in  
others, it doesn't.
I'd prefer to stay with a term that doesn't always imply a change of  
domain.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Apr 2009 14:07:42 +0200

Zach Shelby a écrit :
>>> From: Carsten Bormann <[email-masked]> Date: Fri, 10 Apr 2009
>>> 19:00:42 +0200
>>> 
>>> (I don't tend to think about the case where there is no Edge
>>> Router -- ...)
>>> 
>>> I have a question on this, stemming from my lack of familiarity
>>> with the details of IP routing.
>>> 
>>> management in a home.  The network includes the electric meter,
>>> which has a backhaul connection back to the utility. The utility,
>>> being very protective of its backhaul network, has a firewall in
>>> the meter to keep out everything except the utility's own
>>> traffic.   Given the presence of the firewall, does it still make
>>> sense to use the meter as an Edge Router?
>> 
>> I don't think it would make much sense because Edge Router as 
>> currently specified by 6LoWPAN ND seems to not be doing any routing
>> at all - but a sort of bridging, and firewalls are very much rules
>> on the IP fields, and less if at all rules on the MAC fields.
> 
> That is not true. In 6LoWPAN the edge router is an IP router just
> like any other, and is a natural place to use a firewall.

Yes, but, pictorially speaking:

                   |egress(backbone)            \
                 ------                          |
                | ER   |                         |
                 ------                           > single IPv6 subnet
                   |ingress                      |
                  o  o                           |
                o   o  (lowpan nodes)           /

> Ethernet) to form a single IPv6 subnet.

The ND document says that ER egress interface and the LoWPAN nodes form
a single subnet - that is not a typical router.  A typical router is
connected to two or more different subnets.

In this sense, it's difficult to consider ER to be a typical router
doing a typical firewall.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Apr 2009 14:12:42 +0200

Carsten Bormann a écrit :
> handle cross-domain issues. A 6lowpan Edge Router may have that role 
> in certain cases, but in others, it doesn't. I'd prefer to stay with 
> a term that doesn't always imply a change of domain.

Well I also see Border Router indeed to be OSPF router at the limit of
an OSPF area...

I used the term Border Router in some drafts where OSPF wasn't used (but
Mobile IP) and it seemed to be understood by others.

I could live with Edge Router as well.

And Access Router could be proposed as well, because it typically links
a wired Ethernet to a wireless medium (it's used for WiFi and 3G and more).

Alex

---

From: Richard Kelsey <[email-masked]>
Date: Sat, 11 Apr 2009 14:16:01 -0400

Date: Sat, 11 Apr 2009 10:18:52 +0300
   From: Zach Shelby <[email-masked]>

How are packets routed between the two different networks?
In the LLN Routing Fundamentals draft a router "uses and
advertises at most one tree as Default tree".  How does a
router using the meter's default tree get a packet to the
ISP router and from there to the Internet?  If it sends it up
to the meter it will get blocked by the firewall.  Does the
ISP's router indicate that it is a better default in some
way?
                                 -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 11 Apr 2009 11:19:42 -0700

Hi Richard,

If both egress routers are advertising default routes, then I see no  
problem with the stub network deciding which to choose. If they have  
different costs, then definitely the two should be advertising  
different costs. If the meter network only wants to accept traffic to  
a particular prefix, then it should only be advertising that.

I do think we need to better define what exactly is an Edge Router in  
and out of a 6lowpan context. In general, I think of an Edge Router as  
nothing more than a router that routes between an L2N network to a non- 
L2N network. In the 6lowpan context, we typically associate an Edge  
Router with one that also maintains the "whiteboard" for nodes in the  
6lowpan network. However, I'm not sure we need to bind them together.

Specific to the 6LoWPAN ND draft, you do bring up an important case -  
one where two or more Edge Routers are not connected by a "backbone"  
network. I think there are interesting questions there that are not  
dealt with in the current 6LoWPAN ND draft (e.g. how is the whiteboard  
information distributed between edge routers if at all? can we have a  
particular whiteboard specific for a prefix maintained at only the  
Edge Router that advertises that prefix? do whiteboards have to be  
maintained at edge routers?). We should probably open a new thread on  
this topic in the 6LoWPAN ML...

--
Jonathan Hui

---

From: Geoff Mulligan <[email-masked]>
Date: Sat, 11 Apr 2009 18:29:20 -0600

I don't think that there is any restriction that Edge Router (even as
defined in the ND draft) is not doing routing.  

But, I was interpretting the term edge router as a generic term for a
device on the edge between a 6lowpan network and some other network,
perhaps using a different media.  In this case the edge router might
only bridge, but it might also route if they are different subnets.
This would then be a perfectly appropriate place to place a firewall.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 10 Apr 2009 14:11:11 -0600

geoff

---

From: JP Vasseur <[email-masked]>
Date: Tue, 14 Apr 2009 13:45:45 +0200

Hi Alex,

> forming a DT... without it been mentioned at the last WG meeting.

DT formation are always announced on the ML.

> what is the starting document.

Please see the email. We discussed with the DT and apparently this is  
clear for them and
others.

> not sure there is any other proposal document which is supposed to be

The goal of the DT is not to merge all potential proposals but to  
produce a routing specification
according to our charter. Please read my original email.

> What are the docs considered by the DT?

Please see the DT milestones.

Thanks.

JP.

>> has no special status and nobody should feel "excluded" ! We do  
>> need to contribution of all ROLL contributors. Furthermore, the DT  
>> will regularly poll the other members for feed-back, advise, ...  
>> and in addition everybody is free to post its own proposal of course.
>>>>> send input requests to the mailing list, post regular updates of  
>>>>> the document to get a chance to everybody to comment, ... * All:  
>>>>> please provide input to the Design Team and copy the mailing list.
>>>> JP,
>> _______________________________________________ Roll mailing list [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Apr 2009 17:31:27 +0200

Hi Richard:

I see 2 things here that are supposed to help, one is security/policy
and the other is multiple tree with eventually Multi-Topology Routing.

I suspect that the meters from the utility could have their own L2
security in place and only talk to one another. If that's so then the
home and the meter networks will act as ship in the night?

If not, then it can be a matter of policy, that can be implemented by
what tree discovery calls a plug in, arguably a ill-chosen term (sorry
Charlie). A plugin is a decision engine that selects a preferred parent
based on multiple information. As we discussed at the WG meeting, we get
an optimum network only if all nodes share the same plugin, otherwise we
get at least something loopless. For instance, a given plug in might
white list or black list trees based on information in the TIO. The
result is the same, you end up with 2 different networks. 

In the second category, if the meter edge router advertises a prefix
that encompasses all that the metering applications need, then it does
not need to be advertised as default tree. The nodes can participate to
that tree as non default but since they install a route to the Tree ID
via the root of tree, all the metering traffic will go that way whereas
the default will be routed via the default tree.

Finally MTR (listed in the advanced section) enables joining multiple
default trees if that's what you really need in a given deployment. If
you use a default route for a given packet then you need to mark the
packet to indicate which default tree you have selected, and every node
along the way have to understand that marking and follow the same tree.
An example of marking is a routing header indicating that the packet is
to be routed via the root of the selected default tree. That way, a
meter would flag its packets as metering and they would be forwarded
over the meter tree.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Kelsey
>Sent: samedi 11 avril 2009 20:16
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [Roll] 6lowpan-ND vs. ROLL
>

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 15 Apr 2009 15:24:34 -0400

Date: Wed, 15 Apr 2009 17:31:27 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

In the network I was describing there are three typs of device:
  - a meter, which has an essentially private backhaul network
  - an energy management device, which has a connection to
    a normal ISP
  - one or more appliances
The appliances need to exchange messages with both the
meter and the management device, so they all need to be on
the same L2 network.

The network monitoring device, which is the one with the
(relatively) unrestricted backhaul, is optional.  If it
isn't there, and the only access router is the meter,
then the network has no default tree.  Is that acceptable?

Presumably the decision as to which default tree to use is
made on the basis of the destination address.  That doesn't
sound like a default.  Or the is choice of which default
tree to use made on the basis of some other information?

                                  -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Apr 2009 10:39:00 +0200

Hi Richard

>then the network has no default tree.  Is that acceptable?

Well packets that do not match a route are dropped. That's certainly
acceptable.

>tree to use made on the basis of some other information?

That would be the previous case. Long as you route per destination that
match prefixes advertised by the root you're fine, the longest match
wins and you follow that tree to the root. 

You want MTR when the qualification of the packet is the flow as opposed
the destination. Say the address of the metering application in the
Internet is anything and cannot be aggregated within the prefix
advertised by the metering root. A meter sending a metering packet will
flag it 'meter' so it follows the 'meter' default tree towards the
metering edge router whereas general traffic can be flagged as 'user' to
follow the tree that leads to a Home backbone and gateway.

I hope it's clearer now,

Pascal