Re: Tsvart last call review of draft-ietf-bfd-multipoint-16

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 02 July 2018 19:17 UTC

Return-Path: <cpignata@cisco.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 BDCC21312C0; Mon, 2 Jul 2018 12:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 P96PK5-5w_F2; Mon, 2 Jul 2018 12:17:48 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED71213124D; Mon, 2 Jul 2018 12:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17232; q=dns/txt; s=iport; t=1530559063; x=1531768663; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fHNQXZPR7tlQiBCQT4bzqkEOXPSX3nPD/0LrT3IOFGY=; b=iJ77U0a5IBDnWxwi/0yIGbUM/hcocImqz2VhD8gOU355FMdt4CSKkWZR jk37bG0P2T7Amx9C8kEUSdxYlLWhntH3Rw1OGJ+wUpUApeVc+ZL9zjrhG ukhJUQEuDXJUp8kTQQfyu+UP9I6uh8aJK2NhDMEpbVDhLFe7SVBmBrw8c I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D4AAAUeTpb/4YNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYNJYn8oCoNviASMQIFlIpAYhQyBegsjhEkCF4MdITQYAQIBAQIBAQJtHAyFNwYjVhACAQgOMQMCAgIwFBECBA4FgyABgRtkD6gcghwfiDCBMQWIbYFWP4EOAScMglyDGAEBAgGEXjGCJAKRYodkCQKGBIkXgUCEDIgJijOHLQIREwGBJB04gVJwFWUBgj6CJBeIWYU+bwEBj2uBGgEB
X-IronPort-AV: E=Sophos;i="5.51,300,1526342400"; d="scan'208,217";a="407957339"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2018 19:17:41 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w62JHfhd031412 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Jul 2018 19:17:41 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Jul 2018 15:17:41 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Mon, 2 Jul 2018 15:17:40 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
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
Thread-Topic: Tsvart last call review of draft-ietf-bfd-multipoint-16
Thread-Index: AQHT/HRExw3CBwk62EGoYxhzIgZ7z6RyZA6AgApFoQCAABMlgA==
Date: Mon, 02 Jul 2018 19:17:40 +0000
Message-ID: <5E9130A6-B3A2-4D01-9886-C99B4B8C9F33@cisco.com>
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> <20180702180907.GA1009@pfrc.org>
In-Reply-To: <20180702180907.GA1009@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.141]
Content-Type: multipart/alternative; boundary="_000_5E9130A6B3A24D019886C99B4B8C9F33ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/L6MuMJgByy-4lCxHDs0NyauxoeQ>
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 19:18:04 -0000

Jeff,

On Jul 2, 2018, at 2:09 PM, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:

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”.

I did not say that adding the variable (or variable value) makes 5880 “non-compliant”; I am happy you disagree (or at least you are not sure you agree) with that assertion, which is not mine made.

I did say that the *text* describing the rules around the variable value, as written, does.

 It's a semantic that in a stand-alone classical 5880
scenario is irrelevant.


It really depends on how the text around the new variable values is crafted.

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.

Instead of arguing what might happen if someone suggested that adding a variable state would render base-specs out of compliance — who said that by the way? — let’s look at the exact text once more:

~~~
5.4.1.  New State Variable Values
      bfd.SessionType

            PointToPoint: Classic point-to-point BFD, as described in
            [RFC5880].
[…]
         This variable MUST be initialized to the appropriate type when
         the session is created.
~~~

I am not advocating a rat-hole discussion, or tempting tangential extrapolations.

But, to me, it can be argued that if the variable is not initialized to PointToPoint (which happens if it doesn’t exist), then the MUST is violated...

Greg Misrky wrote in response to Bob Briscoe:
Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode.

But that is not what the spec says.

Thanks,

Carlos.


-- Jeff