================================================================================ command: find rfc -type f -name "*.xml" -exec xmllint --xpath '//li[*[1][self::ul or self::ol]]' {} \; -print 2>/dev/nul format: ================================================================================

L3 Neighbor System ID + pseudonode ID (7 octets)

Flags:

1-octet field of the following flags:

- 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| | +-+-+-+-+-+-+-+-+
- where:
- P-Flag:
  
  When set to 1, one of the sub-TLVs described in immediately follows the flags field. If the P-Flag is set to 0, then none of the sub-TLVs described in are present.
- Other bits:
  
  MUST be zero when originated and ignored when received.

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| | +-+-+-+-+-+-+-+-+

where:

P-Flag:

When set to 1, one of the sub-TLVs described in immediately follows the flags field. If the P-Flag is set to 0, then none of the sub-TLVs described in are present.

Other bits:

MUST be zero when originated and ignored when received.

Length of L2 Bundle Attribute Descriptor (1 octet)
- NOTE: This includes all fields described below.

NOTE: This includes all fields described below.

Number of L2 Bundle Member Descriptors (1 octet)

L2 Bundle Member Link Local Identifiers  (4 * Number of L2 Bundle Member Descriptors octets)

- NOTE: An L2 Bundle Member Descriptor is a Link Local Identifier as defined in .

NOTE: An L2 Bundle Member Descriptor is a Link Local Identifier as defined in .

Sub-TLV(s) A sub-TLV may define an attribute common to all of the bundle members listed, or it may define an attribute unique to each bundle member. Use of these two classes of sub-TLVs is described in the following sections.

SID/Index/Label:

According to the V- and L-Flags, it contains either:
- A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V- and L-Flags MUST be set.
- A 4-octet index defining the offset in the SID/Label space advertised by this router. See . In this case, V- and L-Flags MUST be unset.

A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V- and L-Flags MUST be set.
A 4-octet index defining the offset in the SID/Label space advertised by this router. See . In this case, V- and L-Flags MUST be unset.

SID/Index/Label:

According to the V- and L-Flags, it contains either:
- A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V- and L-Flags MUST be set.
- A 4-octet index defining the offset in the SID/Label space advertised by this router. See . In this case, V- and L-Flags MUST be unset.

A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V- and L-Flags MUST be set.
A 4-octet index defining the offset in the SID/Label space advertised by this router. See . In this case, V- and L-Flags MUST be unset.

rfc/rfc8668.xml

The first approach is called "proxy mode". It requires E and P, but not the PLR, to have the knowledge of the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers, with the link between the proxy node and E having more preferable IGP and TE metrics than the link between the proxy node and P. Therefore, all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate hop but rather as two hops away from the proxy node, via E. The PLR will be able to find a bypass path via P to the proxy node, while the bypass tunnel is actually terminated by P.
The second approach is called "alias mode". It requires P and the PLR, but not E, to have the knowledge of the egress protection schema. E simply advertises the context ID as an IP address. P advertises the context ID and the context label by using a "context ID label binding" advertisement. In both the routing domain and TE domain, the context ID is only reachable via E. Therefore, all egress-protected tunnels destined for the context ID will have E as the tail end. Based on the "context ID label binding" advertisement, the PLR can establish an egress-protection bypass tunnel in several manners (). The "context ID label binding" advertisement is defined as the IGP Mirroring Context segment in and . These IGP extensions are generic in nature and hence can be used for egress protection purposes. It is RECOMMENDED that a similar advertisement be defined for OSPF as well.
The third approach is called "stub link mode". In this mode, both E and P advertise the context ID as a link to a stub network, essentially modeling the context ID as an anycast IP address owned by the two routers. E, P, and the PLR do not need to have the knowledge of the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. Therefore, care MUST be taken for the applicability of this approach to a network.

It may be established by a signaling protocol (e.g., RSVP), with the context ID as the destination. The protector binds the context label to the bypass tunnel.
It may be formed by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it.
It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (), the PLR will have the knowledge of the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, Segment Routing, or another protocol.

