Looking at some more technical aspects of this
/* Configuration */
"This augments the OSPFv3 protocol configuration
with segment routing.";
really?
leaf extended-lsa-support {
leaf extended-lsa-support {
why two? what does it mean if one is true and one false? (why not more
than two?:-)
I wonder too where this boolean is best placed; there seems to me to be
no obvious ospfv3 place for it so
"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:o
spf"
is probably as good as any.
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
is rt:type always set to ospfv3 as opposed to ospf? is there something
in ospf-yang that ensures this?
* Link State Database (LSDB) Augmentations
when "derived-from-or-self(/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type,"
+ "'ospfv3')" {
derived-from seems unnecessary for ospfv3, equality would do
grouping ipv4-link-local-tlv {
container ipv4-link-local-tlv {
description "IPv6 Link-Local LSA TLV";
IPv6 looks odd here
grouping ospfv3-e-lsa-area {
description "Area scope OSPFv3 Extended LSAs.";
container e-router {
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-router-lsa')" {
I see nothing derived from 'ospfv3-e-router-lsa' so I cannot see when
this is true
leaf type {
type uint8;
this is an enumeration in ospf-yang
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-network-lsa')"
likewise I cannot see this being true
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-inter-area-prefix-lsa')"
and again
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-inter-area-router-lsa')"
and again
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-intra-area-prefix-lsa')"
I think you know this by now but this one would work but is not needed,
simple equality test would do.
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-as-external-lsa')"
again equality is all that seems to be needed
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-nssa-lsa')"
and again
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-link-lsa')
and again
Tom Petch
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Friday, August 07, 2020 7:03 PM
Subject: I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-03.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
> Title : YANG Model for OSPFv3 Extended LSAs
> Authors : Acee Lindem
> Sharmila Palani
> Yingzhen Qu
> Filename :
draft-ietf-lsr-ospfv3-extended-lsa-yang-03.txt
> Pages : 26
> Date : 2020-08-07
>
> Abstract:
> This document defines a YANG data model augmenting the IETF OSPF
YANG
> model to provide support for OSPFv3 Link State Advertisement (LSA)
> Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide
> extensible TLV-based LSAs for the base LSA types defined in RFC
5340.
>
>
> The IETF datatracker status page for this draft is:
>
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang
/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-03
>
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa
-yang-03
>
> A diff from the previous version is available at:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yan
g-03
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
