Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!

Gert Grammel <> Wed, 06 April 2016 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E9A12D5EA; Wed, 6 Apr 2016 07:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w5NrXcHBMJ2n; Wed, 6 Apr 2016 07:08:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4270B12D65D; Wed, 6 Apr 2016 07:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eWfKRYoT+KNPzKmX7/z9dLoOcfmGR8JLE2ANKXZQH4E=; b=Bi14qzIRPUJDzoyd3eBjEKE5MJg8WAR3LOqtkC51pOmNuoAus3Hr14IrKVydzzqlCzGSin/Zuehy75zyHFQa3lwulQxu7kAxbZbr3N14KYAlZ8NU43IIZv7gcxoxAyEA6XA1vcpKP5XABOh7kATWz0v/f0nzx5QuQsKpPqe+twc=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 14:08:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 14:08:17 +0000
From: Gert Grammel <>
To: Juergen Schoenwaelder <>, "Rajiv Asati (rajiva)" <>
Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!
Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ9001qAgAVt/oCAAA0XAIAB8nqAgABDUICAAE4FgA==
Date: Wed, 06 Apr 2016 14:08:17 +0000
Message-ID: <>
References: <> <20160401090207.GA50653@elstar.local> <> <20160406062858.GA60806@elstar.local>
In-Reply-To: <20160406062858.GA60806@elstar.local>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 4b106438-2c23-46a5-b2fd-08d35e24e6f8
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1606; 5:kRtRjuPN4ycbI37rDI30wJrCp5uxYzXZpQE9V89RVCtQvjUBw9p7FTs78Qp9uBUGmo5Fr28xnIA/VG46rY6ANluL/1CuKCS6ulnsdY9zyOGrNqyk2KCo350ShSepYMLdh8+XIiOF4DiWxQf6z2qX3g==; 24:ZSAXNPc1T+YCRLTJKH0ij8h9HBelwb3OjDevHieFb1I1wO6LTJcFWMzgUj3byo4kEZVsZfSFR0gB6GJkoJUUozlbCFoYL6RrEeJWgD9Iczs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1606;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY1PR0501MB1606; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1606;
x-forefront-prvs: 0904004ECB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(15975445007)(77096005)(99286002)(93886004)(2950100001)(2900100001)(83506001)(11100500001)(106116001)(19580405001)(122556002)(86362001)(5002640100001)(50986999)(87936001)(81166005)(54356999)(19580395003)(6116002)(1220700001)(66066001)(3660700001)(5001770100001)(4001350100001)(586003)(76176999)(3846002)(189998001)(1096002)(102836003)(5004730100002)(2906002)(3280700002)(5008740100001)(36756003)(10400500002)(4326007)(92566002)(225543005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1606;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 14:08:17.4857 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1606
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Apr 2016 14:08:33 -0000

This case is another reason why the intended config should not be touched
by the server. Juergen is right that there are lots of different
implementations. It is the implementer¹s choice where to put configuration
state. Typically if a server supports rollback, the state is stored in a
database, otherwise it is often stored directly on HW. Both versions
survive a reboot. If you remove the LC (=Line Card?) the result is either
a) intended = config != active in case of a central config repository or
b) intended != config = active in case of config stored on LC

a) is a case that is often tolerated or even desired, as it allows to
pre-configure HW before it becomes physically available. B) is an error


On 2016-06-04 03:28, "netmod on behalf of Juergen Schoenwaelder"
< on behalf of> wrote:

>On Wed, Apr 06, 2016 at 02:28:03AM +0000, Rajiv Asati (rajiva) wrote:
>> Hi Juergen,
>> Thanks for the clarity. I somewhat agree. Different lifetime shouldn't
>>really cause any impact.
>> One nit,
>> When I pull out a configured interface, the operational state of this
>> interface is gone but not the config - if I put the interface back, it
>> should come up configured as before.
>> Depends. If LC itself is removed, then all the related interfaces would
>>be removed from the running-config. And reinserting the LC may not bring
>>their individual conf back (ignoring the notifications).
>Assuming LC means line card if not discard the following (and explain
>what LC means). I believe the answer here is that systems treat this
>differently and there is no universal answer. Some systems seem to
>store line card config on the line card itself, other systems
>associate config with the physical location of a port or interface,
>yet others associate config with a name of an interface (which may not
>indicate the physical location of an interface). Since implementations
>really differ here, we support multiple implementation options in the
>interfaces data model.
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <>
>netmod mailing list