The first approach applies when the egress router does not know the service label allocated by the backup egress router. In this case, the egress router sets up the bypass forwarding state as a label push with the outgoing label of the egress-protection bypass tunnel. Rerouted packets will have the egress router's service label intact. Therefore, the protector MUST perform context label switching, and the bypass tunnel MUST be destined for the context ID of the protected egress {E, P} and established as described in . This approach is consistent with egress node protection. Hence, a protector can serve in egress node protection and egress link protection in a consistent manner, and both the co-located protector mode and the centralized protector mode are supported (see Figures and ).
The second approach applies when the egress router knows the service label allocated by the backup egress router, via a label distribution protocol session. In this case, the backup egress router serves as the protector for egress link protection, regardless of the protector of egress node protection, which will be the same router in the co-located protector mode but a different router in the centralized protector mode. The egress router sets up the bypass forwarding state as a label swap from the incoming service label to the service label of the backup egress router (i.e., protector), followed by a push with the outgoing label (or label stack) of the egress link protection bypass tunnel. The bypass tunnel is a regular tunnel destined for an IP address of the protector, instead of the context ID of the protected egress {E, P}. The protector simply forwards rerouted service packets based on its own service label rather than performing context label switching. In this approach, only the co-located protector mode is applicable.

rfc/rfc8679.xml

at high frequency of congestion marking, approximate preservation of the proportion of congestion marks arriving and departing;
at low frequency of congestion marking, approximate preservation of the timing of congestion marks arriving and departing.

rfc/rfc9599.xml

If T's destination address is from the same address family as the OSPF instance associated with the LSDB, then the extensions defined in this document do not apply.
Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destination IP address.
Walk the X-AF IP addresses in the LSDBs of all connected areas. If a matching IP address is found, advertised by router R in area A, then mark the tunnel T as belonging to area A and terminating on tail-end router R. Assign the intra-area SPF cost to reach router R within area A as the IGP cost of tunnel T.

rfc/rfc8687.xml

The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor-seq" SHOULD be processed as follows:
- For cases defined in +cbor-seq, if the fragment identifier resolves per the +cbor-seq rules, then process as specified in +cbor-seq.
- For cases defined in +cbor-seq, if the fragment identifier does not resolve per the +cbor-seq rules, then process as specified in "xxx/yyy+cbor-seq".
- For cases not defined in +cbor-seq, process as specified in "xxx/yyy+cbor-seq".

For cases defined in +cbor-seq, if the fragment identifier resolves per the +cbor-seq rules, then process as specified in +cbor-seq.
For cases defined in +cbor-seq, if the fragment identifier does not resolve per the +cbor-seq rules, then process as specified in "xxx/yyy+cbor-seq".
For cases not defined in +cbor-seq, process as specified in "xxx/yyy+cbor-seq".

rfc/rfc8742.xml

Orange
mohamed.boucadair@orange.com

Christopher_Gray3@cable.comcast.com

rfc/rfc8811.xml

Common aliases include: face.

Common aliases include: consumer, information consumer, data consumer, consumer of the content.

Common aliases include: producer, publisher, information publisher, data publisher, data producer.

Common aliases include: ICN router.

Common aliases include: ICN Data plane, ICN Forwarding.

Common aliases include: Interest forwarding strategy.

Common aliases include: Interest collapsing.

Common aliases include: on-path in-network caching.

Common aliases include: off-path in-network storage.

Common aliases include: repository, repo.

Common aliases include: Interest, Interest message, information request.

Common aliases include: network NACK, Interest return.

Common aliases include: data, data object, content object, content object packet, data message, named data object, named data.

Common aliases include: pointer.

Common aliases include: data name, interest name, content name.

Common aliases include: name segment (as in CCNx).

Common aliases include: implicit digest.

Common aliases include: interest selector, restrictor, interest restrictor.

Common aliases include: prefix.

Common aliases include: Naming scheme, ICN naming scheme, namespace convention.

Common aliases include: hierarchical naming, structured naming.

Common aliases include: chunking.

Common aliases include: directly securing Data packet.

rfc/rfc8793.xml

restarts the HoldTimer and
changes its state to Established.

restarts the HoldTimer,
starts the SendHoldTimer if the SendHoldTime is non-zero, and
changes its state to Established.

