[Roll] [roll] #101: What purpose RIO/PIO serve in a P2P mode DIO?
"roll issue tracker" <trac+roll@trac.tools.ietf.org> Mon, 04 June 2012 14:12 UTC
Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9721F8889 for <roll@ietfa.amsl.com>; Mon, 4 Jun 2012 07:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzFpJ1-XZkHT for <roll@ietfa.amsl.com>; Mon, 4 Jun 2012 07:12:11 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47D21F8888 for <roll@ietf.org>; Mon, 4 Jun 2012 07:12:11 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1SbY0w-0008CQ-O6; Mon, 04 Jun 2012 10:12:10 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: roll issue tracker <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Mon, 04 Jun 2012 14:12:10 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/101
Message-ID: <055.51e9453239490c60e24001d3e8c729b3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 101
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: [Roll] [roll] #101: What purpose RIO/PIO serve in a P2P mode DIO?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2012 14:12:12 -0000
#101: What purpose RIO/PIO serve in a P2P mode DIO? Discussion: ----------- [Joseph1] Section 6.1: "...A P2P-DIO MAY carry one or more RIO and PIO options..." I am not sure how these options should be used by the DAG members. Later on, in 9.1, it says that "..the temporary DAG must not be used to route packets....". So what is the purpose of RIO and also PIO ? [Mukul1] The RIO would advertize to the target(s) the origin's connectivity to the specified prefix. Regarding PIO, I would very much like to allow P2P mode DIOs to carry PIOs to propagate prefixes for address selfconfiguration (i.e. have A flag set). I think we could forbid setting the R flag to one in a PIO carried in a P2P mode DIOs. Regarding the L flag, I think we could allow a P2P mode DIO to carry a PIO with L flag set subject to the following rules in RFC 6550: <...> [Joseph2] The RIO/PIO information is sent by the Origin to propagate its connectivity and prefix information. However, the route is established towards the Target. So I don’t understand why the Origin information is relevant .. [Mukul2] Here is some relevant text from Section 9.3: "A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO taking in account the metric's value in both forward and Backward directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the DRO messages travel from the Target to the Origin along a discovered route. " So, the target can certainly use a discovered route as a source route to reach the origin. The backward direction route may not meet desired routing constraints but does provide a way to reach the origin. So, it may be useful for the target to know what destination prefixes can be reached via the origin. In fact, it makes sense to allow the target to include one or more RIOs in its DRO to let origin know what destination prefixes could be reached via the target. Regarding the PIO, I think the most critical need is to allow the propagation of address self-configuration prefixes via P2P mode DIOs. These prefixes can be used not only by the target but also the other nodes that join the temporary DAG. I am not too sure about allowing PIOs with L flag set inside the P2P mode DIOs. Would certainly like to hear your views on this. [Joseph3] Thanks for the clarification. For the PIO flags, I think the settings must not contradict the RPL spec. So I would add the same restrictions here ( i.e. L bit must not be set ). [Mukul3] So I guess I would simply refer to RFC 6550 regarding how PIOs might be used in P2P-RPL. I will also clarify that the RIO would advertize to the target(s) the origin's connectivity to the specified prefix. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/101> roll <http://tools.ietf.org/wg/roll/>
- [Roll] [roll] #101: What purpose RIO/PIO serve in… roll issue tracker
- Re: [Roll] [roll] #101: What purpose RIO/PIO serv… roll issue tracker