Re: Warren Kumari's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Wed, 04 July 2018 17:49 UTC

Return-Path: <rrahman@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 E586F130EA8; Wed, 4 Jul 2018 10:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 bUFO-XoJ_hbm; Wed, 4 Jul 2018 10:49:54 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65972130E09; Wed, 4 Jul 2018 10:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5670; q=dns/txt; s=iport; t=1530726594; x=1531936194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NBb41JJZt7PT+ovH8fAjhYI7bcjVQQgMyFeVH/uPvlA=; b=FglRP0ugYAQEQRyupuCTb7HrQXcCodWV1pqvsFE1i5uEzQWdJmO2tgmE SMSUYuXiFRRx/4HrN775y88L6mlLGcDzonoTUdZ78vGa1AHskXGVZP9D+ Dv8zY9FeQwE7KWXWJIld+ZpeneS3qAiQ3RMzmDAg1wTdeupzeRIC7kmnA M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DHAAC9Bz1b/4MNJK1SChkBAQEBAQEBAQEBAQEHAQEBAQGDSWJ/KAqDcIgEjDWBZZVPFIFmCyMJhEACF4INITQYAQIBAQIBAQJtHAyFNwYjEUUQAgEIEggCJgICAjAVAg4CBAENBYMgAYF/D6g8ghyIT4E1BYELh2KBVj+BDycMglyDGAIBAgGBKQEHCwE2gmoxgiQCh2GKBodlCQKGBIkaDYEzhAyIC4o1hy0CERMBgSQdOGFYEQhwFWUBgj6CJBcRiEiFPQFvAYEUjheBHwGBGQEB
X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208";a="138187418"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 17:49:53 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w64Hnr89025615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 17:49:53 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Jul 2018 12:49:52 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Wed, 4 Jul 2018 12:49:52 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Warren Kumari's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Thread-Topic: Warren Kumari's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUE7rh3vgw2YYj9UmFUWMQ1wVefaR/aB8A
Date: Wed, 04 Jul 2018 17:49:52 +0000
Message-ID: <E5A28979-F0E7-4018-A6FF-93115ADD3225@cisco.com>
References: <153072464426.27514.14043810545632452277.idtracker@ietfa.amsl.com>
In-Reply-To: <153072464426.27514.14043810545632452277.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.155]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D76D5EDF53595D48B6710DAA1983D7EE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Jdl_FtCJfZko6cME6I_Tael3GPQ>
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: Wed, 04 Jul 2018 17:49:57 -0000

Hi Warren,

Thanks for the review. 
In your example below
                 +--ro number-of-sessions (10)
                 +--ro number-of-sessions-up (2)
                 +--ro number-of-sessions-down (5)
                 +--ro number-of-sessions-admin-down (3)

There is a description on Page 37 of rev-16 of the draft, I can add to it as follows, is this sufficient?
      leaf number-of-sessions {
        type yang:gauge32;
        description "Number of BFD sessions.";
      }
      leaf number-of-sessions-up {
        type yang:gauge32;
        description "Number of BFD sessions currently in up state (as defined in [RFC5880]).";
      }
      leaf number-of-sessions-down {
        type yang:gauge32;
        description "Number of BFD sessions currently in down or init state (as defined in [RFC5880]).";
      }
      leaf number-of-sessions-admin-down {
        type yang:gauge32;
        description
          "Number of BFD sessions currently in admin-down state (as defined in [RFC5880]).";
      }

I will fix the nits in the next rev.

Regards,
Reshad.   

On 2018-07-04, 1:17 PM, "Warren Kumari" <warren@kumari.net> wrote:

    Warren Kumari has entered the following ballot position for
    draft-ietf-bfd-yang-16: Discuss
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    Don't panic, this should be an easy DISCUSS to clear, but I think it important
    for interoperability.
    
    In multiple places, you have:
                 +--ro number-of-sessions?
                 +--ro number-of-sessions-up?
                 +--ro number-of-sessions-down?
                 +--ro number-of-sessions-admin-down?
    
    I'm a little confused by the meaning of the counters, and didn't see them
    clearly defined anywhere. Apologies if I missed it...
    
    Are "number-of-sessions-admin-down" included in "number-of-sessions-down"?
    Is 'number-of-sessions' always equal to 'number-of-sessions-up' +
    'number-of-sessions-down', or is it always equal to 'number-of-sessions-up' +
    'number-of-sessions-down' + 'number-of-sessions-admin-down', or are there other
    cases?
    
    E.g: I have created 10 sessions (because I have 10 interfaces). 5 of them are
    down because there is no peer, 3 of them I've configured to be down (admin
    down), and so 2 of them are up.
    
    What should be in each of:
    number-of-sessions?
    number-of-sessions-up?
    number-of-sessions-down?
    number-of-sessions-admin-down?
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Thank you.
    
    I also had a few minor nits:
    Nits:
    Section 1:
    "The YANG modules in this document conform to the Network Management Datastore
    Architecture (NMDA) Network Management Datastore Architecture [RFC8342]. " The
    Department of Redundancy Department called and wants some of their words back
    please :-)
    
    Section 2:
    "Since BFD is used for liveliness detection of various forwarding
       paths, there is no uniform key to identify a BFD session.  So the BFD
       data model is split in multiple YANG modules where each module
       corresponds to one type of forwarding path."
    I think this would be more readable as:
    "... to identify a BFD session, and so the BFD..."  (hey, I said it was a nit)