[OSPF] 答复: Some doubts about OSPF YANG model.

[Yangang <[e-mail]>]

Hi, Acee:

Please check my comments below.

Thanks.

发件人: Acee Lindem (acee) [mailto:[e-mail]]
发送时间: 2016年8月20日 23:20
收件人: Yangang; [e-mail]
主题: 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 <[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).

[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.


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.


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.";
      }


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.

[Yangang]:Understand, maybe we can have more discussion.


Thanks,
Acee




It is all I got.

Yangang.