Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09

Greg Mirsky <gregimirsky@gmail.com> Fri, 29 June 2018 17:17 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC53130DDD; Fri, 29 Jun 2018 10:17:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wAzVsUTzVRal; Fri, 29 Jun 2018 10:17:03 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 0E030130DDB; Fri, 29 Jun 2018 10:17:03 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id v15-v6so7880533ljk.5; Fri, 29 Jun 2018 10:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DZJUjMLZAsMADSRW4EoJRwWcnwbcjCTnJ1wFeJCydi8=; b=rfAE1CzlPQIxrSLydiCjwNx97k0PTEEHebVC0FJkaOxa66LJ3//oIt7KgxwzI1hP3Y GhyfjvAsrx4mbQTA4XMO7kT4uSHJAlw2ATdQ5JOC6fdRjfBZQD3CDFHvwgTFct2ddcp0 YES0AfRNcO/jX5S3kaJe8+cMlbPkxgAlKvUq/gvBLJzoTajSjV7zpgmN15J+R9t1TMWJ jQnJ/XQdUy5otTCUGhMXJIK6UZWr3k3u4to0kQp66PcMsYCkMWnbRW50uloEx0bElENz J/yO3AcNtVYzJqpbEv+xUwjOo7nhoxUNKSjfl1dlwXXb3IE9KxDdQMBzEfz4suWOwRpf AfcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DZJUjMLZAsMADSRW4EoJRwWcnwbcjCTnJ1wFeJCydi8=; b=kOEm67XYrj4/APpimJdCIdOVbEPkKDbz6f+2LznFDPdU7T0GRiA/PrDEb21R7spbTU ua3PzS3AgbZsBvERtaLITD7zPETOfWeGIL1fsXC12pG4O+N3va1Dy9vVsfRwvYzsWqUH lhUf77wxSTA+pMyBRCCEF246+LOWM9ltTOoQiHrv5EpE59Pns23aOFh3YuH9MOBn72zh be42Y6oqlBXGpfKeTRCNv3IRDxIjmSK5ARBf4nUAWfwhQaj8+kFB+FgJcVfPcBeTHe17 NMciW9Kn9vVAjpUTND74Pc+ARfXPP2L9NUNxFbokGMjR3KOelrbkRzUUKRByXT2YlT0j NPaA==
X-Gm-Message-State: APt69E3RD5weUQZG/3gEUYk5EwruhMW7QpdLqrNiHGtowl7XeBrseuxP ru0cIMrT5e3nqXm2wAgyTZ+ARfj++541q2L7bfc=
X-Google-Smtp-Source: ADUXVKKzS3rYcPaYHgydzzEXQ0KTt4mCeM4KzAwFvvv6ygv0r0V424CMbnaguQ/ZhMiFRrxt05KGC8uYckQDAQbyzYM=
X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr10591550ljd.72.1530292621263; Fri, 29 Jun 2018 10:17:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 10:17:00 -0700 (PDT)
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0764D4@sjceml521-mbs.china.huawei.com>
References: <153021423641.18488.4659084638238812446@ietfa.amsl.com> <CA+RyBmU_zRdtSTbogU_4As-YLhhM9OYKWSSgN190cSwLkLzwCQ@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B0764D4@sjceml521-mbs.china.huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 29 Jun 2018 10:17:00 -0700
Message-ID: <CA+RyBmU=ipMLUSiEDFDVAtNUu0j=U8XRp3pNoBNNMJak=tYK1Q@mail.gmail.com>
Subject: Re: Genart last call review of draft-ietf-bfd-multipoint-active-tail-09
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, IETF list <ietf@ietf.org>, "draft-ietf-bfd-multipoint-active-tail.all@ietf.org" <draft-ietf-bfd-multipoint-active-tail.all@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000017c7e6056fcb04bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Jv3CAMyXZadAXLsAN4HFkW0bNTk>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 29 Jun 2018 17:17:15 -0000

Hi Linda,
thank you for the question. Always happy to discuss the technology.

If the head is required to know the state of the set of the tails, then
using p2p BFD session between the head and each of such tails may be the
right solution. But it may be challenging to ensure that the unicast path
from the head to each of the tails in that set is co-routed with the
multicast path used to transport the data. The use of p2mp BFD does ensure
that the BFD control packets transmitted by the head follow exactly the
same path as data packets of the monitored flow.

Regards,
Greg

On Fri, Jun 29, 2018 at 9:51 AM, Linda Dunbar <linda.dunbar@huawei.com>
wrote:

> Greg,
>
>
>
> Thanks for the reply.
>
>
>
> It might be too late to ask this question, I am curious if the head-end is
> aware of the list of end points, what is wrong if they just use unicast BFD
> to each of them? Multicast-BFD seems requires more support of the network,
> isn’t it?
>
>
>
> Linda
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Friday, June 29, 2018 11:45 AM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>
> *Cc:* gen-art@ietf.org; rtg-bfd@ietf.org; IETF list <ietf@ietf.org>;
> draft-ietf-bfd-multipoint-active-tail.all@ietf.org
> *Subject:* Re: Genart last call review of draft-ietf-bfd-multipoint-
> active-tail-09
>
>
>
> Hi Linda,
>
> thank you for the review and your kind words, much appreciated.
>
>
>
> If an end-point during the p2mp BFD session never responded to the head's
> multicast poll it is unknown to the head and cannot be reported as
> "inactive tail". I can imagine that if the head has been given the list of
> the tails, then the unresponsive end-point can be reported as "inactive
> tails".
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jun 28, 2018 at 12:30 PM, Linda Dunbar <Linda.dunbar@huawei.com>
> wrote:
>
> Reviewer: Linda Dunbar
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-bfd-multipoint-active-tail-??
> Reviewer: Linda Dunbar
> Review Date: 2018-06-28
> IETF LC End Date: 2018-06-18
> IESG Telechat date: 2018-07-05
>
> Summary: clear writing of the procedure.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> Are End points that not responding considered "Inactive Tails"?  Does the
> HeadEnd report the "Inactive Tails"?
>
> Linda Dunbar
>
>
>