Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Sam Aldrin <aldrin.ietf@gmail.com> Tue, 25 November 2014 01:29 UTC

Return-Path: <aldrin.ietf@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8591A6F45 for <rtg-bfd@ietfa.amsl.com>; Mon, 24 Nov 2014 17:29:19 -0800 (PST)
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 uO_FZLyy-5W9 for <rtg-bfd@ietfa.amsl.com>; Mon, 24 Nov 2014 17:29:17 -0800 (PST)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178D11A6F1D for <rtg-bfd@ietf.org>; Mon, 24 Nov 2014 17:29:17 -0800 (PST)
Received: by mail-qc0-f170.google.com with SMTP id x3so7828671qcv.1 for <rtg-bfd@ietf.org>; Mon, 24 Nov 2014 17:29:16 -0800 (PST)
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=h4sj30CkoA/U0KSmDj/hiw5db1jv3jM4X71GGENkt+E=; b=VHU9e7AYwNsXyl2ST60gWk4gffA2lGeqeJEoIrAVlRwZrw28BSH0lQ2U5d64Wk85q2 X2uUnSlVGNu0XJQAGbpfEHN9noRsv5x1EfedTkIJMCWLLHG1Qz61zGnwttpSG0ZgIswJ POD/JPhZ8s2U2bR3wUTfrPtwpULuRa+g2oPdENDcKZfyP4A0mDGknHajBVnjKksotAzf uwt56uPviiN7JbPYbozFM13RjoKukCa3Muz6xOke9/3c2d22Qra9s5wOr0o2+G+1d3/M 7OXSeWTUjKrHw0/IHX+b9L2CvBcq3nOrLJ4Rs379fSM1akh09A9mA+R952T2T5M0IHRq UQUQ==
MIME-Version: 1.0
X-Received: by 10.140.51.99 with SMTP id t90mr32994016qga.72.1416878956377; Mon, 24 Nov 2014 17:29:16 -0800 (PST)
Received: by 10.96.65.42 with HTTP; Mon, 24 Nov 2014 17:29:16 -0800 (PST)
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3943F5A1776@xmb-aln-x01.cisco.com>
References: <CECE764681BE964CBE1DFF78F3CDD3943F59FF47@xmb-aln-x01.cisco.com> <D098C403.279A9%mmudigon@cisco.com> <CECE764681BE964CBE1DFF78F3CDD3943F5A1776@xmb-aln-x01.cisco.com>
Date: Mon, 24 Nov 2014 17:29:16 -0800
Message-ID: <CA+C0YO0NV3dkf==-M+kmTu5V_wEm4K0sBjxwu6ChrtieSXX8fw@mail.gmail.com>
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
From: Sam Aldrin <aldrin.ietf@gmail.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Content-Type: multipart/alternative; boundary="001a11351efae27d6c0508a4d6f1"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oep8S319BC_0Dw4OxSSwTZwyBVE
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "manav@ionosnetworks.com" <manav@ionosnetworks.com>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 01:29:19 -0000

[resending as mailer complained, mail is too long; removed earlier content
as well)
Hi Nobo et al,

I have finally read the 'alert discriminator' document.

Keeping the solution aside, what makes it special that the use case cannot
be documented in 'use case' ID?
Irrespectively, while explaining the solution, the problem has to be
explained anyway.
But, when there is use case document, like other use cases, adding the use
case will be good, doesn't it?

I know it will only delay the use-case document, which I am an editor of
it.
Want to understand the rationale behind it. (Read emails, but don't think I
am convinced).

Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2).
I am not sure if it is indeed needed as BFD was not used so far like this.
Just a simple extension or not is different matter. Whether we should be
doing it with BFD (not just S-BFD) is more important and needs to be
discussed.
And I do not think that it should be part of S-BFD use case at this point.

cheers
sam