Subject: [RSN] RL2N BOF in Vancouver

From: JP Vasseur <[email-masked]>
Date: Fri, 26 Oct 2007 14:16:24 -0400

Dear list,

The RL2N BOF has been approved for Vancouver.

I've updated www.employees/~jvasseur with the related information -  
please provide
your comments.

We're planning to have a pre-WG meeting in Boston Nov 15 with 15-20  
people
who expressed some interest in this work. Let us know if you would  
like to attend.
Otherwise, we will post the minutes of that meeting on the list.

Thanks.

JP.

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 31 Oct 2007 16:55:39 +0530

I've read the documents at www.employees/~jvasseur, and I have some comments.

As I expressed at the IETF 69, I still feel this working area is
lacking focus and not properly scoped out. I have seen very little
public discussion on the list addressing this issue.

Here are some of the questions I have about the RSN/RL2N's proposed work:

Which of the huge number of routing requirements will be
satisfied/addressed? Will both unicast and multicast routing be
handled? Will the group focus on intra-domain routing? Will both IPv4
and IPv6 be handled? Will the solutions first go to experimental RFC
or directly to proposed standard?

At this time, I would suggest that the charter scope be limited to
creation of problem statement document. If needed a companion
architecture document and/or a protocol evaluation document could also
be created.

In line with my previous comments, I think it is premature to create
milestones for the solution space, and I am not sure about the
usefulness of publishing routing requirements (especially those that
will not be addressed by the proposed protocols) as informational
RFCs. Although, I think they can be useful in forming the problem
statement.

I do think this area is very interesting, and I think that we can
identify a workable set of routing challenges to address in the
RSN/RL2N space.

See you in December,
Ian Chakeres

Unfortunately, I won't be able to attend the pre-BOF meeting in Nov. I
will wait to see the minutes.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Oct 2007 16:08:05 -0400

Hi Ian,

Thanks for your feed-back - in line,

On Oct 31, 2007, at 7:25 AM, Ian Chakeres wrote:

> satisfied/addressed?

First of all, let me make sure that we're on the same page. We first  
started by
collecting requirements for a wide set of applications, which are  
spelled out
in draft-culler-rl2n-routing-req-01. Several months ago, we decided  
to have
a narrow focus on a few use cases from which we will derive the routing
protocol requirements. You are absolutely right that draft-culler- 
rl2n-routing-req-01
contains a large number of requirements that may sometimes contradict  
each other
and we are very much aware of this. The only aim of this ID is to  
serve as a
placeholder but our effort will be to concentrate on the very use  
cases mentioned
in the charter, namely: Industrial, Connected Home and Smart Cities.  
As pointed
out during my presentation during the Routing Area meeting in  
Chicago, we would
be happy to have a solution for 80% of the problem space, we're not  
aiming at
finding solution to very exotic problems and of course we want to  
focus on issues
for which proprietary non IP solutions are being deployed as we speak.

> Will both unicast and multicast routing be
> handled?

Both will have to be handled according to some of the requirements in  
the IDs
(particularly relevant to some fairly frequent P2MP sensor  
applications for
example).

> Will the group focus on intra-domain routing?

Good point: yes, this must be added to the proposed charter.

> Will both IPv4
> and IPv6 be handled?

Another good question: IPv6 but as usual feed-back from the list are  
welcome.
Note that there are situations where finding a IPv4 solution would be  
desirable
but we should probably focus on IPv6 for the time being.

> Will the solutions first go to experimental RFC

Proposed Standard.

> RFCs.

Why wouldn't you want to publish the routing requirements IDs as  
informational
RFCs ?

> Although, I think they can be useful in forming the problem
> statement.
>

We're in sync.

> identify a workable set of routing challenges to address in the

Thanks, no need to say that we would hope to collaborate with the  
MANET WG.
The problem space is quite different but there is with no doubt some  
interesting
synergy.

> See you in December,

See you, thanks for the comments.

JP.