Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

["Derek Man-Kit Yeung (myeung)" <[e-mail]>]

Hi Alan,

Please see DY> below.

From: Alan Davey <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 18, 2016 at 3:28 AM
To: myeung <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: OSPF WG List <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: 04 February 2016 19:39
To: Alan Davey <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 15, 2015 8:23 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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