Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO

"Reddy, Joseph" <jreddy@ti.com> Tue, 26 April 2011 15:50 UTC

Return-Path: <jreddy@ti.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129DE0681 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 08:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+qTqM2vCpGW for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 08:50:56 -0700 (PDT)
Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by ietfa.amsl.com (Postfix) with ESMTP id B51BCE07CC for <6lowpan@ietf.org>; Tue, 26 Apr 2011 08:50:56 -0700 (PDT)
Received: from dlep35.itg.ti.com ([157.170.170.118]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3QFoodu012381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500
Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3QFooin027632 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500 (CDT)
Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3QFooep018429 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500 (CDT)
Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Tue, 26 Apr 2011 10:50:30 -0500
From: "Reddy, Joseph" <jreddy@ti.com>
To: "6lowpan@ietf.org" <6lowpan@ietf.org>
Date: Tue, 26 Apr 2011 10:50:27 -0500
Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
Thread-Index: AcwD0PYDKjtLm146QWGGLacaxGgn5AAWH10w
Message-ID: <DE92901D19672647B9ADB0CB499498650508C0F5AC@dlee02.ent.ti.com>
References: <mailman.44.1303794928.15813.6lowpan@ietf.org>
In-Reply-To: <mailman.44.1303794928.15813.6lowpan@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 15:50:57 -0000

 

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 <samita.chakrabarti@ericsson.com>
To: Erik Nordmark <nordmark@sonic.net>et>, "Pascal Thubert (pthubert)"
	<pthubert@cisco.com>om>, "nicolas.riou@schneider-electric.com"
	<nicolas.riou@schneider-electric.com>
Cc: 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Fwd: Re:  "Advertize on Behalf" flag in ARO
Message-ID:
	<16D60F43CA0B724F8052D7E9323565D71B8FAF2786@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
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan