UPA and BGP PIC Edge in Summarized SRv6 Domains

1

(% class="row" %)

2

(((

3

(% class="col-xs-12 col-sm-8 test-report-content" %)

(((

----

Control-plane scalability is the primary driver of locator and prefix summarization in SRv6 multi-domain networks. In large deployments, each PE advertises its SRv6 locator and service-related prefixes. If every individual prefix were distributed across all domains, the IGP database size, SPF computation load, and FIB state would increase significantly. To limit this growth, domains advertise only summarized locators at their boundaries. External domains maintain reachability only to the summarized prefix, while individual PE locators remain visible only within their local domain.

8

9

[[~[~[Figure 84: SRv6 Unreachable Prefix Announcement~>~>image:486179564591906817_SRv6 Unreachable Prefix Announcement.png~|~|alt="Figure 84"~]~]>>attach:486179564591906817_SRv6 Unreachable Prefix Announcement.png||target="_blank"]]

10

11

We verified correct summarization by confirming that nodes outside the domain installed only the summarized locators in their FIB and successfully resolved them into functional forwarding paths. We then generated end-to-end traffic toward individual PE destinations and confirmed that traffic entered the domain via the summarized locator and reached the intended egress PE through internal routing.

12

13

14

(% class="table-bordered" %)

15

|=ABR|=PE|=Traffic Generator

|(((

Ciena 8192,

Cisco 8711-32FH-M,

Ericsson RAN Connect 6682,

HPE MX204,

Nokia 7750 SR-1,

ZTE ZXR10 M6000-4SE

)))|(((

Arista 7280R4,

Ciena 5164,

Cisco 8011-4G24Y4H-I,

Cisco 8711-32FH-M,

Cisco 8712-MOD-M,

Cisco ASR-9902,

Ericsson RAN Connect 6682,

31

Ericsson Router 6678,

HPE ACX7020,

HPE ACX7024,

HPE MX304,

HPE PTX10002-36DD,

Keysight IxNetwork,

Nokia 7250 IXR-e2,

Nokia 7730 SXR-1x-44s,

39

ZTE ZXCTN 6120H-S,

40

ZTE ZXR10 M6000-2S16,

41

ZTE ZXR10 M6000-4SE,

42

ZTE ZXR10 M6000-3S Plus,

43

ZXCTN 6120H-E,

44

Raisecom RAX721-T-4C24,

45

Raisecom iTN8800-A

46

)))|Keysight IxNetwork

47

48

Table 57: UPA and BGP PIC Edge in Summarized SRv6 Domains - µSID-Locator Summarization

49

50

51

The limitation of this approach appears when a single egress PE becomes unreachable inside the summarized domain. Since the summary route remains valid, ingress PEs in other domains still see the aggregate locator as reachable. The IGP does not provide any indication that one specific PE behind the summary has failed. As a result, traffic may continue to be forwarded toward the failed egress until another mechanism reacts.

52

53

Unreachable Prefix Announcement (UPA), as defined in RFC9929, solves this issue by allowing specific prefixes to be explicitly marked as unreachable in the IGP. This signaling is independent of the summarized locator advertisement. The summary remains installed, but the affected prefixes are identified as unusable.

54

Using BGP Prefix Independent Convergence (PIC) Edge, we configured ingress PEs with primary and backup BGP paths toward multiple egress PEs. Under normal operation, the ingress PEs forwarded traffic through the primary egress. We intentionally failed the primary path toward the egress PE, which caused the ABR to generate a UPA indication for the affected prefixes. When the primary egress signaled unreachable prefixes through UPA, the ingress PEs immediately removed those prefixes from their forwarding decision and relied on BGP PIC to redirect traffic to the backup egress without waiting for full BGP reconvergence.

55

56

57

(% class="table-bordered" %)

58

|=ABR|=Ingress PE|=Traffic Generator

59

|Ericsson RAN Connect 6682|(((

60

Cisco 8712-MOD-M,

61

Ericsson Router 6678,

62

HPE MX304

63

)))|Keysight IxNetwork

64

|HPE MX204|(((

65

Cisco 8712-MOD-M,

66

Ericsson Router 6678,

67

HPE MX304

68

)))|Keysight IxNetwork

69

70

Table 59: UPA and BGP PIC Edge in Summarized SRv6 Domains - µSID-UPA

(% class="table-bordered" %)

|=PE

|(((

Cisco 8712-MOD-M,

Ericsson Router 6678,

HPE MX304

)))

Table 58: UPA and BGP PIC Edge in Summarized SRv6 Domains - µSID-BGP PIC Edge

83

84

85

During testing, we encountered an interoperability issue with some implementations. According to Section 3.2 of the RFC, IS-IS may advertise a prefix with a metric higher than 0xFE000000 for various reasons. Although IS-IS defines how to treat such high metrics, the standard introduces an explicit signaling mechanism to distinguish a true Unreachable Prefix Announcement (UPA) from other cases where a high metric is used. For this purpose, two new bits were defined in the IPv4/IPv6 Extended Reachability Attribute Flags, including the U-Flag (Bit 5), which indicates that the prefix is unreachable.

86

87

In these implementations, the ABR generated an advertisement with a very high metric but did not set the U-Flag to explicitly indicate an unreachable prefix (non-compliant with RFC 9929). Because the ingress PEs relied on the presence of the defined flag to recognize a UPA condition, they did not interpret the high-metric advertisement as an unreachable signal. As a result, the ingress PEs did not trigger the expected BGP PIC Edge reaction, and traffic continued to follow the primary path despite the ABR’s attempt to signal a loss of reachability.

88

89

However, the ingress node's behavior remains compliant with the RFC. The specification states that the handling of UPA signals by the receiving node is optional and outside the scope of the document. Therefore, an implementation that responds only to explicit UPA signaling—specifically when the U-Flag is set—remains within the scope of the standard. In the absence of the U-Flag, a high-metric advertisement alone does not necessarily indicate an unreachable prefix and, as a result, may not activate mechanisms such as BGP PIC Edge.

90

91

(% id="prev-next-links" %)

92

|[[< Previous>>doc:SRv6 Flexible Algorithm]]|[[Next ~>>>doc:SRv6 Policies with Explicit Paths]]

93

)))

94

95

(% class="col-xs-12 col-sm-4 test-report-sidebar" %)

96

(((