SRv6 BSID with Notification Message Relay
draft-liu-spring-srv6-bsid-relay-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Yao Liu | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-spring-srv6-bsid-relay-00
SPRING Y. Liu
Internet-Draft ZTE Corporation
Intended status: Standards Track 3 July 2026
Expires: 4 January 2027
SRv6 BSID with Notification Message Relay
draft-liu-spring-srv6-bsid-relay-00
Abstract
This document defines a new SRv6 Endpoint behavior,
End.B6.Encaps.Relay, for Binding SID (BSID) nodes in SRv6 networks.
The behavior enables BSID nodes to relay tunnel-internal notification
messages, such as ICMPv6 errors and congestion notifications, back to
the upstream tunnel source node through a mapping mechanism.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Liu Expires 4 January 2027 [Page 1]
Internet-Draft SRv6 BSID with Notification Relay July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. End.B6.Encaps.Relay: Endpoint Bound to an SRv6 Policy with
Notification Relay . . . . . . . . . . . . . . . . . . . 5
4. Application Example . . . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
5.1. Mapping Table Management . . . . . . . . . . . . . . . . 9
5.2. Selective Relay . . . . . . . . . . . . . . . . . . . . . 9
5.3. Path Orchestration Considerations . . . . . . . . . . . . 9
5.4. Scope of the Solution . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The Segment Routing (SR) Architecture [RFC8402] specifies a mechanism
to steer packets through an ordered list of segments. As in
[RFC8402], the Binding SID (BSID) is bound to an SR Policy,
instantiation of which may involve a list of SIDs.
[RFC8986] defines the SRv6 Network Programming concept and specifies
the base set of SRv6 behaviors. In [RFC8986], End.B6.Encaps and
End.B6.Encaps.Red are defined as instantiations of a Binding SID.
When a node (BSID node) receives a packet whose destination address
matches a local BSID, it encapsulates the packet with a new outer
IPv6 header and an optional Segment Routing Header (SRH), and then
forwards the packet to the SRv6 policy associated with that BSID.
According to [RFC2473], the tunnel entry-point node MUST use one of
its own routable IPv6 addresses as the source address of the outer
IPv6 header. Since the BSID behavior is essentially a form of IPv6-
in-IPv6 tunneling, it MUST also comply with this general requirement
of [RFC2473]. This means that the BSID node, acting as the tunnel
entry-point, MUST set the source address of the newly encapsulated
outer IPv6 header to an IPv6 address that belongs to itself.
In SRv6 tunneling scenarios, various types of tunnel-internal
notification messages may be generated by nodes inside the tunnel and
need to be delivered to the source of the original packet. Examples
of such messages include:
Liu Expires 4 January 2027 [Page 2]
Internet-Draft SRv6 BSID with Notification Relay July 2026
* ICMPv6 error messages, such as Time Exceeded (Type 3), Destination
Unreachable (Type 1), Packet Too Big (Type 2), and Parameter
Problem (Type 4), as defined in [RFC4443].
* Network congestion notification messages, which may be generated
by nodes experiencing congestion or processing overload. Such
messages inform the source node of the congestion condition,
enabling it to adjust its transmission behavior accordingly.
For ICMP error messages, [RFC2473] defines a relay procedure. When
an error occurs inside a tunnel, the ICMP error message is first sent
to the tunnel entry-point node (since the entry-point is the source
of the outer IPv6 header). Upon receiving the ICMP error, the tunnel
entry-point node extracts the invoking packet from the ICMP payload,
decapsulates it to retrieve the original packet, and then relays a
new ICMP error message to the original source address extracted from
the original packet. However, in SRv6 networks, the ICMPv6 error
message may contain both outer tunnel IPv6 extension headers (e.g.,
SRH, Hop-by-Hop Options, Destination Options) as well as inner IPv6
extension headers of the original packet. The relay approach in
[RFC2473] may be unsuitable in some scenarios:
* Due to the MTU constraints of ICMPv6 error messages [RFC4443], the
IPv6 Source Address field of the inner original packet may not be
fully included in the ICMPv6 error payload. As a result, the
relay node is unable to retrieve the source address of the
original packet, making the relay procedure infeasible.
* Since the outer IPv6 extension headers have variable length,
parsing through the outer encapsulation to locate the inner IPv6
header imposes processing complexity on the relay node. For some
devices, such deep header parsing cannot be performed efficiently.
For network congestion notification messages, similar challenges
exist:
* Some network congestion messages need to be delivered to the host
side. However, if the host source address extracted from the
packet payload is used directly as the destination address of the
notification message, the route may be unreachable from the
congestion reporting node. Therefore, it may still be necessary
to send the notification message to the headend node of the path
first, and then have the headend node forward it to the host. In
this case, the same BSID node relay issue may arise.
Liu Expires 4 January 2027 [Page 3]
Internet-Draft SRv6 BSID with Notification Relay July 2026
* Congestion notification messages have various formats. Some
congestion notification messages do not include all the packet
header information. In such cases, the BSID node is unable to
extract the original source address information from the
congestion notification message.
* Even if the congestion notification message, similar to ICMPv6
messages, includes as much of the original packet information as
possible, it will still face the same issues as the ICMPv6 relay
case described above. This is particularly problematic in
scenarios where congestion notification messages need to be
delivered as quickly as possible, as the deep parsing required to
locate the original source address introduces additional
processing latency, adversely affecting transmission performance.
To address the above issues, this document defines a new SRv6
behavior to be used on the BSID node. This behavior enables the BSID
node to relay ICMPv6 error messages and other tunnel-internal
notification messages to the original source node of the SR path.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terminology from [RFC8402], [RFC8754], and
[RFC8986]. In particular:
SRv6: Segment Routing over IPv6
SID: Segment Identifier
SRH: Segment Routing Header
BSID: Binding SID
End.B6.Encaps: the BSID behavior defined in Section 4.13 of
[RFC8986]
This document defines the following new term:
End.B6.Encaps.Relay: a variant of End.B6.Encaps that enables the
BSID node to relay tunnel-internal notification messages to the
upstream tunnel source node through a stateful mapping mechanism.
Liu Expires 4 January 2027 [Page 4]
Internet-Draft SRv6 BSID with Notification Relay July 2026
3. End.B6.Encaps.Relay: Endpoint Bound to an SRv6 Policy with
Notification Relay
In this section, a new SRv6 Endpoint Behavior is proposed for SRv6
based notification relay in nested tunnel scenarios.
The "Endpoint Bound to an SRv6 Policy with Notification Relay"
behavior ("End.B6.Encaps.Relay" for short) is a variant of the
End.B6.Encaps behavior as defined in [RFC8986]. Its main use is to
enable the BSID node to relay tunnel-internal notification messages
(e.g., ICMPv6 errors, congestion notifications, or other notification
messages) to the upstream tunnel source node.
The End.B6.Encaps.Relay behavior addresses the notification return
path breakage issue in nested SRv6 tunnels, where the standard
End.B6.Encaps behavior overwrites the outer IPv6 source address and
consequently prevents downstream tunnel-internal notification
messages from reaching the original source. By maintaining a local
mapping between a dynamically allocated argument and the upstream
source address, the End.B6.Encaps.Relay behavior ensures that tunnel-
internal notification messages can be relayed back to the original
source through layer-by-layer relay.
Any SID instance of this behavior is associated with an SR Policy B
and a source address A. The SID follows the LOC:FUNCT:ARG format as
defined in [RFC8986]. The ARG field serves as a dynamically
allocated session identifier that uniquely identifies each
encapsulation session.
When N receives a packet whose IPv6 DA is S and S is a local
End.B6.Encaps.Relay SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
Liu Expires 4 January 2027 [Page 5]
Internet-Draft SRv6 BSID with Notification Relay July 2026
interrupt packet processing, and discard the packet.
S11. }
S12. }
S13. If (ARG == 0) {
S14. Record the source address of the received IPv6 header as ORIG_SA.
S15. If (local relay table does NOT contain ORIG_SA) {
S16. Allocate a new ARG value, NEW_ARG.
S17. Create a mapping entry (NEW_ARG -> ORIG_SA) in the local
relay table.
S18. } Else {
S19. Retrieve NEW_ARG associated with ORIG_SA from the local
relay table.
S20. }
S21. Push a new IPv6 header with its own SRH containing B.
S22. Update the ARG field of N to NEW_ARG, and set it as the outer
IPv6 SA.
S23. Set the outer IPv6 DA to the first SID of B.
S24. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields per [RFC2473] and
[RFC6437].
S25. Submit the packet to the egress IPv6 FIB lookup for
transmission.
S26. }
S27. If (ARG != 0) {
S28. If (local relay table does not contain this ARG) {
S29. Interrupt packet processing and discard the packet.
S30. }
S31. Retrieve ORIG_SA from the local relay table using the ARG.
S32. If (the received packet is a message that needs to be relayed) {
S33. Decapsulate the received packet and push a new IPv6 header.
S34. Set the IPv6 SA of the resulting packet to A.
S35. Set the IPv6 DA to ORIG_SA.
S36. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields per [RFC2473] and
[RFC6437].
S37. Submit the packet to the egress IPv6 FIB lookup for
transmission.
S38. } Else {
S39. Process the packet locally.
S40. }
S41. }
End.B6.Encaps.Relay SIDs MAY be allocated by the network nodes and
announced to the network controller with the information of the ARG
length using IGP [RFC1195] [RFC2328] or BGP-LS [RFC9552].
Alternatively, End.B6.Encaps.Relay SIDs MAY be assigned by a
Liu Expires 4 January 2027 [Page 6]
Internet-Draft SRv6 BSID with Notification Relay July 2026
centralized network controller and advertised to the network nodes
through Netconf/YANG [RFC6241] [RFC6020], BGP [RFC4271], or PCEP
[RFC5440].
With the information of End.B6.Encaps.Relay SIDs, the network
controller or headend nodes could use End.B6.Encaps.Relay SIDs
together with other types of SRv6 SIDs to build SRv6 SID lists that
support reliable notification message relay in nested tunnel
scenarios.
4. Application Example
This section provides an application example of the
End.B6.Encaps.Relay behavior defined in Section 3. It shows how the
behavior enables relay of ICMPv6 error messages generated inside a
BSID tunnel back to the original headend of the SR Policy including
this BSID.
The reference topology is shown in Figure 1, where:
+---+ +---+ +---+ +---+ +---+ +---+
|PE1|--|R1 |--|T1 |--|R2 |--|R3 |--|PE2|
+---+ +---+ +---+ +---+ +---+ +---+
| |
+---+ +---+
|CE1| |CE2|
+---+ +---+
Figure 1: Reference Topology
Step 1: Encapsulation at PE1
* CE1 sends packets to CE2.
* PE1 performs SRv6 function H.Encaps with SRv6 Policy, and the
corresponding SID list is <SID-R1, BSID-T1, SID-PE2>, wherein
SID-T1 is an End.B6.Encaps.Relay BSID instantiated on node T1
which is associated with an SR Policy <SID-T2, SID-T3> and its
argument is set to 0.
* Packet leaving PE1: IPv6<SA=add-PE1, DA=SID-R1> SRH<SID-R1, BSID-
T1, SID-PE2> payload.
Step 2: End.B6.Encaps.Relay Processing
Liu Expires 4 January 2027 [Page 7]
Internet-Draft SRv6 BSID with Notification Relay July 2026
* When the packet arrives at T1, based on End.B6.Encaps.Relay BSID
SID-T1 (ARG=0), T1 records the source address of the received IPv6
header (i.e., add-PE1), and checks whether the local relay table
already contains add-PE1.
* Since this is a new session, T1 allocates a new ARG value, e.g.,
0x1001.
* T1 creates a mapping entry in the local relay table: (0x1001 ->
add-PE1).
* T1 pushes a new IPv6 header with its own SRH containing the SRv6
Policy towards PE2 with the outer SA set to BSID-T1' (generated
based on SID-T1 with ARG=0x1001) and the outer IPv6 DA = first SID
of the policy <SID-T2, SID-T3>.
* Packet leaving T1: IPv6<SA=BSID-T1', DA=SID-T2> SRH<SID-T2, SID-
T3> IPv6<SA=add-PE1, DA=BSID-T1> SRH<SID-R1, SID-T1, SID-PE2>
payload.
Step 3: ICMP Error Generation inside BSID Tunnel
* At T2, an error condition occurs, e.g., the Hop Limit expires. As
per [RFC4443], T2 generates an ICMPv6 error message. The
destination address of the ICMP error is set to the source address
of the invoking packet, which is BSID-T1', and is sent to node T1.
* Packet leaving T2: IPv6<SA=add-T2, DA=BSID-T1'> ICMPv6.
Step 4: ICMP Error Relay at T1
* When the packet arrives at T1, based on End.B6.Encaps.Relay BSID
SID-T1' (ARG=0x1001), T1 looks up the local relay table with
ARG=0x1001 and retrieves the original source address add-PE1.
* T1 decapsulates the received packet and pushes a new IPv6 header,
with DA set to add-PE1 and SA set to a suitable local address
(e.g., add-T1), and forwards it to PE1 based on the DA.
* Packet leaving T1: IPv6<SA=add-T1, DA=add-PE1> ICMPv6.
5. Operational Considerations
Liu Expires 4 January 2027 [Page 8]
Internet-Draft SRv6 BSID with Notification Relay July 2026
5.1. Mapping Table Management
The End.B6.Encaps.Relay behavior relies on a local mapping table that
stores associations between dynamically allocated ARG values and the
upstream source addresses. To prevent unbounded growth of the
mapping table, an implementation SHOULD provide mechanisms for
managing table entries.
An implementation MAY support a configurable timer for each mapping
entry. When a mapping entry remains inactive for a period exceeding
the configured timer, the entry SHOULD be removed and the associated
ARG value SHOULD be recycled for future allocations. The default
timer value is implementation specific and MAY be configured by the
network operator based on the expected session duration and traffic
patterns.
Additionally, an implementation MAY support a configurable maximum
number of mapping entries. When the table reaches the maximum
capacity, new session establishment requests MAY be rejected, or the
implementation MAY replace the oldest entries based on a configurable
policy. The choice of policy is implementation specific and out of
scope of this document.
5.2. Selective Relay
An implementation of the End.B6.Encaps.Relay behavior MAY support
selective relay based on configurable policies. For example, a
network operator may configure the End.B6.Encaps.Relay BSID node to
relay only specific types of tunnel-internal notification messages,
such as ICMPv6 error messages (e.g., Time Exceeded, Destination
Unreachable, Packet Too Big, Parameter Problem) while processing
other types of messages locally or discarding them.
5.3. Path Orchestration Considerations
Not all SRv6 paths that include BSIDs require the End.B6.Encaps.Relay
behavior. When orchestrating SR paths, the network controller SHOULD
select the appropriate BSID type based on the requirements of the
path.
If the path requires that tunnel-internal notification messages
(e.g., ICMPv6 errors) generated inside the BSID tunnel be relayed to
the upstream tunnel source node, the controller SHOULD use an
End.B6.Encaps.Relay SID for that path. If such relay capability is
not required, the controller MAY use the standard End.B6.Encaps SID
as defined in [RFC8986] to reduce state requirements on the BSID
node.
Liu Expires 4 January 2027 [Page 9]
Internet-Draft SRv6 BSID with Notification Relay July 2026
5.4. Scope of the Solution
The End.B6.Encaps.Relay behavior defined in this document addresses
the relay of tunnel-internal notification messages from inside a BSID
tunnel back to the upstream tunnel source node. It does not address
the subsequent delivery of such notifications from the upstream
tunnel source node to the final host or customer edge device.
For example, in VPN scenarios where ICMPv6 errors need to be
delivered to customer edge devices, the End.B6.Encaps.Relay behavior
can be used in conjunction with the ICMP error handling mechanisms
defined in [I-D.varhal-6man-icmp-srv6-vpn], which specifies how an
ingress PE processes ICMP error messages and forwards them to the
host.
6. Security Considerations
The relay of ICMPv6 error messages follows the model defined in
[RFC2473] and [RFC4443]. Implementations SHOULD apply standard ICMP
rate limiting to prevent ICMP flooding attacks.
The security considerations of [RFC8402], [RFC8754], and [RFC8986]
also apply to this specification. This document does not introduce
additional security threats beyond those already present in the SRv6
architecture and the underlying IPv6 and ICMPv6 protocols.
7. IANA Considerations
This document defines a new SRv6 Endpoint behavior called
End.B6.Encaps.Relay.
IANA is requested to allocate the following code point for
End.B6.Encaps.Relay from the "SRv6 Endpoint Behaviors" sub-registry
in the "Segment-routing with IPv6 data plane (SRv6) Parameters"
registry:
+=======+======+=====================+===============+
| Value | Hex | Endpoint Behavior | Reference |
+=======+======+=====================+===============+
| TBA1 | TBA1 | End.B6.Encaps.Relay | This document |
+-------+------+---------------------+---------------+
Table 1: SRv6 Endpoint Behaviors Registry
8. References
8.1. Normative References
Liu Expires 4 January 2027 [Page 10]
Internet-Draft SRv6 BSID with Notification Relay July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
8.2. Informative References
[I-D.varhal-6man-icmp-srv6-vpn]
Varga, B. and J. M. Halpern, "ICMP Error Handling for VPNs
in SRv6 Networks", Work in Progress, Internet-Draft,
draft-varhal-6man-icmp-srv6-vpn-02, 24 June 2026,
<https://datatracker.ietf.org/doc/html/draft-varhal-6man-
icmp-srv6-vpn-02>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
Liu Expires 4 January 2027 [Page 11]
Internet-Draft SRv6 BSID with Notification Relay July 2026
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Author's Address
Yao Liu
ZTE Corporation
Nanjing
China
Email: liu.yao71@zte.com.cn
Liu Expires 4 January 2027 [Page 12]