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

<stephane.litkowski@orange.com> Thu, 26 November 2015 16:29 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B961B2BA1 for <isis-wg@ietfa.amsl.com>; Thu, 26 Nov 2015 08:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 FfShpgSyd6kc for <isis-wg@ietfa.amsl.com>; Thu, 26 Nov 2015 08:29:17 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918641B2BA0 for <isis-wg@ietf.org>; Thu, 26 Nov 2015 08:29:17 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B4643C03CA; Thu, 26 Nov 2015 17:29:15 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 7CC3340057; Thu, 26 Nov 2015 17:29:15 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0248.002; Thu, 26 Nov 2015 17:29:15 +0100
From: <stephane.litkowski@orange.com>
To: Radha Danda <rdanda@Brocade.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: draft-ietf-isis-yang-isis-cfg-07
Thread-Index: AdEnmJwdFwRr22YfQTqx+4BMOFFAcQAAW2IA///8+4CAACdcgIAAt6qA//9BCFA=
Date: Thu, 26 Nov 2015 16:29:14 +0000
Message-ID: <15128_1448555355_5657335B_15128_22_1_9E32478DFA9976438E7A22F69B08FF921678ED5D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <5d1815f82559463abe2197b10f84954b@BRMWP-EXMB11.corp.brocade.com> <384cdb90ae534966afede0962769209f@XCH-ALN-001.cisco.com> <568f541a5489469383198806aa7185f7@BRMWP-EXMB11.corp.brocade.com> <84f3e78ad4d748f7a9fc57a058f55097@XCH-ALN-001.cisco.com> <58867eb090624c57b26e3535a755862c@BRMWP-EXMB11.corp.brocade.com>
In-Reply-To: <58867eb090624c57b26e3535a755862c@BRMWP-EXMB11.corp.brocade.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921678ED5DOPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/HiLhk0AShDLVi1V-Bv9B-D6bhGI>
Subject: Re: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 16:29:22 -0000

Is there any real use case for configuring NSEL <> 0 ?


From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Radha Danda
Sent: Thursday, November 26, 2015 07:05
To: Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: Re: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07

Hi Les,
Thanks (leaving the vendor specific problems apart),
net-address is not any vendor-specific component. RFC defines it. By defining net-address in yang it would be easy to integrate with the existing systems. Even ISIS-MIB defines net object.
Now selector is removed from system-id, so new container have to be defined for "selector"
All these things can be done with net-address.

Best Regards,
Radha

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Thursday, November 26, 2015 12:38 AM
To: Radha Danda; isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

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.

   Les

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


From: Radha Danda [mailto:rdanda@Brocade.com]
Sent: Wednesday, November 25, 2015 8:47 AM
To: Les Ginsberg (ginsberg); isis-wg@ietf.org<mailto:isis-wg@ietf.org>
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,
Radha

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

Radha -

From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Radha Danda
Sent: Wednesday, November 25, 2015 7:49 AM
To: isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: [Isis-wg] draft-ietf-isis-yang-isis-cfg-07


Hi,

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 {

      pattern

       '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';

    }

    description

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



   Les



       typedef net-address {

                type string {

                        pattern

                                '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.00';

                        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,

Radha


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.