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

[<[e-mail]>]

There was a discussion at the beginning of the model writing.
It was decided to go to the area/system-id which is more flexible and fits all implementations rather than most with NET.


From: Radha Danda [mailto:[e-mail]]
Sent: Friday, November 27, 2015 11:05
To: LITKOWSKI Stephane SCE/OINIS; Les Ginsberg (ginsberg); [e-mail]
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

But my point is, now if you don't ensure that you are getting value 0 for NSEL and filer ISIS packets, then we might land-up processing unwanted (control) traffic. This could be considered as a check/filter from DOS attacks or unintentional processing of other NSAP packets.

And it is good to provide net-address container as per RFC, because most of the vendors have this implementation, it will be easy to adopt to the ISIS yang RFC without much backend modifications.

Best Regards,
Radha,

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Friday, November 27, 2015 1:48 PM
To: Radha Danda; Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

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


From: Radha Danda [mailto:[e-mail]]
Sent: Friday, November 27, 2015 08:30
To: LITKOWSKI Stephane SCE/OINIS; Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

NSEL for ISIS is always set to 0.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, November 26, 2015 9:59 PM
To: Radha Danda; Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

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


From: Isis-wg [mailto:[e-mail]] On Behalf Of Radha Danda
Sent: Thursday, November 26, 2015 07:05
To: Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Thursday, November 26, 2015 12:38 AM
To: Radha Danda; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Wednesday, November 25, 2015 8:47 AM
To: Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Wednesday, November 25, 2015 9:33 PM
To: Radha Danda; [e-mail]<mailto:[e-mail]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

Radha -

From: Isis-wg [mailto:[e-mail]] On Behalf Of Radha Danda
Sent: Wednesday, November 25, 2015 7:49 AM
To: [e-mail]<mailto:[e-mail]>
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.

_________________________________________________________________________________________________________________________

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.