OSPFv3 Interface ID

[Mitrixsen]

Hello, everyone.

I understand that OSPFv3 separates links from prefixes and purposely moves the prefix information from T1/T2 LSAs into T8/T9.

The RFC states the following:

o  The Hello packet now contains no address information at all.
      Rather, it now includes an Interface ID that the originating
      router has assigned to uniquely identify (among its own
      interfaces) its interface to the link.  This Interface ID will be
      used as the network-LSA's Link State ID if the router becomes the
      Designated Router on the link.

I'm not quite sure whether I understand the purpose of this interface ID. Each router generates this locally and assigns it to an interface (which it then informs its neighbors about), right? The RFC states that the purpose of this is to uniquely identify the interface. However, why does it need an Interface ID to uniquely identify it? Aren't all interfaces unique in OSPF? For example, G0/0/0 is not the same as G0/0/1, why the need to assign an ID to them?

Thank you
David

[M02@rt37]

Hello @Mitrixsen 

Interface names are purely local to a device. Ospf v3 deliberately remove addresses from Hellos to decouple links from prefixes and support multi AF routing.

[Cristian Matei]

Hi,

   Multi AF capability has nothing to do with decision of removing addresses from HELLO packets or the interface ID concept, meaning there is no dependency in between.

Thanks,

Cristian. 

[Cristian Matei · Accepted solution]

Hi,

     As you know, OSPFv3 has moved towards a more scalable internal architecture similar to IS-IS, while keeping OSPFv2 features and functions, where possible. The first phase was achieved through RFC2740 / RFC 5340, which, among other things has decoupled topological information (Dijkstra's graph of nodes build by nodes / vertices and links / edges) from database information ( data / prefix reachability). These RFC's have been further updated by RFC 8362 which changes OSPF LSA structure by encoding existing LSA information in TLV tuples, which now completes the work of having IS-IS and OSPF very similar in structure.

     Back to your question, as OSPFv3 uses Type 1 / 0x2001 and Type 2 / 0x2002 LSA's to just build the graph of nodes within a specific area, without any prefix information being attached to these LSA's, the algorithm needs a way to identify each node / vertices and each link /edge at both ends; while the node is still identified by the OSPFv3 router-ID, the link / edge is identified by the interface ID, and for the graph to be build there needs to be an interface-ID for both ends of the link. Both router ID and interface ID are pure data structure relevant to the mathematical algorithm to function without having any dependency on the actual reachability information over the graph of nodes.

    As the router-ID is mandatory to be unique within an area (so the area graph of nodes can be build via uniquely identifiable nodes) and recommended across the entire OSPF domain (not to run into issues when dealing with multiple ASBR's attached to different areas), the interface-ID needs to be unique per interface per node, thus any given OSPFv3 interface on a router needs a unique interface-ID (so that each link attached to a node has a unique identifier for the graph of nodes to distinguish between different paths towards same node); so, on the same segment, two routers can end up with same interface-ID, however having two segment between two routers, these two segments needs unique identifiers on each side, otherwise the algorithm cannot distinguish between the two paths). Why isn't OSPFv3 using the actual interface value, e.g GigabitEthernet0/0/0 as the interface ID, because it's  deterministic to work with a well defined algorithm of defining an interface ID, rather than using whatever the actual value of the interface would be today or tomorrow. 

  Once this is understood, it will also make sense in which OPFv3 packets is the interface ID value attached to and for which scope: HELLO packets, router LSA / 0x2001, network LSA / 0x2002, link-local LSA / 0x0008.

Thanks,

Cristian.

[M02@rt37]

Thanks for that explanation Christian.

Minor nuance...If you permit it... Interface IDs uniquely identify link endpoints ; but they exist primarily to support OSPF’s protocol design and LSA semantics, not because dijkstra intrinsically needs an “interface ID” concept...

[Cristian Matei]

Hi,

    Yes, we're both saying the same thing; interface ID exists to support OSPF's protocol design and LSA semantics, so that it can be mapped on Dijkstra's algorithm, not because Dijkstra's requires the concept of interface ID, as the mapping direction is from OSPF towards the algorithm, not the other way around.

Thanks,

Cristian.