Re: WGLC for BFD Multipoint documents (last round)

Greg Mirsky <gregimirsky@gmail.com> Fri, 02 February 2018 03:23 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 027F912EBD0 for <rtg-bfd@ietfa.amsl.com>; Thu, 1 Feb 2018 19:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 n6nU6fV_-R_J for <rtg-bfd@ietfa.amsl.com>; Thu, 1 Feb 2018 19:23:30 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 4D52712EBC2 for <rtg-bfd@ietf.org>; Thu, 1 Feb 2018 19:23:30 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id v188so29353532lfa.11 for <rtg-bfd@ietf.org>; Thu, 01 Feb 2018 19:23:30 -0800 (PST)
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=FIiz839k6OPE++6GYHsBSMdx7cj5jRIcaLr6J5N5FI4=; b=cytqTdkxAaRLo6kvygxfw4NyB/7qqelhIc7iuiCpVOg5IHBW7QE8Z6YmjIQvCIhQra eIzvg3T54iFmdtlrsguV+CITvBl5uVm+Otl2JS41iDE6+OgYI7lyaebvFnKm537t0zOz nLRtVBaRhj/WsqOKiiIIX7E+YIu8JRKGOcwdqI7jxlmp7YB+NFzcmInMsYKUJg+Rdd8k 3dj5hxIeYcdWP66r/pcmBwD4o7k1/JBYVOlcq5jf01LaX0OGPNMjYiv2PPUS0drrSZOJ bywtDmy+cR+oG2UYLNOyY4opu4jHwK3xv77K6R443BHO53tzp02g8/yM2L7YtFhK/PHF N42w==
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=FIiz839k6OPE++6GYHsBSMdx7cj5jRIcaLr6J5N5FI4=; b=Njx8gkz/CrDiN8oU7/jKpJMLmJY4YPahLKomkZUzjvB2WsHr33kHjzhSUYKOUeXJbo 1bGyK5OrZ9egWtuPO6gO9bbd4pbjrYKMvnKWsFeMbP6FDfWyKX3rBzASI2VdMEVRsKjD JEkwseRIrtC2ubqjdvpwc2QMUbyU+uFWouS2VT+9ZhcR3DxvtCfCqxzxJA/qgNJkwmwN O2CmaHYsajmQWSMO60Z1Hcw18A+41dLs20k8dqDco3RYFq4SPROvED9pu9gHYVwkbNbb QBzCJXQ2bhMwFPxDrAYjvhtEil68eV0dHoPm9jAWO2/1ksFvbm2DBEq7Uzr3w5l1WaJK jDEg==
X-Gm-Message-State: AKwxytdsb5AOpos3HIU+1p4NtHQ8X9Fsd0VVKkiiLCNiCY9gKA5n5FnJ ouO3ngdL8VYITL4OTlyn0n7UFpMnvYwmOWBbLjo=
X-Google-Smtp-Source: AH8x227TSAM1Kuf2jRUHE9DwipaOY4Z57Dbv3rKol6VRqIy3T/5Kl74Ibb5R/ljC4hJvf7McgSBXNn0Df+fc4D7M9Qg=
X-Received: by 10.46.118.18 with SMTP id r18mr22061249ljc.11.1517541808407; Thu, 01 Feb 2018 19:23:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.83.91 with HTTP; Thu, 1 Feb 2018 19:23:27 -0800 (PST)
In-Reply-To: <B5EA7CAD-36D4-470F-9A8D-4C5FE58E4C29@cisco.com>
References: <20171213172443.GC8708@pfrc.org> <CA+RyBmX6PHczvwEzc4UNqBioK8qv=wTfyeHg9j04EJNe1Uv0wA@mail.gmail.com> <746F74E2-7DFC-41A7-879F-4054CF95475C@cisco.com> <CA+RyBmWqGPTkBek+a0N+BaFr9QZ+xEKvWT5oRxPBuhFsQcizcw@mail.gmail.com> <38B53F72-66B9-4E8F-8BCE-C28A2C283D38@cisco.com> <20171219160537.GH8708@pfrc.org> <CA+RyBmWQTH9N9cCOHJ_9BgvfDGLGFgrsKrMj8mmqGm-V=5KLSw@mail.gmail.com> <20171220171322.GE8708@pfrc.org> <7C073038-8E7D-4735-82A4-97592AA9B34B@cisco.com> <CA+RyBmXanVpKKmyXP9+yuh4z2H4qAeN4jH2xEMx7ddiSHViV3g@mail.gmail.com> <DB3B0F10-4BD8-4096-8875-2E476064E77A@cisco.com> <491F0297-F2AB-4377-A013-1050FDBBB709@cisco.com> <CA+RyBmVXO0o09k-DYY69E2sKdKiU5YBf-h=PnBgerx+HF=ryfg@mail.gmail.com> <44B4B608-7A2B-4E95-A5F7-116896C57028@cisco.com> <0714A770-BF3F-4EF8-A302-A478439A5B13@cisco.com> <5F69E3D1-19E1-45F7-926D-61449E1F09B2@cisco.com> <CA+RyBmWMwom+2=jWHfvSr9AG=WPCnhYJ6uC9HVonVFh9McaysQ@mail.gmail.com> <E14FF8C0-082B-4D52-89F6-0CBAF9CD4181@cisco.com> <CA+RyBmUOpBgVho0SPsp9FB=ymFV29q_2EY2k8uOf-O4gfpTmyw@mail.gmail.com> <CA+RyBmXs_gRjeUk9gx0653WkvjDfztD-cgNw=mNX+66Whj_AFw@mail.gmail.com> <639B40D7-F79B-4546-93B3-55812C880217@cisco.com> <CA+RyBmUEG2L4ExWRCvLYVMs=BL5OsGRpfD0a9RLEvu+4Avhy9A@mail.gmail.com> <E816D829-7F6D-478A-9DE6-F5C5A177B981@cisco.com> <CA+RyBmUeJi5Rttr+5PiNUBEo1cr10pvcg=twC3Biz+c6xT7iGQ@mail.gmail.com> <28FBFF19-27FD-41DB-A0CF-29DC3CED119A@cisco.com> <CA+RyBmVh_uKZ8rT+03YhhF4W6qiDBRmeK9BtbUEo_ZuTdzkfBw@mail.gmail.com> <A44E5437-C394-4110-9FFC-99EA06D8186D@cisco.com> <CA+RyBmVNU6bt2KVw+=xsFU0J3fmoBNX9QP8GF+eCbPzbyWTSjg@mail.gmail.com> <7F1C8A95-18DE-42D0-9DF5-A6920ED4029F@cisco.com> <CA+RyBmXyT4UbfP_y7KuuoABp1TQ5db2x_R-4az-bGP=7d2ssGQ@mail.gmail.com> <F9C80743-5159-4D5E-9B33-54E0F2160FC6@cisco.com> <CA+RyBmWHyG8TRA2DbSd+mK6wK8Odc+sERAguj7tG6sCJQcyrTg@mail.gmail.com> <B5EA7CAD-36D4-470F-9A8D-4C5FE58E4C29@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 1 Feb 2018 19:23:27 -0800
Message-ID: <CA+RyBmUKPH_WQZGz4z-UHQcf-pSVd+tC7PFVXiHgYCyA-=xPdA@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="f4f5e80762f06c0b4f0564323cae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GgodseY1_ISIGr4cNSUww9xx7Yk>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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, 02 Feb 2018 03:23:34 -0000

