Hi Yangang, See a couple inlines.
From: Yangang <[email protected]<mailto:[email protected]>> Date: Sunday, August 21, 2016 at 3:49 AM To: Acee Lindem <[email protected]<mailto:[email protected]>>, OSPF WG List <[email protected]<mailto:[email protected]>> Subject: 答复: [OSPF] Some doubts about OSPF YANG model. Hi, Acee: Please check my comments below. Thanks. 发件人: Acee Lindem (acee) [mailto:[email protected]] 发送时间: 2016年8月20日 23:20 收件人: Yangang; [email protected]<mailto:[email protected]> 主题: Re: [OSPF] Some doubts about OSPF YANG model. 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 <[email protected]<mailto:[email protected]>> on behalf of Yangang <[email protected]<mailto:[email protected]>> Date: Saturday, August 20, 2016 at 10:23 AM To: OSPF WG List <[email protected]<mailto:[email protected]>> 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). [Yangang]: It is right. So I think maybe no need define these leafs in the YANG model. 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. [Yangang]: Oh, Maybe it need be discussed. Why the OSPF TE extension, IGP LDP SYNC is the feature, but OSPF BFD is a module, I also have this doubt. We intend to remove the separate BFD module and retain the BFD leaf. 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? [Yangang]:Maybe the instance level counter is enough, But I think it is not only for rx-bad-packet, but also if-config-error. We’ll add these and look at the others at the global level. I know some OSPF implementations include these counters in the show commands. 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. [Yangang]:In page 38, there are some “when” defines about the router LSA, so I think maybe this kind of statement also need be defined for opaque-LSA, like: container summary { when "../../header/type = 3 or " + "../../header/type = 4" { description "Only applies to Summary LSAs."; } ………. container external { when "../../header/type = 5 or " + "../../header/type = 7" { description "Only applies to AS-external LSAs and NSSA LSAs."; } We decided that operational state didn’t need to be validated but I think we’ll discuss a bit more. 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. We decided not to specify defaults in the model since the RFC only provides example defaults. 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. [Yangang]:Understand, maybe we can have more discussion. This discussion is ongoing in the YANG Routing DT, i.e., a saparate ietf-routing-types module. Thanks, Acee Thanks, Acee It is all I got. Yangang.
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
