Hi Alan,
Thanks for the comments.
As you have pointed out, there are OSPFv3 specific fields missing in the model
now. For example, instance ID and interface ID. We will add them in the next
update.
As for the DR, DR is conceptually one of the neighbor.
In OSPFv2, the DR's router ID and IP address are used in protocol operation.
While in OSPFv3, the DR's router ID and interface ID are used in protocol
operation.
According to OSPFv2 and OSPFv3 RFC, the interface structure should keep both
the DR's router ID and IP address.
We have the following in the current model.
grouping interface-operation {
leaf dr {
type inet:ipv4-address;
description "Designated Router (DR) IP address.";
}
}
grouping neighbor-operation {
leaf dr {
type yang:dotted-quad;
description
"Designated Router.";
}
}
To better match the RFC and accommodate both OSPFv2 and OSPFv3 in a cleaner
way, we plan to make the following changes.
grouping interface-operation {
leaf dr-router-id {
type yang:dotted-quad;
description
"Designated Router (DR) router ID.";
}
leaf dr-ip-address {
type inet:ip-address;
description "Designated Router (DR) IP address.";
}
}
grouping neighbor-operation {
leaf dr-router-id {
type yang:dotted-quad;
description
"Neighbor's Designated Router (DR) router ID.";
}
leaf dr-ip-address {
type inet:ip-address;
description "Neighbor's Designated Router (DR) IP address.";
}
}
If one need the DR's interface ID in the OSPFv3 case, it could be found by
locating the neighbor entry for the DR and get the interface ID (To be added)
field there.
Comments welcome.
Thanks,
- Derek
From: Alan Davey <alan.da...@metaswitch.com<mailto:alan.da...@metaswitch.com>>
Date: Tuesday, December 15, 2015 8:23 AM
To: "draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>"
<draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>>
Cc: "ospf@ietf.org<mailto:ospf@ietf.org>" <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: draft-ietf-ospf-yang-03 questions and doubts
Folks
I have a doubt about draft-ietf-ospf-yang-03. Please let me know your thoughts
on the following.
The text is OSPFv2-specific in places. I think that it would be better to
define separate top-level groupings and containers for OSPFv2 and OSPFv3 and
define common groupings and containers, where possible, that are used by both.
For example, grouping interface-operation contains the following, which is
incorrect for OSPFv3.
- leaf dr with type ipv4-address
- leaf bdr with type ipv4-address.
I think that it would be better to define something along the following lines.
- ospfv3-interface-operation {
o uses interface-config
o uses ospf-common-interface-operation
o leaf dr {
§ type if:interface-ref
§ description:
· "The remote interface ID used by the Designated Router on
· this link. This is the interface index of the interface
local to the DR.";
o etc
- ospfv2-interface-operation {
o uses interface-config
o uses ospf-common-interface-operation
o leaf dr {
§ type inet:ipv4-address;
§ description "Designated Router (DR) IP address.";
o etc.
Regards
Alan Davey
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
