Re: [netmod] NMDA System controlled resource

Robert Wilton <rwilton@cisco.com> Thu, 17 May 2018 08:58 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913B112E868 for <netmod@ietfa.amsl.com>; Thu, 17 May 2018 01:58:54 -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 vOMwXFi67814 for <netmod@ietfa.amsl.com>; Thu, 17 May 2018 01:58:53 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB9B12AF83 for <netmod@ietf.org>; Thu, 17 May 2018 01:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9813; q=dns/txt; s=iport; t=1526547532; x=1527757132; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nIRZ+luJKQ4ETJl7n23TRSIrZCT3qntOxVgDNxSKRbU=; b=cNe0BlUHbM3R/n7ha2WaBjq2vh8l//Ffx51XTQHHFEBJpaWgssqHEafl XGpjXWWwKyPDRV6LvJXnsNmPUKLeCbpdCDHZqcv37BAPuekLi/3fGyxQa 1E4gbo8e9QVPnW7J+P/CNAEPlEMgD6Y+X8BI8hZ+sGxoziJy7ZN/M6eFO M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AgDvQ/1a/xbLJq1bGgEBAQEBAgEBAQEIAQEBAYJNgVd9KIxWjWcpgQ+OP4R3gXgLGAEKhANGAoItNhYBAgEBAQEBAQJsHAyFKQEBBAEBK0EbCxguJzAGAQwGAgEBgx8CgX8PqGMfhDmDdYIiBYoCP4EPI4JpgxEBAYc0AphGCY5PBodehRqLRYUrgSUiATGBUjMaCBsVO4JDixCFPz4wjzcBAQ
X-IronPort-AV: E=Sophos;i="5.49,390,1520899200"; d="scan'208,217";a="3848759"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 08:58:50 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4H8wnZw012426; Thu, 17 May 2018 08:58:50 GMT
To: Rohit R Ranade <rohitrranade@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <4da2b372-d950-80c6-5a8e-9fa58951f6a8@cisco.com>
Date: Thu, 17 May 2018 09:58:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBAAC22@dggeml510-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------94A9D9705A0BC413E4C3CA6E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jeCkSY3y1AQqe78Vy47ka7ICsFM>
Subject: Re: [netmod] NMDA System controlled resource
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 08:58:55 -0000

Hi Rohit,

Section 5.3.2 states that you allowed to have configuration in 
<running>/<intended> for resources that could be present on the device 
but are not currently present.  The canonical example would be interface 
configuration for an interface on a linecard that isn't operational 
(either because it isn't present, or hasn't completely initialized).

Section 5.3.3 is saying that if the linecard becomes operational, then 
it may instantiate system controlled entries (in <operational>) for 
those interfaces.  It also states that if there also happens to be 
configuration in <running>/<intended> for those interfaces then that 
configuration will also get applied as those interfaces as instantiated 
in <operational>.  All of the configuration that has been successfully 
applied would also appear in <operational>.

Thanks,
Rob


On 17/05/2018 04:57, Rohit R Ranade wrote:
>
> Hi All,
>
> RFC 8342 has below statement in Section 5.3.3
>
> “If a system-controlled resource has
>
>    matching configuration in <intended> when it appears, the system will
>
>    try to apply the configuration; this causes the configuration to
>
>    appear in <operational> eventually (if application of the
>
>    configuration was successful).
>
> “
>
> Why does application of configuration for system-controlled resources 
> depend on whether <intended> has configurations for that resource ? 
> The configuration will still get applied as part of “system” 
> configuration as shown in examples in Section C.1 in the same RFC 
> given below
>
> “In addition to filling in the default value for the auto-negotiation
>
>    enabled leaf, a loopback interface entry is also automatically
>
> instantiated by the system.  All of this is reflected in
>
> <operational>.”
>
> With Regards,
>
> Rohit R Ranade
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod