Re: WGLC for BFD Multipoint documents (last round)

Jeffrey Haas <> Tue, 19 December 2017 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBCA3126C26 for <>; Tue, 19 Dec 2017 08:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FilikrvcPzRm for <>; Tue, 19 Dec 2017 08:01:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0C39C12D7FC for <>; Tue, 19 Dec 2017 08:01:34 -0800 (PST)
Received: by (Postfix, from userid 1001) id C61931E35A; Tue, 19 Dec 2017 11:05:37 -0500 (EST)
Date: Tue, 19 Dec 2017 11:05:37 -0500
From: Jeffrey Haas <>
To: "Carlos Pignataro (cpignata)" <>
Cc: Greg Mirsky <>, "" <>
Subject: Re: WGLC for BFD Multipoint documents (last round)
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Dec 2017 16:01:37 -0000

[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