Re: WGLC for BFD Multipoint documents (last round)

Greg Mirsky <gregimirsky@gmail.com> Tue, 19 December 2017 22: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 BA0B012D867 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 14:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=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 VATFBrcLRUfr for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 14:17:06 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 4904F12D848 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 14:17:05 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id c19so1986503lfg.3 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 14:17:05 -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=fj/F273V7hav1yzRVwcQ7aJ4cUqDFK2t+Jk8qQh48pU=; b=Q9eneVykjUB95JZYPITI33UPRBlY98Bjk1FOsM84DLsVaYMwh75+3Y6zsW2mW7SUUl UpffZXm8XbY2WNyR5GcdWHTaCAPfljYfMs/gHfTO3yzPOtEPgxTCX39Od0oupjXpHcqX Qol0UJE3LR5I/YAykQicd+lcWcNtxav6+3yQSldMjblGZzpU+8gElBqSvlJK/bnXnR4n BzdkUPvG6kpH3BGdkLadrIHlmQvjRP00mEWvqew0OBmPH/MwVlXhk6yCCmP8hadA7nDC GLWurufyUH1gNjRAXLxkDtn5cS7H/ARZZrtqLiyuMomAGg+OWRbtAn3FdLfBoWUQ6CWI tSAQ==
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=fj/F273V7hav1yzRVwcQ7aJ4cUqDFK2t+Jk8qQh48pU=; b=KxVTgmz3jp6DIqOX8ztyucuDS5XlBIZ1INs/lDbNtfWHdoCLfJM4Cbe0KTR51Q/hCf j+RG17t0ruxWsljGcRTcDPnPUkFJPhJ+5eoh861LL4KDrd+jEEYT2FzYMsVjuJyh0LuF Hequ9z4YARLa8XX51e4SiQ4LbbAh+XYsSiRlLvW/pkjZchXUpMqmbnM42Ikz/N7maqO5 ilfBRGdWhjwgNXWD+c+SGPzGOyC/SPE9Nl6Yd4s5lcrtVRJMVkasaLU/S+7tsnGo5Sbs pE+K5BbfpY6WLRDJWGx72CnsKbL9lmLHKZIfxXYsiTFCe71tjYFTQ/+5aizolPgeK836 Lp5Q==
X-Gm-Message-State: AKGB3mJ8mZ8qkn6hadFzck+buyn9XidFpN7SLXXG1G6bVFuXcxLvwM1m Rw+nXPxI5dI3SktEnH2opvB6i2kDS5IcrdIzdcs=
X-Google-Smtp-Source: ACJfBosKnftDaUoKieUBI8ZdculSsviesVs6/Lh20U3UbQjc6gZPzi26N/YcKJQBfLNzmlRhdr0n0hegva6Z7id47fw=
X-Received: by 10.25.219.145 with SMTP id t17mr3034690lfi.73.1513721823272; Tue, 19 Dec 2017 14:17:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Tue, 19 Dec 2017 14:17:02 -0800 (PST)
In-Reply-To: <20171219160537.GH8708@pfrc.org>
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>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 19 Dec 2017 14:17:02 -0800
Message-ID: <CA+RyBmWQTH9N9cCOHJ_9BgvfDGLGFgrsKrMj8mmqGm-V=5KLSw@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/mixed; boundary="94eb2c18519a90ea750560b8d347"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/KEVfcY6jOYf_px9iUjBzUDQ4jh8>
X-Mailman-Approved-At: Tue, 19 Dec 2017 14:18:02 -0800
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: Tue, 19 Dec 2017 22:17:16 -0000

Hi Carlos and Jeff,
thank you for responding so expediently. I think we've reached the rough
consensus. Attached are the diffs for both BFD documents and the updated
copies. Please let me know if the changes being made have addressed all the
comments received during the WGLC. I'll then upload new versions.

Regards,
Greg

On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

> [Speaking as an individual contributor.]
>
> On Tue, Dec 19, 2017 at 02:20:11AM +0000, Carlos Pignataro (cpignata)
> wrote:
> > S-BFD currently specified for p2p but I don't see a reason why S-BFD
> cannot be applied to p2mp cases. So, for a BFD node that supports both RFC
> 7880 and draft-ietf-bfd-multipoint values of variables may be SBFDInitiator
> and PointToPoint. And, at some time, there will be interest to define
> behavior of the SBFDInitiator/MultipointHead and
> SBFDReflector/MultipointTail combinations.
> >
> > Thus I see this issue as name conflict that can be resolved by changing
> the name in draft-ietf-bfd-multipoint-* to something other than
> bfd.SessionType. Perhaps we can change the name to bfd.SessionTopology.
>
> I concur with Carlos.  This really isn't a topology, simply a session type.
> (And one that is core to even the original BFD spec, albeit simply a bit
> that wasn't well defined!)
>
> I also agree that the solution to permitting S-BFD with multipoint is to
> simply have a value that expresses that combination.  At this point, S-BFD
> with multipoint is undefined.
>
> At this point it is also worth noting that the session type has no
> centralized location covering their enumerations.  This leads to two
> interesting observations:
> - We could have an IANA registry for such things.  However, I'm not sure
>   this is really need.  But this also means:
> - Here's another case why some pieces of the BFD yang module likely shoudl
>   be IANA maintained.  In this case, the bfd-path-type identity as the
>   relevant example.
>
> -- Jeff
>