Re: Tsvart last call review of draft-ietf-bfd-multipoint-16
Jeffrey Haas <jhaas@pfrc.org> Mon, 02 July 2018 18:09 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 D8CD8130F81; Mon, 2 Jul 2018 11:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MAax0NU-kdYI; Mon, 2 Jul 2018 11:09:15 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BA84013112B; Mon, 2 Jul 2018 11:09:15 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 968051E3D0; Mon, 2 Jul 2018 14:09:08 -0400 (EDT)
Date: Mon, 02 Jul 2018 14:09:08 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, "draft-ietf-bfd-multipoint.all@ietf.org" <draft-ietf-bfd-multipoint.all@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, IETF list <ietf@ietf.org>
Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16
Message-ID: <20180702180907.GA1009@pfrc.org>
References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <CA+RyBmVmsFxmiDTLLS5Jz+q_Fgb3O7QcsbMJwFUxbh-+9XxYWQ@mail.gmail.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net> <CA+RyBmVo2B6bh=j6a32xOcq8EwTGceuDeifgEGKBVRRwMi9HGQ@mail.gmail.com> <1A5DF3AA-ED83-4656-AB1B-E8CC9E721CE1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1A5DF3AA-ED83-4656-AB1B-E8CC9E721CE1@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/55m2jVuBbmxaPoA7EtwnhOM-BFw>
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: Mon, 02 Jul 2018 18:09:18 -0000
Carlos, On Tue, Jun 26, 2018 at 05:17:20AM +0000, Carlos Pignataro (cpignata) wrote: [...] > I do not believe the question was whether S-BFD or any other protocol followed the behavior. It’s a question about this document. > > For correctness, S-BFD (RFC 7880) did not miss to define PointToPoint value — it chose not to. > > Back to this document, the question was whether something needs to be written to clarify. > > The text in rev -18 still needs clarification. It reads: > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-18#section-5.4.1 > > bfd.SessionType > > The type of this session as defined in [RFC7880]. Newly added > values are: > > PointToPoint: Classic point-to-point BFD, as described in > [RFC5880]. > > MultipointHead: A session on the head responsible for the > periodic transmission of multipoint BFD Control packets > along the multipoint path. > > MultipointTail: A multipoint session on a tail. > > This variable MUST be initialized to the appropriate type when > the session is created. > > > Basically, the variable MUST be initialized, PointToPoint is used for RFC 5880, and this text effectively renders every implementation of RFC 5880 non compliant. > > Could you please add some clarifying text that codifies what you described above (i.e., existing p2p traditional BFD only do not need to set the variable) I'm not sure I agree with the assertion that adding this variable makes 5880 "non-compliant". It's a semantic that in a stand-alone classical 5880 scenario is irrelevant. We had a similar form of this discussion when we were working through WGLC comments on the BFD yang module. Effectively at this point, it's the only single place that the various modes are gathered together. In the context of the yang module, which must be flexible enough to cover implementations that may or may not support other modes of BFD, the variable is present to help differentiate session types. When the question was put to the AD during those comments as to whether we would need to peel out a separate registry covering the state, the decision was not to do it and that the yang module's IANA maintenance of that variable was sufficient. So, while I agree that the variable effectively comes into existence after the fact for standard 5880 BFD, I don't see it as a hindrance to any implementation's conformance. If we did, each time we added some sort of comparative state with the introduction of a new feature type, we'd have to completely re-issue all of the underlying RFCs that were impacted simple to catch that case. -- Jeff
- Re: Tsvart last call review of draft-ietf-bfd-mul… Carlos Pignataro (cpignata)
- Re: [Tsv-art] Tsvart last call review of draft-ie… Jeffrey Haas
- Re: [Tsv-art] Tsvart last call review of draft-ie… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-mul… Bob Briscoe
- Re: Tsvart last call review of draft-ietf-bfd-mul… Greg Mirsky
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: Tsvart last call review of draft-ietf-bfd-mul… Jeffrey Haas
- Re: Tsvart last call review of draft-ietf-bfd-mul… Carlos Pignataro (cpignata)
- Tsvart last call review of draft-ietf-bfd-multipo… Bob Briscoe
- Re: Tsvart last call review of draft-ietf-bfd-mul… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-mul… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Spencer Dawkins at IETF
- Re: [Tsv-art] Tsvart last call review of draft-ie… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-mul… Greg Mirsky