Passive Interface Attribute

Passive interfaces are used commonly within an operators enterprise or service provider networks. One of the most common use cases for passive interface is in a data center Layer 2 and Layer 3 TOR(Top of Rack) switch where the inter connected link between the TOR switches and uplink to the Core switch are only a few links and a majority of the links are Layer 3 VLAN Switched Virtual Interface Default Gateways trunked betwen the TOR switches servicing Layer 2 broadcast domains. In this scenario all the VLANs are made passive as it is recommended to limit the number of network LSAs between routers and switches to avoid unnecessary hello processing overhead. Another common use case is an inter-as routing scenario where the same routing protocol but diffent IGP instance is running between the adjacent BGP domains. Using passive interface on the inter-as tiepoint connections can ensure that prefixes contained within a domain are only reachable within the domain itself and not allow the link state database to be merged between domain which could result in undesirable consequences. For operator which runs different IGP domains that interconnect with each other, there is desire to obtain the inter-as topology information as described in . If the router that runs BGP-LS is within one IGP domain and can distinguish passive interfaces from other interfaces with transit neighbor, it is then easy for the router to report these passive links using BGP-LS to centralized PCE controller. But OSPF and ISIS have no capabilities to flag such passive interface. This document defines the protocol extension for OSPF and ISIS for the prefix that comes from passive interface.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Figure 1 illustrates the topology scenario when ISIS/OSPF is running in different domain. B1, B3 are border routers within IGP domain A, B2, B4 are border routers within domain B. S1-S4 are the internal routers within domain A, T1-T4 are the internal routers within domain B. The two domain are interconnected via the links between B1/B2 and B3/B4. Passive interfaces are enabled in the links between B1/B2 and B3/B4 respectively. For domain A and B, the S2/T1 router that runs ISIS/OSPF can't extract the passives links from the normal links and report it to PCE controller via the BGP-LS protocol. They can only judge the passive interfaces from other characteristics, such as no IGP neighbor on this link. Such judgement can extract these passive links but it is not accurate, because it covers also the situation when there are some issues to establish the ISIS adjacency/OSPF neighbor but not the passive interface. For passive interfaces that are used in the edge router or switches which connects the server, for example in the router S1/S4 and T2/T4 in Figure 1, knowing these interfaces are correctly configured will also benefit the management of them. The method to label these passive interfaces explicitly is necessary then.

defines the "IPv4/IPv6 Extended Reachability Attribute Flags" sub-TLV to advertise the additional flags associated with a given prefix advertisement. We propose new bit(Bit 5 is desired) to be assigned by the IANA for the passive interface attribute, as illustrated in Figure2:

When the interfaces on one router be configured as the passive interface, the U-flag bit will be set in the "IPv4/IPv6 Extended Reachability Attribute Flags" sub-TLV. This sub-TLV will be included in the TLV 135, TLV 235, TLV 236 and TLV 237 as necessary and be flooded within the ISIS domain.

defines the "Prefix Option field" in "Intra-Area-Prefix-LSAs" LSA to describe the prefix capabilities. The bits in this field can be defined to flag the prefix is coming from the passive interface. We propose new bit(Bit 1 is desired) to be assigned by the IANA for the passive interface, as illustrated in Figure 3:

When the interfaces on one router be configured as the passive interface, the U-flag bit will be set in the "Prefix Option field" of Intra-Area-Prefix-LSAs. The router receives such advertisement can then easily distinguish the passive interfaces from the normal interface, and reports them to the PCE controller if it run the BGP-LS protocol.

Security concerns for ISIS are addressed in and Advertisement of the additional information defined in this document introduces no new security concerns.

IANA is requested to allocate the P-bit (bit position 5 is desired) from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.

Thanks Shunwan Zhang, Tony Li, Les Ginsberg and Robert Raszuk for their suggestions and comments on this idea.