Hi: Maybe we should be more explicit on what we assume from the mesh-under when there is a mesh-under. In particular what we expect as multicast routing from that L2 mesh-under service. If we make no assumption then we implicitly accept that plain flooding/pruning is also a supported option to carry L3 multicast. And I would not base ND support on that.
Pascal >-----Original Message----- >From: Eunsook "Eunah" Kim [mailto:[EMAIL PROTECTED] >Sent: jeudi 13 décembre 2007 09:15 >To: Carles Gomez Montenegro >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Issue of the week: Charter finalization > >Hi Carles, > >My thought is inline; > >>[....] >> > 3a "Routing requirements" (which needs its own milestone >entry) has >> > a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. >> > During the RL2N BOF, a similar document was proposed as a >result of >> > the RL2N-followup WG to be formed. We need to understand whether >> > the two documents (the 6lowpan one and the rl2n++ one) are >> > sufficiently different or whether we simply need to >cooperate on one >> > document, which would then have to include the 6lowpan-specific >> > aspects including mesh-under. >> >> We believe, at least at this time, it might not be necessary having >> two different routing requirements documents (one from RL2N and one >> from 6LoWPAN). Since LoWPAN scenarios are a subset of those >considered >> by RL2N, at least there should be an RL2N requirements >document, which >> should address the requirements for 6LoWPAN. If RL2N >requirements were >> too broad for 6LoWPAN, then a routing requirements document for >> 6LoWPAN would make sense. >> > >[E] Carles, as you already know, RL2N focuses on 3 scenarios >at this moment based on multiple PHY/MAC condition. I believe >that 6LoWPAN needs its own routing requirement narrowing down >the scope of the document as 6LoWPAN specific, including its >very unique node characteristics. I think that RL2N can use >the input as one of the area where RL2N solution will be used. > >> > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. >> > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" >> > might provide a basis, but we need more input, in particular from >> > implementors of each of these scenarios that we actually >want to use >> > as use cases. >> >> We can contribute. We have developed applications for home >automation, >> healthcare and city management environments. >> > >[E] I think the current "application space" documents contains >home automation and healthcare. I think the doc need to have >deeper depth by collecting experiences like you did. It must >be great to work together. > >-eunah > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
