Re: New Version Notification for draft-pfister-6man-sadr-ra-00.txt

Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 03 March 2015 20:55 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C550E1A8939 for <ipv6@ietfa.amsl.com>; Tue, 3 Mar 2015 12:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 wAKzNgKn2BIQ for <ipv6@ietfa.amsl.com>; Tue, 3 Mar 2015 12:55:52 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DD91A1BA5 for <ipv6@ietf.org>; Tue, 3 Mar 2015 12:55:52 -0800 (PST)
Received: by lbvn10 with SMTP id n10so39893694lbv.4 for <ipv6@ietf.org>; Tue, 03 Mar 2015 12:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ks4DOrCQTJMZ8zpotdOnq8vQiCWVvv9Jw7ffpdTAI/Q=; b=sUzd8pK/QyasZzitr1NqctZjOkpUARsdJlPzvGDif5JnjA+beuw7a/OWrjFweRrFO9 sgcWzsQvkGNXUccul7/xyMLgy6BRUPEBvBSbOnDR/o+CBKHUYY/0rz1bqu8xapXd7jYI 6dCye319mVI8Psmv58QG2ZFWSYEn8TARX4FH9XFGltC83W22oHPA8rH5ZfCHPro/EWMH mg9rHIB8YnSv9krFaNY/QrDjLDDwm037xPxx7qcx+hOAUHnPo5VcbFkHsccdqzXfXiXN vL5WcbLsMsZjrTFbpe3CFd/Le3/dumpR85VAp0Vt2Rjr96XuzXcjpStOUSR939HRhyI6 iUAQ==
MIME-Version: 1.0
X-Received: by 10.152.37.69 with SMTP id w5mr621832laj.15.1425416150754; Tue, 03 Mar 2015 12:55:50 -0800 (PST)
Received: by 10.114.24.135 with HTTP; Tue, 3 Mar 2015 12:55:50 -0800 (PST)
In-Reply-To: <286938BC-25B8-4412-BAE5-E842B7C6F0D1@darou.fr>
References: <20150227122103.13200.78821.idtracker@ietfa.amsl.com> <2F64C09E-D05B-4E20-A87A-2D4C7EED8FB9@darou.fr> <CAC8QAce4FTaJ=L37PZBdBHkBOZLTBa1TSH5LxcKXmH4ykjjq=Q@mail.gmail.com> <286938BC-25B8-4412-BAE5-E842B7C6F0D1@darou.fr>
Date: Tue, 03 Mar 2015 14:55:50 -0600
Message-ID: <CAC8QAcef8ufRuxkc++ZktjjtMQQY1ZM-t8TWZVq4mZT0dZiXbg@mail.gmail.com>
Subject: Re: New Version Notification for draft-pfister-6man-sadr-ra-00.txt
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Pierre Pfister <pierre.pfister@darou.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/8l5nQJLwmUb3rNa4a9dRdBur4eE>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2015 20:55:53 -0000

Hi Pierre,

On Tue, Mar 3, 2015 at 9:34 AM, Pierre Pfister <pierre.pfister@darou.fr> wrote:
> Hello Behcet,
>
> With two drafts targeting the same purpose, it looks like we have a real
> beauty contest here !

No, there are more issues.

>
> We could combine them indeed. But ‘combining’ requires us to identify what
> should be kept and what should be removed from each document. For that
> purpose, I think it might be helpful to have some feedback first. Or at
> least try to comment each other’s proposals.
>
> The following is not a full review, but just a few things that came to my
> mind while reading your document.
>
> - You say homenet requires the option you define with prefix and source
> address. I don’t understand what that has to do with homenet.
> Actually, I don’t really understand the purpose of the ‘Route Prefix with
> Source Address option’ at all. You already have the two other options
> enabling what we want.
>
> - I wonder why we would want 8bits metric in the RA. RFC4191 has only 3
> router preference values. Are you thinking about a particular use for it ?
>
> - This part bugs me:
>
> the hosts with 3-4 interfaces or
>    links can be easily configured by a single router advertisement
>    message carrying the options defined here.
>
>
> If a host has 4 interfaces. It is likely to be configure by at-least 4 RAs.
> Unless there is no router on some link.
>
> - We clearly have chosen two different designs. You chose to have 3
> different new RA options while I chose to have one new option, and a new
> flag for backward compatibility with RFC4191. How does your proposal
> interacts with RFC4191 ? Why do you think it is better to use these 2 RA
> options instead of the single option I am proposing ?
>

Thanks for these comments.

However, the above text existed in draft-sarikaya-6man-next-hop-ra-04
which was published on December 8 and partly in reply to your comments
on the list. Almost 3 months passed since then.
I had also called for co-authorship. I don't remember receiving any
request from you.

If it is beauty contest, we could have made the solution more
beautiful at least to you as

Beauty is in the eye of the beholder
right?


>
>
> I would appreciate if you could give a read to my document and tell me the
> things you dislike about it. I mean, if you don’t dislike anything, there is
> no point ‘combining’ the two drafts.
>

Well, at this moment, I am soliciting to get the analysis draft
draft-sarikaya-6man-sadr-overview-05 which I published on Feb. 20
accepted as WG draft, rather than working on the solutions.

I presented the drafts twice and we had very good active email
discussions and I believe this is the time for the analysis draft to
go for an adoption call.

 This draft will allow 6man to decide:

a) everything works, no solution work is needed, as in Section 5.1

b) Some solution work is needed, e.g. for SADR which has  wider
application areas, as in Section 5.2

c) More solution work is needed, e.g. next hop which has a narrower
application and SADR as in Section 5.3.

Regards,

Behcet