Re: [OSPF] Some doubts about OSPF YANG model.

["Acee Lindem (acee)" <[e-mail]>]

Hi Yangang,

Thanks for reviewing - let me answer the ones for which I have answers and we will discuss the others amongst the authors.

From: OSPF <[e-mail]<mailto:[e-mail]>> on behalf of Yangang <[e-mail]<mailto:[e-mail]>>
Date: Saturday, August 20, 2016 at 10:23 AM
To: OSPF WG List <[e-mail]<mailto:[e-mail]>>
Subject: [OSPF] Some doubts about OSPF YANG model.

Hi,

I am reading the YANG model of OSPF, and I have some doubts. I hope it can provide some help for model standard process.

1. Page 8: There are two leaf: mtu-ignore and prefix-suppression. I think maybe no need define these two leaf in virtual link.

prefix-suppression is not applicable to virtual links since there is no interface subnet associated with a virtual link.
mtu-ignore is not applicable to virtual links since it the field in the DD packet is always 0 (see section 10.8 in RFC 2328).



2. Page 9: Similar with the first doubt, do we need "mtu-ignore" in sham-link?

Similar to a virtual link, sham link implementations set the MTU to 0 in DD packets (unfortunately, this is not explicitly stated in RFC 4577).


3. Page 9: Maybe there is a mistake in writing. "bfd" leaf should be moved to OSPF BFD model.

Will need to discuss. We have gone back and forth on whether or not we need a separate OSPF BFD model.


4. Page 13: In the notification definition: About the "rx-bad-packet", it is not same as the model, "if-rx-bad-packet". The other, there is similar trap in OSPF MIB. But some EMS/NMS don't handle it because robustness of OSPF can handle it. Sometime, only when some adjacencies are broken, or routes have some problem, the administrator will debug it and find the number of some bad packet counter will be very big, Base on it, the problem can be solved and the service will be restored. I suggest maybe we can provide some counter in OSPF.

So, you are asking for an instance level counter for rx-bad-packet?



5. Page 39: In the container opaque, there are some define about "router-address-TLV", "link-TLV" and some other named TLV, do we need "when" statement?

I’m not sure why we’d want to add “when” conditions. These are operational state TLVs.


6. Page 58: About the leaf of "Hello-Interval" and "Dead-Interval". Do we need define the default value? Because this kind of parameter can affect the adjacency establish. Sometime the adjacency maybe cannot be established because the default value is different. Maybe a explicit define is good choice.

We will discuss. Typically these have been implementation specific.


7. Page 75: About te-id of MPLS, it should be defined in OSPF model? Or OSPF quote it from MPLS model?

There has been some discussion of consolidation of common types for routing in a separate model. However, I wouldn’t want to introduce a dependency on an MPLS model for a single type.

Thanks,
Acee




It is all I got.

Yangang.