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

From: Radha Danda <[email-masked]>
Date: Fri, 27 Nov 2015 13:57:47 +0000

Ok. Thanks.
May be I am missing something. The implementation that I saw I found net to be using everywhere and we are also using net. So I brought this point for discussion.

Best Regards,
Radha

-------- Original message --------
From: [email-masked]
Date:27/11/2015 3:47 PM (GMT+05:30)
To: Radha Danda , "Les Ginsberg (ginsberg)" , [email-masked]
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

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:[email-masked]]
Sent: Friday, November 27, 2015 11:05
To: LITKOWSKI Stephane SCE/OINIS; Les Ginsberg (ginsberg); [email-masked]
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, November 27, 2015 1:48 PM
To: Radha Danda; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: Friday, November 27, 2015 08:30
To: LITKOWSKI Stephane SCE/OINIS; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

NSEL for ISIS is always set to 0.

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

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

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

Radha -

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 28 Nov 2015 17:52:09 +0000

The use of the NSEL field is best defined in ISO 10589 Section 7.1.3.2:

“SEL   NSAP Selector — a 1-octet field which acts as a selector for the entity which is to receive the PDU (this may be a Transport entity or the Intermediate system Network entity itself). It is the least significant (last) octet of the NPAI.”

The selector identifies the user of the network service at a given node. This could be a “transport entity” (such as the ISO Transport service) or it could be the IS-IS protocol. The selector is meaningful when one is sending packets using the ISO addressing scheme defined in ISO  8348 Annex A. So if one supports the ISO Connectionless Network Layer Protocol (CLNP) then the NSEL would have meaning. In such a network IS-IS PDUs can be encapsulated in CLNP PDUs (using an NSEL of “00”) in support of the partition repair function. The NSEL of “00” insures that when the CLNP PDU arrives at the destination node it is passed to the correct network layer user (IS-IS in this case).

NSEL has no meaning to IS-IS itself and the NSEL does NOT appear in IS-IS PDUs i.e. IS-IS advertises one or more area addresses and a system-id. As we are not defining support for operating in a network using ISO destination addresses there is no need to include NSEL in the model.

HTH

   Les

From: Radha Danda [mailto:[email-masked]]
Sent: Friday, November 27, 2015 5:58 AM
To: [email-masked]; Les Ginsberg (ginsberg); [email-masked]
Subject: Re: draft-ietf-isis-yang-isis-cfg-07

Ok. Thanks.

Best Regards,
Radha

-------- Original message --------
From: [email-masked]<mailto:[email-masked]>
Date:27/11/2015 3:47 PM (GMT+05:30)
To: Radha Danda , "Les Ginsberg (ginsberg)" , [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-isis-yang-isis-cfg-07

Best Regards,
Radha,

Hi Les,

Best Regards,
Radha

Radha –

   Les

Thanks Les.

Best Regards,
Radha

Radha -

Hi,

typedef system-id {

    type string {

      pattern

    }

    description

  }

   Les

       typedef net-address {

                type string {

                        pattern

                }

        }

Best Regards,

Radha

Thank you.

Thank you.

Thank you.