I agree we should move forward with this draft without adding additional 
features. 

-Joseph


----------------------------------------------------------------------

Message: 1
Date: Mon, 25 Apr 2011 15:00:04 -0400
From: Samita Chakrabarti <[email protected]>
To: Erik Nordmark <[email protected]>, "Pascal Thubert (pthubert)"
        <[email protected]>, "[email protected]"
        <[email protected]>
Cc: 6lowpan <[email protected]>
Subject: Re: [6lowpan] Fwd: Re:  "Advertize on Behalf" flag in ARO
Message-ID:
        
<16d60f43ca0b724f8052d7e9323565d71b8faf2...@eusaacms0715.eamcs.ericsson.se>
        
Content-Type: text/plain; charset="us-ascii"

 
Hi Pascal and Nicolas,

I am in agreement with the following reasons (by Erik) as to why we don't want 
to add the TID/sequence# in the ARO message. As discussed many times in the wg 
that the goal of this 6lowpan-nd work is to provide simple optimized neighbor 
discovery functionality of the low-power IPv6 network. This is independent of 
routing protocol functionalities such that it works with multiple routing 
protocols on top of it.

If RPL  or other routing protocol needs a specific information to pass around, 
it could do that as an option aka future extension of 6lowpan-nd. We already 
decided/presented in the Prague wg meeting and the consensus was to  move 
forward with the 6lowpan-nd as it is plus the editorial changes discussed at 
the meeting slides.

Besides the dependency of 6lowpan-nd on a specific routing protocol( such as 
RPL or backbone routing), I have a major concern including a feature like 
sequence# in the ARO message at this point for supporting a corner case without 
knowing its larger impact.

As for MIP, I am not sure if we want to run MIPv6 as it is in the 6lowpan 
network. Our design goal for 6lowpan-nd-basic is to provide the core 
functionality and then build things on top of it on a modular basis as needed.
Please help in proceeding toward the basic 6lowpan-nd work done first.

Best regards,
-Samita




| A host isn't aware of whether the routers speak IS-IS or OSPF, so why do the 
hosts need to be aware of RPL by | passing some TID around?

> I think ND has the same need as MIP for a TID == Sequence # . We know 
> of MIP; We know of RPL. We know of the backbone router operation. We 
> know we'll need the TID and we know exactly why. I think we should 
> have it in the 6LowPAN ND spec right away to avoid interop issues when 
> we add RPL and BR operations.

| I don't see a need in 6lowpan-nd for a TID; the protocol works fine without 
it.
| I think RPL needs to be improved to deal with reality. Isn't there a desire 
for RPL to handle 4861 hosts? | | | Those would never know about a TID.

|   Erik

_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to