(optionally) sends a NOTIFICATION message with the BGP Error Code "Send Hold Timer Expired" if the local system can determine that doing so will not delay the following actions in this paragraph,
logs an error message in the local system with the BGP Error Code "Send Hold Timer Expired",
releases all BGP resources,
sets the ConnectRetryTimer to zero,
drops the TCP connection,
increments the ConnectRetryCounter by 1,
(optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
changes its state to Idle.

rfc/rfc9687.xml

The instance is an array. Otherwise, the error indicator for this case shall have an "instancePath" pointing to the instance and a "schemaPath" pointing to the schema member with the name "elements".
If the instance is an array, then every element of the instance must be accepted by S. Otherwise, the error indicators for this case are the union of all the errors arising from evaluating S against elements of the instance.

rfc/rfc8927.xml

- Registration Packet Format +---------+------------------+----------------+ | | | | | R/D | hash(FQDN) | nSFF_ID | | (1 bit) | (16 bits) | (8 bits) | +---------+------------------+----------------+
  - R/D: 1-bit length (0 for Register, 1 for Deregister)
  - hash(FQDN): 16-bit length for a hash over the FQDN of the SF
  - nSFF_ID: 8-bit length for a system-unique identifier for the SFF related to the SF
- We assume that the pathID towards the NR is known to the nSFF through configuration means.
- The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information, as well as the pathID information being used for communication between nSFFs and NRs. The nSFF locally maintains a mapping of registered FQDNs to IP addresses for the latter using link-local private IP addresses.

Registration Packet Format +---------+------------------+----------------+ | | | | | R/D | hash(FQDN) | nSFF_ID | | (1 bit) | (16 bits) | (8 bits) | +---------+------------------+----------------+
- R/D: 1-bit length (0 for Register, 1 for Deregister)
- hash(FQDN): 16-bit length for a hash over the FQDN of the SF
- nSFF_ID: 8-bit length for a system-unique identifier for the SFF related to the SF

We assume that the pathID towards the NR is known to the nSFF through configuration means.
The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information, as well as the pathID information being used for communication between nSFFs and NRs. The nSFF locally maintains a mapping of registered FQDNs to IP addresses for the latter using link-local private IP addresses.

rfc/rfc8677.xml

The originating router advertises the following ranges:
SR-Cap: range: 100, SID value: 100
SR-Cap: range: 100, SID value: 1000
SR-Cap: range: 100, SID value: 500

rfc/rfc8667.xml

set d_base = +INFINITY
set p_loss = 0
set p_mark = 0
set r_recv = 0
set both t_last and t_curr as current time in milliseconds

obtain current timestamp t_curr from system clock
obtain from packet header sending time stamp t_sent
obtain one-way delay measurement: d_fwd = t_curr - t_sent
update baseline delay: d_base = min(d_base, d_fwd)
update queuing delay: d_queue = d_fwd - d_base
update packet loss ratio estimate p_loss
update packet marking ratio estimate p_mark
update measurement of receiving rate r_recv

calculate non-linear warping of delay d_tilde if packet loss exists
calculate current aggregate congestion signal x_curr
determine mode of rate adaptation for sender: rmode
send feedback containing values of: rmode, x_curr, and r_recv
update t_last = t_curr

set r_ref = RMIN
set rtt = 0
set x_prev = 0
set t_last and t_curr as current system clock time

obtain current timestamp from system clock: t_curr
obtain values of rmode, x_curr, and r_recv from feedback report
update estimation of rtt
measure feedback interval: delta = t_curr - t_last
if rmode == 0:
- update r_ref following accelerated ramp-up rules
else:
- update r_ref following gradual update rules
clip rate r_ref within the range of minimum rate (RMIN) and maximum rate (RMAX).
set x_prev = x_curr
set t_last = t_curr

update r_ref following accelerated ramp-up rules

update r_ref following gradual update rules

rfc/rfc8698.xml

Version of the YANG instance data format (if not explicitly present, the default value is used).

Name of the data set.
Content-schema specification (i.e., the "content-schema" node).
Description of the instance data set. The description SHOULD contain information on whether and how the data can change during the lifetime of the server.
An indication of whether default values are included. The default handling uses the concepts defined in ; however, as only concepts are re-used, users of instance data sets do not need to support .

rfc/rfc9195.xml