Re: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07

"Les Ginsberg (ginsberg)" <> Wed, 25 November 2015 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 775891B2AF8 for <>; Wed, 25 Nov 2015 11:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.485
X-Spam-Status: No, score=-14.485 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, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OD2F8K3UwCqV for <>; Wed, 25 Nov 2015 11:07:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D24A1B2A82 for <>; Wed, 25 Nov 2015 11:07:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19627; q=dns/txt; s=iport; t=1448478478; x=1449688078; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Me2pktztrFDPFHUdfkxnzPR5PvsJ/kvDdXiZHXK1/Z0=; b=k5ZGF/AVOIq7DP9JTTKqXazrR23ZLeMOw0Vpnjixpdn1OoG2zbS6EHFl P89tWzkRO3jHQbwVAaKSlmInHXpXxVwwcOlwTsl3L5BFm++QXDHnaBsB4 gFc3UPz6rYMVEFxVU34lXo+eiFd4Zrte/2mgaF+x/DBUzvNQiwaJA07dU 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQABBlZW/4cNJK1egm5NU28GvjMBD?= =?us-ascii?q?YFmhg8CgUM4FAEBAQEBAQGBCoQ0AQEBBC1cAgEIDgMEAQEoBzIUCQgBAQQBEgi?= =?us-ascii?q?IJr42AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUhH6FEYQoBZJZFoNoAY0tgWOEQ?= =?us-ascii?q?YQejjGDcQEfAQFCgg4ggVZyg2QlHIEHAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,343,1444694400"; d="scan'208,217";a="212305904"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Nov 2015 19:07:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tAPJ7tBa000308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 19:07:55 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 Nov 2015 13:07:55 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Wed, 25 Nov 2015 13:07:55 -0600
From: "Les Ginsberg (ginsberg)" <>
To: Radha Danda <>, "" <>
Thread-Topic: draft-ietf-isis-yang-isis-cfg-07
Thread-Index: AdEnmJwdFwRr22YfQTqx+4BMOFFAcQAAW2IAAA5KhYAAB8VqQA==
Date: Wed, 25 Nov 2015 19:07:55 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_84f3e78ad4d748f7a9fc57a058f55097XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2015 19:08:01 -0000

Radha -

You are making the mistake of thinking that vendor specific CLI determines how we define the YANG model.

The protocol functionality is:

1)Define system-id for an IS-IS instance
2)Define one or more area addresses for the IS-IS instance

Whether a particular vendor uses a "net" config or  a "system-id" and "area address" config isn't relevant.


(Of course I work for a vendor that uses "net" config. :) )

From: Radha Danda []
Sent: Wednesday, November 25, 2015 8:47 AM
To: Les Ginsberg (ginsberg);
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

Thanks Les.

Regarding the net-address configuration. Find the sample configuration from Cisco router
router isis
net 49.0001.1720.1600.1001.00
net 50.0001.1720.1600.1001.00

net-address here consists of area-address, system-id and selector. Even Juniper router has similar configuration. So I think yang should be modelled to support these existing configurations.
And validation should be done to ensure the uniqueness of system-id.

In the above mentioned net configurations, system-id is unique.

If we don't support net-address configuration in yang, I am afraid back-end implementation of protocols might have to be changed. Please let me know your thoughts.

Also the way yang model is currently designed (assuming the selector is removed from system-id), there is no way to input selector now.

And separate area-address is not needed if we support net-address configuration.

Best Regards,

From: Les Ginsberg (ginsberg) []
Sent: Wednesday, November 25, 2015 9:33 PM
To: Radha Danda;<>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

Radha -

From: Isis-wg [] On Behalf Of Radha Danda
Sent: Wednesday, November 25, 2015 7:49 AM
Subject: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07


I was going through draft-ietf-isis-yang-isis-cfg-07 and I have below comments.

1. system-id definition should not contain selector. As per NSAP definition, system-ID is 6 bytes and it has below mentioned format and it is only of length 6 bytes.

[Les:] I agree - selector should NOT be part of system-id.

typedef system-id {

    type string {





     "This type defines ISIS system id using pattern,

      system id looks like : 0143.0438.AeF0";


2. Also we need support to configure net-address as shown below.

[Les:] No. The model correct supports the config of one system-id (as modified above) and one or more area addresses.

There are implementations which combine the configuration into a single CLI "net" - but if multiple area addresses are supported the same system-id MUST be entered on each line - so functionally what you have are multiple (synonymous) area addresses and a single system-id. The model has it correct in that regard.


       typedef net-address {

                type string {



                        configd:pattern-help "XX.XXXX. ... .XXXX.XX";

                        configd:help "Network entity title (NET)";



Please let me know if you need more details. This is my first post, so please excuse me in case if I miss to provide some details.

Best Regards,