I tried http://www.yangvalidator.com/draft-validator on my most recent update
and it finished with no errors. However, there was an internal error in pyang
(+Martin):
Traceback (most recent call last):
pyang", line 444, in <module>
run()
pyang", line 219, in run
repos = pyang.FileRepository(path, no_path_recurse=o.no_path_recurse)
__init__.py", line 408, in __init__
location = pip.locations.distutils_scheme('pyang')
AttributeError: 'module' object has no attribute 'locations'
Thanks,
Acee
From: Stephane Litkowski <[email protected]>
Date: Monday, December 10, 2018 at 4:54 AM
To: Acee Lindem <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Acee and co-authors,
The last version of the model has a compilation failed status in the YANG
catalog.
https://yangcatalog.org/results/ietf-ospf@2018-11-27_ietf.html
Could you check what’s going on ?
From: Lsr [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, December 10, 2018 10:16
To: Acee Lindem (acee); [email protected]; [email protected]
Subject: Re: [Lsr] Shepherd's review of ietf-ospf.yang and
draft-ietf-ospf-yang-17
Hi Acee,
I’m fine with that.
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Friday, December 07, 2018 18:03
To: LITKOWSKI Stephane OBS/OINIS; [email protected]; [email protected]
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hi Stephane,
I’ve added sample values or guidance to the descriptions of these parameters
based on Appendix C in RFC 2328. I don’t think we should use these as defaults
unless they are normative in the existing standards as implementations of the
YANG model will have to guarantee these defaults or use deviations.
Thanks,
Acee
From: Stephane Litkowski <[email protected]>
Date: Thursday, November 29, 2018 at 5:44 AM
To: Acee Lindem <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hi Acee,
In IS-IS some of the defaults we are using a coming from the ISO spec and some
from vendor implementations (common used values). At the beginning we had no
default in IS-IS, and during a review, there was a request to add defaults. I
cannot remember who did this request.
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Wednesday, November 28, 2018 18:09
To: LITKOWSKI Stephane OBS/OINIS; [email protected]; [email protected]
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hi Stephane,
From: Stephane Litkowski <[email protected]>
Date: Wednesday, November 28, 2018 at 7:04 AM
To: Acee Lindem <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hi Acee,
For the default values, some examples where I was expecting defaults:
hello-interval, dead-interval, retransmit-interval, transmit-delay, passive,
priority, cost…
There are no normative values for the interface timers – just suggested
defaults in an RFC2328 appendix. The defaults can depend on the interface type
and the deployment (much like the SPF delay timers). For cost, some
implementations use 1 as the default (i.e., a hop count) and others default to
making the cost inversely proportional to the link speed. I’m hesitant to
define normative defaults. Are the timer defaults normative in the ISO IS-IS
specification?
Another comment, in the last version of the IS-IS model, I have catched up all
the existing IS-IS extensions in the LSDB description (all that have an IANA
code point registered). What’s your plan for OSPF ?
This falls back the point that we have discussed by email on how we extend the
base model with new extensions. One way would be to have the base model to
catch up all the existing RFCs (that have implementations), and the on going
drafts should have their own extension YANG model.
We have separate drafts now for OSPF SR and OSPFv3 extend LSAs. I think we
should use what we have a baseline – least we never get done. We could update
the RI LSA with some additional from RFCs that have been published. Let me
discuss with the authors.
Thanks,
Acee
Brgds,
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Tuesday, November 27, 2018 23:53
To: LITKOWSKI Stephane OBS/OINIS; [email protected]; [email protected]
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hey Stephane,
Thanks for the great review – I’ve incorporated most of your comments in the
-18 version (just posted). See some inlines.
From: Stephane Litkowski <[email protected]>
Date: Wednesday, November 21, 2018 at 5:34 AM
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Resent-From: <[email protected]>
Resent-To: Derek Yeung <[email protected]>, Yingzhen Qu
<[email protected]>, Jeffrey Zhang <[email protected]>,
<[email protected]>, Acee Lindem <[email protected]>
Resent-Date: Wednesday, November 21, 2018 at 5:34 AM
Hi,
Here are some comments I have on the model:
• The model should use the LSR WG as point of contact and no more the
OSPF WG
• In the feature multi-topology: s/-Topolgy/-Topology
• In the packet-type typedef:
s/database-descripton/database-description.
• In the container lsa-log description: s/conatiner/container
• OSPF model has no keychain feature, while ISIS has one. We need to
agree on a common way to go.
I went ahead and added a feature to OSPF. It seems we have done this for other
options outside the base RFCs.
• In the container link-tlvs, the link-type is an uint8 , wouldn’t it
be better to use an enum to get a description of what is the link type ?
• Need to expand “af” to ”address-family” everywhere in the model
(comments received from Yang doctor in the ISIS model review => ISIS has done
this expansion).
I did this but am not so sure this is an improvement 😉
• Ietf-spf-delay timers use uint16 while ISIS uses
timer-value-milliseconds
• The grouping instance-config has a “uses
instance-fast-reroute-state”. It would be better to put it in the
instance-state container.
• The model uses the “ospf-protocol” identity while IS-IS uses just
“isis”. We need to find a common way to define the protocol identity name. RIP
yang model uses just “rip”, so I suppose OSPF has to align.
• In the feature “fast-reroute” reference: s/Rereoute/Reroute/
• The description of the identity “ospf-lsa-type” is strange: “Base
identity for OSPFv3 and OSPFv3 Link State Advertisements”. Do you mean just :
“Base identity for OSPFv3 Link State Advertisements”
This should be “OSPFv2 and OSPFv3 …” I have updated in -18.
• It seems that you are using a typedef uint24 for the metric. In IS-IS
there is a metric typedef for this purpose.
• In the if-state-type, the value 6 is referred as “bdr” while the RFC
talks about “backup”. “bdr” works for sure, we just need to agree if we align
on RFC naming or common usage naming.
• In the nbr-state-type, why using “ex-start” instead of “exstart”,
again the RFC does not use the “-“.
• In the packet-type: s/Acknowlegement/Acknowledgement/
• In the ospfv2-router-link, the type is uint8, would be better to have
an enum. Note that this appears multiple times in the model.
• In the leaf-list attached-router “line 1376”, why using dotted-quad
instead of ip-address type ?
These are router-ids which are not necessarily IP addresses.
• In the grouping area-stat, there are checksum sums that are using
int32 type while checksums are using uint32 or some other checksum sums (like
in interface-stat) also use uint32. Need to be consistent here.
• In the grouping interface-physical-link-config, why do you say that
it applies to physical interfaces ? Can’t you run OSPF on VLANs ?
By physical, I mean non-virtual. RFC 2328 uses this terminology. I did not
change.
• Please set default values as much as you can (for instance in
interface-common-config or interface-physical-link-config or interface-config…)
I’m hesitant to do this since these defaults are non-normative in the RFCs. Can
you give an example? I think it is obvious that the absence of a feature means
it is not configured.
• Why do you have interface-physical-link-config and interface-config,
what difference do you make between the two ? My point is why there is still so
much containers/leaves in the interface-config and why couldn’t we put them in
the other groupings or even create additional ones if required.
I’m not sure I disagree with the groupings. There are other possible
hierarchies but this seems to work.
• What is the purpose of some empty groupings that you have created ?
like “ospf-config” or “ospf-state”
These are meant to be augmented for top-level config and stats.
Thanks,
Acee
• In the multi-topology-area-common-config, you are using a limited
uint32 type for the default cost while you have defined a uint24 type that you
can use. It appears also in area-common-config.
On the draft:
• In the overview (§1), reference to 7950 does not appear as a link,
maybe an XML issue.
• §2.2: s/The topology container/The “topologies” container
Brgds,
[Orange logo]<http://www.orange.com/>
Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
NEW !
mobile: +33 6 71 63 27 50
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
NEW !
[email protected]<mailto:[email protected]>
_________________________________________________________________________________________________________________________
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,
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,
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,
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,
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
