[Roll] Some confusions in RFC 6719 (MRHOF)

Duong Ngoc Nguyen <nduong@purdue.edu> Wed, 07 November 2012 19:55 UTC

Return-Path: <nduong@purdue.edu>
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 5F34C21F8850 for <roll@ietfa.amsl.com>; Wed, 7 Nov 2012 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yjQnbOi9B9jx for <roll@ietfa.amsl.com>; Wed, 7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub128.itcs.purdue.edu (mailhub128.itcs.purdue.edu [128.210.5.128]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6F21F87F6 for <roll@ietf.org>; Wed, 7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub022.itcs.purdue.edu (mailhub022.itcs.purdue.edu [128.210.5.22]) by mailhub128.itcs.purdue.edu (8.14.4/8.14.4/mta-nopmx.smtp.purdue.edu) with ESMTP id qA7JtI0l009756 for <roll@ietf.org>; Wed, 7 Nov 2012 14:55:18 -0500
Date: Wed, 07 Nov 2012 14:55:18 -0500
From: Duong Ngoc Nguyen <nduong@purdue.edu>
To: roll@ietf.org
Message-ID: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
In-Reply-To: <mailman.1872.1352129713.3373.roll@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.210.5.219]
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - SAF3 (Linux)/6.0.10_GA_2692)
X-PMX-Version: 5.5.9.388399
X-PerlMx-Virus-Scanned: Yes
Subject: [Roll] Some confusions in RFC 6719 (MRHOF)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 07 Nov 2012 19:55:20 -0000

As I work with MRHOF, I find some statements are not consistent that I cannot resolve by myself. I'm very grateful if someone can help me overcome this confusion.

1. Which path cost is carried in Metric Container?

Section 3.2.2 states:

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to the
   preferred parent.  The value of the cur_min_path_cost is carried in
   the Metric Container corresponding to the selected metric when DIO
   messages are sent.

==> it suggests Metric Container carries the cost through the best (i.e. preferred) parent.

While section 3.4 states:

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to its
   preferred parent.  It then calculates the metric it will advertise in
   its metric container.  This value is the path cost of the member of
   the parent set with the highest path cost.  Thus, while
   cur_min_path_cost is the cost through the preferred parent, a node
   advertises the highest cost path from the node to the root through a
   member of the parent set.  The value of the highest cost path is
   carried in the metric container corresponding to the selected metric
   when DIO messages are sent.

==> it suggests Metric Container carries the cost through the worst parent.

2. Which value is written to Rank field of DIO messsage's base object in case ETX is used?

When ETX is the metric, node must not include Metric container, thus the rank field in DIO's base object is the only information to advertise to neighbors.

Section 3.4 states:

   If ETX is the selected metric, a node MUST NOT advertise it in a
   metric container.  Instead, a node MUST advertise an approximation of
   its ETX in its advertised Rank value, following the rules described
   in Section 3.3...

==> The phrase "in its advertised Rank value, following the rules described in Section 3.3." means we would write the value of node rank (computed by rules in section 3.3) into the rank field of DIO message.

On the other hand, section 3.5 states:

   ... Once parent selection and rank computation is performed
   using the ETX metric, the node advertises the Rank and MUST NOT
   include a metric container in its DIO messages.  While assigning Rank
   in this case, use the representation of ETX described in [RFC6551],
   i.e., assign Rank equal to ETX * 128.

==> The phrase "assign Rank equal to ETX * 128" suggests that we should write value of ETX of path cost to the rank field of DIO message.

3. A possible typo.
Section 3.5 states:

   In the absence of a Metric Container, MRHOF uses ETX as its metric.
   It locally computes the ETX of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes...

==> Adding ETX of link and value of advertised rank is to compute cost of a route, not rank of a route. Rank of a route is computed by adding MinHopRankIncrease (instead of link's ETX) with advertised rank (as in section 3.3)

Sincerely thanks,
Duong Nguyen