Hi Tom,
See inline.
On 6/3/20, 7:04 AM, "rtgwg on behalf of t petch" <[email protected] on
behalf of [email protected]> wrote:
Looking some more, at -15:
The choice of OSPF identity puzzles me
I would expect a base OSPF identity to be useful from which all other
OSPF then derive
I am not familiar with NSSA T1 and T2 - I see no such language in
RFC3101 nor is there an update to that RFC (but they do appear in
ospf-yang!)
The identity names seem inconsistent
identity ospf-internal-type {
identity ospf-external-type {
identity ospf-external-t1 {
identity ospf-external-t2-type {
identity ospf-nssa-type {
identity ospf-nssa-t1 {
I suspect that '-type' is redundant if the usage is as in this i-D
More generally, is the intention that these match the LSA type? If so,
it would help me to have the value of the LSA type in the YANG
description - it is what I think in terms of.
Routing policy normally is used on routes. Hence, these identities are for the
route type specified by the installing RIB client. In the case of OSPF, they
would correspond to the LSA type of the LSA which resulted in installation of
routes.
s.10
'described by the YANG modules' !
"RFC 5302 - Domain-Wide Prefix Distributino ..."
container routing-policy {
leaf name {
type string;
I have always liked the more constrained yang-identifier as opposed to
string but suspect I am alone in that.
While identifiers in the respective implementations are more constrained (e.g.,
with respect to length), IETF models do not normally include this.
Thanks,
Acee
I did look for the four original authors and did not see them; they
are there - I was looking at the second list of parties and missed the
first list which is where they are
Tom Petch
> I have some doubts about this I-D
>
> -01 had four authors; -13 has four authors. None are the same yet much
> of the text in the I-D is the same.
>
> NSSA could be added to the Terminology and/or expanded on first use.
>
> Policy subroutines sound interesting - if there is one example I would
> find useful it would be one involving subroutines.
>
> 10 YANG modules
> I only see one singular
>
> XXXX is used as a placeholder for two different I-D
>
> I like the reference to RFC2178, RFC5130 but they need to appear in the
> I-D References and more YANG reference clauses would not come amiss
>
> typedef metric-modification-type {
> ....
> If the result would exceed the maximum metric
> (0xffffffff), set the metric to the maximum.";
> OSPF has a 16 bit link metric, a 24 bit route metric as defined in
> ospg-yang. Defining a maximum of 0xffffffff seems problematic. Add two
> to 16777215 and you get one.
> The other LSR protocol has a 6 or 24 or 32 bit metric depending on where
> you look.
>
> "The prefix member in CIDR notation -- "
> member of what? My prefix are a number!
>
> leaf mask-length-upper {
> the example implies that upper and lower must both be present which I do
> not see in the YANG. Both upper and lower are part of the YANG key of
> the list which also suggests that both need to be present
>
> grouping match-proto-route-type-condition {
> gets a bit long; here and elsewhere, is 'proto' needed as part of the
> identifier?
>
> container prefix-sets {
> leaf mode {
> I am not a fan of features - Cartesian explosion - but wonder if one is
> called for here at least for mixed mode
>
> Tom Petch
>
> ----- Original Message -----
> From: <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
