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

<stephane.litkowski@orange.com> Fri, 27 November 2015 08:18 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 075E31A00DA for <isis-wg@ietfa.amsl.com>; Fri, 27 Nov 2015 00:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 P6P_ZsorhJ2Q for <isis-wg@ietfa.amsl.com>; Fri, 27 Nov 2015 00:18:30 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01EB1A00D5 for <isis-wg@ietf.org>; Fri, 27 Nov 2015 00:18:29 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id AC1FF2647B5; Fri, 27 Nov 2015 09:18:27 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 84F584C048; Fri, 27 Nov 2015 09:18:27 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0248.002; Fri, 27 Nov 2015 09:18:27 +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//9BCFCAAmjeAP//4b0Q
Date: Fri, 27 Nov 2015 08:18:27 +0000
Message-ID: <32271_1448612307_565811D3_32271_1831_1_9E32478DFA9976438E7A22F69B08FF921678FCBB@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> <15128_1448555355_5657335B_15128_22_1_9E32478DFA9976438E7A22F69B08FF921678ED5D@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <d9ef048c45c84512bba9c5afe9786cbf@BRMWP-EXMB11.corp.brocade.com>
In-Reply-To: <d9ef048c45c84512bba9c5afe9786cbf@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.1]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921678FCBBOPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.11.24.110316
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/6l1HIdbwiJiIujgMRyTVFx-T-Eg>
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: Fri, 27 Nov 2015 08:18:36 -0000

So there is no need for configuring it ... and no need of container for NSEL.


From: Radha Danda [mailto:rdanda@Brocade.com]
Sent: Friday, November 27, 2015 08:30
To: LITKOWSKI Stephane SCE/OINIS; Les Ginsberg (ginsberg); isis-wg@ietf.org
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

NSEL for ISIS is always set to 0.

From: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
Sent: Thursday, November 26, 2015 9:59 PM
To: Radha Danda; Les Ginsberg (ginsberg); isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

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<mailto: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.

_________________________________________________________________________________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.