openconfig/public

Question about ospfv2 link-scoped opaque LSAs

zlei-arista opened this issue · 6 comments

zlei-arista commented

Hi all,

I have a question regarding how link-scoped opaque LSAs are presented in the ospfv2 lsdb model.
Link-scoped LSAs such as grace LSA are originated once per interface. In the current lsdb model, all LSAs are stored under areas, and there aren't any identifiers/fields to distinguish between different interfaces for a link-scoped LSA.

Example scenarios:
1.) We have 2 neighbors, and we enter a graceful restart. We will originate 2 grace LSAs, one for each interface/neighbor, each LSA having the same lsa-type, link-state-id, and advertising-router.
2.) We have 1 neighbor, but connected by multiple parallel links. The neighbor enters a graceful restart. The neighbor will originate multiple grace LSAs, one for each interface connected to us. Then we will receive multiple grace LSAs of the same data, but from different interfaces.

For these scenarios, since each LSA is originated once per interface, there should be multiple copies of the same LSA in ospfv2 lsdb model. Is the current model missing a way to identify the interface for each of these copies?

Thanks in advance!

dplore commented

I think /network-instances/network-instance/protocols/protocol/ospfv2/areas/area/lsdb/lsa-types/lsa-type/lsas/lsa/
link-state-id is what you're looking for? Link state ID in OSPF is intended to represent the interface.

zlei-arista commented

Hi Darren,
From my understanding, the link-state-id of opaque LSAs are formed by a combination of opaque type and opaque ID. According to RFC 3623, grace LSAs have an opaque type of 3 and an opaque ID of 0. This means all grace LSAs have the same link-state-id, 3.0.0.0. I am not sure how we could use that to represent the interface.

dplore commented

Ah, you are correct regarding the grace-lsa format.

It seem like there isn't a way in the OC models to correlate between a 'grace-lsa' and the interface it was received on. Is this needed? What is the use case?

In case it is helpful, there is /network-instances/network-instance/protocols/protocol/ospfv2/areas/area/lsdb/lsa-types/lsa-type/lsas/lsa/opaque-lsa/grace-lsa/tlvs/tlv/state/ip-interface-address which would help to uniquely identify the neighbor which is restarting.

zlei-arista commented

If we received multiple copies of the same link-scoped LSA through different interfaces, we want a way to distinguish between them. It seems "buggy" to have the same LSA with the exact same info taking up multiple entries in the OC states.

Also, in the current model, there are ways to correlate an area-scope LSA with an area and to correlate an AS-scoped LSA with a protocol instance. I think it would be good to be able to correlate a link-scope LSA with the interface it is received on, too. This could just be a field indicating the interface or another layer under area lsdb specifically for link-scope LSAs.

The ip-interface-address could be helpful but this TLV is not mandatory. Per RFC 3623, it is required on broadcast, NBMA and Point-to-MultiPoint segments but not on other network types.

dplore commented

Looking at this some more, is interface the right attribute to model? This is not an attribute on the wire in OSPF. Can you provide 2+ examples of implementations that expose the interface an LSA is received on?

Would modeling /network-instances/network-instance/protocols/protocol/ospfv2/areas/area/lsdb/lsa-types/lsa-type/lsas/lsa/state/advertising-router work for your use case? I realize in the parallel link scenario, I would expect the advertising router to be the same on multiple LSAs.

zlei-arista commented

You are correct, the interface is not an attribute on the wire in OSPF. But since it is the interface that the LSA is received on, I think the receiver should be aware of what the attribute is.

As for examples, there is an SNMP MIB standard across implementations that exposes the receiving interface of a link-scope LSA.
In the OSPFv2 MIB (RFC4750), there is a table ospfLocalLsdbTable dedicated for type 9 link-local LSAs. As part of the key for the table, it contains ospflocalLsdbIpAddress and the ospfLocalLsdbAddressLessIf.

  • ospflocalLsdbIpAddress is the IP address of the interface in which the LSA was received on, if it is a numbered interface.
  • ospfLocalLsdbAddressLessIf is the interface index of the receiving interface, if it is an unnumbered interface.

The combination of these 2 attributes should be able to identify any receiving interface. I guess this means "interface" might require more than 1 attribute/field.
Note that the ospflocalLsdbIpAddress here is different than the ip-interface-address TLV, since ip-interface-address is the sender's IP address.