Hi Reshad,
thank you for your patience and support.
To address your questions a) and b) we may recommend that an implementation
creates MultipointTail session only if provisioned with My Discriminator
value for the given pair of MultipointHead and multicast tree via
out-of-band control or management plane. Discussion of exact mechanisms is
outside the scope of this document. And then the text will continue to
discuss measures for implementations that create MultipointTail session
dynamically for any known combination of head and multicast tree that has
Multipoint BFD enabled.

Regards,
Greg


On Wed, Jan 31, 2018 at 6:44 AM, Reshad Rahman (rrahman) <rrahman@cisco.com>;
wrote:

> Hi Greg,
>
> Thanks for addressing the changes so promptly. I’d like to hear from the
> WG on the 2 security concerns below, i.e. whether they need to be addressed
> and if yes, then how. I believe if we address a) below we also address b)?
>
> Regards,
> Reshad.
>
> : a) We should have the ability, e.g. via configuration, to prevent the
> number
> : of MultipointTail sessions from exceeding the number of expected streams.
> : Otherwise 1 misbehaving head could use up all the MultipointTail session
> : resources on a tail.
> : b) A misbehaving head which changes My Discriminator for a MultipointHead
> : session will cause tails to create many MultipointTail sessions
> (4.13.2). We
> : should consider adding a check to see if we have a MultipointTail session
> : based on source address and the identify of the of the multipoint tree
> with a
> : different discriminator?
>
> 7.  Security Considerations
>
>    The same security considerations as those described in [RFC5880]
>    apply to this document.  Additionally, implementations that create
>    MultpointTail sessions dynamically upon receipt of Multipoint BFD
>    Control packets MUST implement protective measures to prevent
>    infinite number of MultipointTail sessions being created.  Below are
>    listed some points to be considered in such implementations.
>
>       If a Multipoint BFD Control packet did not arrive on a multicast
>       tree (e.g. on expected interface, with expected MPLS label, etc),
>       then a MultipointTail session should not be created.
>
>       If redundant streams are expected for a given multicast stream,
>       then the implementations should not create more MultipointTail
>       sessions than the number of streams.  Additionally, when the
>       number of MultipointTail sessions exceeds the number of expected
>       streams, then the implementation should generate an alarm to users
>       to indicate the anomaly.
>
>
>
> Katz, et al.             Expires August 3, 2018                [Page 16]
>
>
> Internet-Draft         BFD for Multipoint Networks          January 2018
>
>
>       The implementation should have a reasonable upper bound on the
>       number of MultipointTail sessions that can be created, with the
>       upper bound potentially being computed based on the number of
>       multicast streams that the system is expecting.
>
> On 2018-01-30, 10:23 PM, "Greg Mirsky" <gregimirsky@gmail.com>; wrote:
>
>     Hi Reshad, et.al,
>     I've uploaded the new version of the draft:
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>     This draft is a work item of the Bidirectional Forwarding Detection WG
>     of the IETF.
>
>             Title           : BFD for Multipoint Networks
>             Authors         : Dave Katz
>                               Dave Ward
>                               Santosh Pallagatti
>                               Greg Mirsky
>             Filename        : draft-ietf-bfd-multipoint-13.txt
>             Pages           : 18
>             Date            : 2018-01-30
>
>     Abstract:
>        This document describes extensions to the Bidirectional Forwarding
>        Detection (BFD) protocol for its use in multipoint and multicast
>        networks.
>
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-bfd-multipoint-13
>     https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-13
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-13
>
>     Will respond to your comments on the Active Tails shortly.
>
>     Regards,
>     Greg
>
>
>     On Mon, Jan 29, 2018 at 11:47 AM, Reshad Rahman (rrahman)
>     <rrahman@cisco.com>; wrote:
>     > Greg, these changes are good with me.
>     >
>     >
>     >
>     > Regards,
>     >
>     > Reshad.
>     >
>     >
>     >
>     > From: Greg Mirsky <gregimirsky@gmail.com>;
>     > Date: Monday, January 29, 2018 at 1:04 PM
>     > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
>     > Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas
>     > <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
>     > Subject: Re: WGLC for BFD Multipoint documents (last round)
>     >
>     >
>     >
>     > Hi Reshad,
>     >
>     > nits fixed and the new text below:
>     >
>     > OLD TEXT
>     >
>     > A number of values of the state variable are added to the base BFD…
>     >
>     > NEW TEXT
>     >
>     > A number of new values of the state variable bfd.SessionType are
> added to
>     > the base BFD…
>     >
>     > Would you accept this update?
>     >
>     >
>     >
>     > Regards,
>     >
>     > Greg
>     >
>     >
>     >
>     > On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>;
>     > wrote:
>     >
>     > Hi Greg,
>     >
>     >
>     >
>     > Section 4.2. s/The head has a session of type MultipointHead Section
> 4.4.1/
>     > The head has a session of type MultipointHead, as defined in Section
> 4.4.1,
>     > /
>     > Section 4.4.1. “A number of values of the state variable are added
> to the
>     > base BFD…”. That sentence needs rewording IMO but maybe I’m just
> missing
>     > what it’s trying to convey.
>     > Section 4.6. s/Active role , / Active role, /
>     > Section 4.10. “MUST send packets with P bit set.”. Did we agree on
> “MUST
>     > send packets with the P bit set.”?
>     >
>     >
>     >
>     > Regards,
>     >
>     > Reshad.
>     >
>     >
>     >
>     > <snip>
>     >
>     >
>
>
>