--- Samita Chakrabarti <[EMAIL PROTECTED]> wrote:
> > Hi Gabe, > > Thanks for your response. > > I have a few questions regarding the routing solutions on Lowpan: > > - Are we going to go ahead with lowpan-aodv draft? > If so, I'd like to pass some modification requests that we have > discovered during an exercize of its implementation. > > - Are we going to merge lowpan-aodv and LOAD draft? > - If yes, then we need to review this draft seriously. It is RFC3561 > based. As Daniel mentioned, LOAD is what we're working on going forward. > > IMHO, neigther AODV-bis nor RFC3561 are quite suitable for lowpan routing; > It'd be much nicer if we come up with a lowpan routing protocol based on > DYMO/AODV/AODVbis flavors. It is unlikely that lowpan tiny devices will > route packets for the regular internet, hence the modified standard version > protocol makes more sense for the lowpan world. I believe an adapted protocol is the idea, yes. I think inventing something new won't happen (at least not in this WG, it might in MANET or something else in the routing area). But I believe it should be ok for lowpan to adapt an existing protocol. Perhaps not all fields are needed. Perhaps not all features are needed. The current drafts already started the adaptation because I don't believe they include all the bells and whistles in aodv or dymo, right? I guess we're in agreement. > I am not quite sure how it is useful to have lowpan-aodv, lowpan-dymo and > lowpan-aodvbis etc. as opposed to one draft that covers lowpan concerns > and is based on parts of AODV/AODVbis and DYMO features. That way we will > not be tying lowpan's fate on success of the corresponding protocols > through the IETF process. But I may be too optimistic. Again, these protocols are already adaptations of any of the above, right? So I'm not sure they'll create hard dependencies. In other words, within the LOAD document, AODV should perhaps appear as an informational reference. It is not a normative reference because implementing AODV per the RFC is not a pre-requisite for this to work and be interoperable. Actually, implementing it won't help lowpan meshing, cuz AODV per the RFC uses UDP as transport, whereas LOAD (or any other mesh for lowpan protocol) uses the lowpan adaptation layer as transport. So one could argue that the AODV RFC (or AODV-bis draft) is not normative, so it wouldn't tie LOAD in the publication process. But we're *very* far from that problem so I wouldn't worry about it yet. -gabriel _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
