Re: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets

Abdussalam Baryun <abdussalambaryun@gmail.com> Fri, 26 September 2014 13:55 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7C1A87E1 for <manet@ietfa.amsl.com>; Fri, 26 Sep 2014 06:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jTzMn0jTr0s for <manet@ietfa.amsl.com>; Fri, 26 Sep 2014 06:55:43 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDFF1A87B8 for <manet@ietf.org>; Fri, 26 Sep 2014 06:55:42 -0700 (PDT)
Received: by mail-yk0-f174.google.com with SMTP id q9so3444190ykb.19 for <manet@ietf.org>; Fri, 26 Sep 2014 06:55:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cv8hFYRMzuxLtLjWyADyiVY6tAPuXLuS3E/zKWbpR7A=; b=gc5ji06bMYkisOnza63HRubHtlMRk1xznUDDVBH45HHfTj89Dyc7UEtjb0YKJFU+Cz wJqY6AjUYOQQ77hjjSZPx3sXwNEtJWrLfjyJ5HMM8pUjZ/b4PLORRNM7tiDLbaTHy0QG etHXO/jFMaG9jkQ7Tx+yI5CHmt9JcqqZum4kSVaVe0pbESLvEHWHkIEBaLVvs2P+CHRD WLgsV5dfD/7bHMprKBZY7wTzqLacO99JHii3s/M4r6y/hn5sU8tp6h3p+FyuDMZkuNe9 Yj1TwSnS9mFtW1KtQiY7sBCsn6LVv+MtKUw5HEi3/fyoubR+Um/UzLQW/24R4EFx1jN7 NKPA==
MIME-Version: 1.0
X-Received: by 10.236.90.78 with SMTP id d54mr1034580yhf.182.1411739742017; Fri, 26 Sep 2014 06:55:42 -0700 (PDT)
Received: by 10.170.150.194 with HTTP; Fri, 26 Sep 2014 06:55:41 -0700 (PDT)
In-Reply-To: <A34255DF-DA0F-47B9-B602-C2BF749B2B2F@cisco.com>
References: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> <C83A8919-4D6A-4B64-9695-8A60CFA45908@gmail.com> <CADnDZ88rmtEHyLheZKrUNXaoBt42A2Ty1RQ6TeShqGg98qPDzw@mail.gmail.com> <A34255DF-DA0F-47B9-B602-C2BF749B2B2F@cisco.com>
Date: Fri, 26 Sep 2014 15:55:41 +0200
Message-ID: <CADnDZ8-KZRu8NBED+RG9dMQWGA=8NcLrWhaqnju5OGk7W-bDUA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
Content-Type: multipart/alternative; boundary="20cf300e5531d69fad0503f84590"
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_X00syy6iR90MisQcFAYwwp34vA
Cc: Christopher Dearlove <christopher.dearlove@gmail.com>, "manet@ietf.org" <manet@ietf.org>, "draft-ietf-manet-olsrv2-multitopology@tools.ietf.org" <draft-ietf-manet-olsrv2-multitopology@tools.ietf.org>
Subject: Re: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 13:55:44 -0000

Hi

On Sunday, September 21, 2014, Stan Ratliff (sratliff) wrote:

>  Abdussalam,
>
>  On Sep 21, 2014, at 7:53 AM, Abdussalam Baryun <
> abdussalambaryun@gmail.com> wrote:
>
> Section 11 and subsection 6.8 need more specification details for routing
> maintenance.
>
> On Saturday, August 23, 2014, Christopher Dearlove wrote:
>
>> ....
>>
>> Yes, the draft does describe creating multiple routing sets. See Section
>> 11. If familiar with OLSRv2, that's all you need - because OLSRv2 describes
>> how a Routing Set is calculated and when it needs to change.
>
>
>  Already seen section 11 when reviewed but is not enough. Regarding
> RFC7181 (which section refers to) it is only for single topology, so for MT
> we need a fresh maintenance paragraph at least. In subsection 6.8 it does
> not describe how is the separation. In section 11 it does not describe how
> the calculation separates routing sets. The is a need to add an element in
> routing set for metric type. All maps are done with metric type
> reference, but in the routing sets there is no element for metric type or
> reference.
>
>
>  I want to reinforce what Chris Dearlove said in another email. The text
> above implies (at least to me) that you have a specific deployment scenario
> in mind, and that when looking at the text of the draft, you conclude that
> your scenario won't work. If that is the case, describe the scenario
>


That is not the case, the scenarios are general purpose of MANET or as
RFC7181. The case is the draft reader did not understand and is discussing
to clarify the issues. The reader is referring to texts in the draft
related to updating routing sets. Generally, the case is that some of my
questions are not getting clear answers. It is good that reader reviewing
and commenting on draft and sharing his/her understanding
or misunderstanding. I want to implement the work then will think about
scenarios.



> - I'm not able to follow your concerns, above some vague notion that "this
> won't work". Without the necessary detail, I can only conclude that
> consensus exists to progress the draft, and you are "in the rough".
>

 I never said it does not work. I want the draft to be clear to readers how
protocol works. Does your message mean stop discussing because your in
the rough? Or stop because you have no scenario detail (usually my scenario
is the draft scenario). The WG is small in size so maybe 10% participants
don't understand the work. The IETF is not about only consensus, but about
publishing readable work that full community can understand and implement.

AB