Hi Derek Did you have any thoughts on my email below? I have not seen any response.
Thanks Alan From: Alan Davey Sent: 12 April 2016 07:58 To: 'Derek Man-Kit Yeung (myeung)' <[email protected]>; [email protected] Cc: OSPF WG List <[email protected]> Subject: RE: draft-ietf-ospf-yang-03 questions and doubts Hi Derek Thanks for your email, apologies for the delay in getting back to you. I have followed up on a couple of points from our email exchange. Please let me know your thoughts on the following. On the subject of separate containers for OSPFv2 and OSPFv3 interfaces, conditional statements add complexity. My analogy here is writing program code. In a similar situation, to support OSPFv2 and OSPFv3, I would have different top level functions for the two versions and then call common functions where possible. This gives a straightforward top-level with no conditional statements; simpler to write and easier to read and understand. Therefore, I think that a simpler definition would follow from having version-specific top level containers which then include common and version-specific common definitions. In interface-common-operation, I think that the DR and BDR information is provided to show the DR or BDR for a link as identified by the protocol. Therefore, for OSPFv3, this identification consists of the Router ID plus the interface ID. Note the following. - On the use of interface ID, as per RFC 5340, this is used in OSPFv3 to uniquely identify (among its own interfaces) the DR's interface to the link. (Recall that a router may have multiple interfaces to the link.) - Using the link-local IPv6 address may not be the most user-friendly way of identifying the link. The link-local address is normally auto-generated by the system, not assigned by the user, and therefore the user is likely to have to search the system configuration to identify the link to which it is associated. - The leaf bdr-ip-addr still has "type inet:ipv4-address" in version 04 of the draft. Regards Alan Davey From: Derek Man-Kit Yeung (myeung) [mailto:[email protected]] Sent: 03 March 2016 21:55 To: Alan Davey <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: OSPF WG List <[email protected]<mailto:[email protected]>> Subject: Re: draft-ietf-ospf-yang-03 questions and doubts Hi Alan, Please see DY> below. From: Alan Davey <[email protected]<mailto:[email protected]>> Date: Thursday, February 18, 2016 at 3:28 AM To: myeung <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: OSPF WG List <[email protected]<mailto:[email protected]>> Subject: RE: draft-ietf-ospf-yang-03 questions and doubts Hi Derek Thank you for your response, and apologies for the delay in getting back to you. Have you considered distinct ospfv3-interface-operation and ospfv2-interface-operation? Or even distinct "container ospfv2" and "container ospfv3"? DY> No, we do not plan to have explicit ospfv2 and ospfv3 container. We used when statement or if-feature to take care of OSPFv2 vs OSPFv3 specific fields in general. There are a number of differences between the Interface Data Structure defined in RFC2328 and in RFC5340. In particular, the following. Do you plan to add all of these differences to the interface-operation grouping? - DR and BDR identification. o As you wrote, section 9 of RFC2328 specifies that the Interface Data Structure includes the Router ID and IP address for the DR and BDR. o Section 4.1.2 of RFC5340 does not specify how to identify the DR and BDR, but given the OSPFv3 protocol, it seems reasonable that the router ID and interface ID would be stored. DY> In OSPFv3, the DR/BDR is still identified by a router ID. The interface ID of the DR is used when generating LSA and by itself do not identify the DR/BDR. DY> Given the DR/BDR router ID/ip address, one can locate the corresponding neighbor information and find the interface ID there. DY> So we are not going the duplicate the interface ID of the DR in the interface container again. - Section 4.1.2 of RFC5340 specifies a number of objects that do not appear in the RFC2328 version of the Interface Data Structure, as follows. o Interface ID. o Instance ID. DY> The two above will be added. It is missing now. To be clear. It is the interface ID of the local router, not the one of the DR, for the interface. o List of LSAs with link-local scope. DY> The model already have link-local LSA database. o List of IPv6 prefixes configured for the attached link. DY> Understood that it is mentioned in the OSPFv3 RFC. DY> However, looking at a few implementations there is no explicit display of such information with the interface related OSPF show command. DY> The IPv6 prefixes (or IPv4 prefix in OSPFv2) advertised by the router could be found already either from the interface module (IPv4/IPv6 augment) or from the LSA database itself. DY> Extracting it again in OSPF model interface operation data seems redundant. DY> We don't think we need it in the base model, but vendors could augment it if they find it useful. Thanks, - Derek Regards Alan From: Derek Man-Kit Yeung (myeung) [mailto:[email protected]] Sent: 04 February 2016 19:39 To: Alan Davey <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-ospf-yang-03 questions and doubts 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 <[email protected]<mailto:[email protected]>> Date: Tuesday, December 15, 2015 8:23 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/ospf
