SRv6 End.X SID Sub-TLV (RFC 9352 section #8.1) and SRv6 LAN End.X SID
Sub-TLV (RFC 9352 section #8.2) contain a `flag` field. Currently, three
flags are defined:
* B-Flag: Backup flag
* S-Flag: Set flag
* P-Flag: Persistent flag
This commit defines three constants representing these flags.
isisd: Add SRv6 End.X SID to IS ext reach Sub-TLVs
Add SRv6 End.X SID Sub-TLV and SRv6 LAN End.X SID Sub-TLV to the
Extended IS Reachability Sub-TLVs data structure and perform proper
initialization/free when the Sub-TLVs data structure is
allocated/destroyed.
According to RFC 9352 section #5, the SRv6 Locators associated with
algorithms 0 and 1 should be also advertised in a Prefix Reachability
TLV (236 or 237) to allow legacy routers (i.e., routers that do not
support SRv6) installing a forwarding entry for algorithms 0 and 1 SRv6
traffic.
This commits extend IS-IS to advertise SRv6 Locators in IPv6
Reachability TLV.
Add a function to build an SRv6 SID Structure Sub-Sub-TLV (RFC 9352
section #9) to advertise the structure of a specific SRv6 End SID passed
as an argument.
General Sub-Sub-TLV processing functions (i.e., copy, format, free,
pack, and unpack) perform a lookup of the handler specific for a
Sub-Sub-TLV in the `tlv_table`, and then call the specific handler to
process the Sub-Sub-TLV.
This commit adds the handlers for the SRv6 Structure Sub-Sub-TLV (stored
in `subsubtlv_srv6_sid_structure_ops`) to the `tlv_table`.
Add a function to pack all the Sub-Sub-TLVs passed as an argument.
At this time, this function does not pack any Sub-Sub-TLVs because no
Sub-Sub-TLVs have been defined yet. This function will be extended in
future commits to pack specific Sub-Sub-TLVs, as they become supported.
Add a function to free all the Sub-Sub-TLVs and the `isis_subsubtlvs`
data structure passed as an argument.
At this time, this function only frees the `isis_subsubtlvs`. It does
not free any specific Sub-Sub-TLVs because no Sub-Sub-TLVs have been
defined yet. This function will be extended in future commits to free
specific Sub-Sub-TLVs, as they become supported.
isisd: Add format func for Sub-Sub-TLVs in general
Add a function to return information about all the Sub-Sub-TLVs passed
as an argument.
At this time, this function does nothing because no Sub-Sub-TLVs have
been defined yet. This function will be extended in
future commits to return information about specific Sub-Sub-TLVs,
as they become supported.
Add a function to copy all the Sub-Sub-TLVs passed as an argument.
At this time, this function does not copy any Sub-Sub-TLVs because no
Sub-Sub-TLVs have been defined yet. This function will be extended in
future commits to copy specific Sub-Sub-TLVs, as they become supported.
Add a data structure to store IS-IS Sub-Sub-TLVs information. At this
time, does not contain any Sub-Sub-TLV information because no
Sub-Sub-TLVs have been defined yet. This data structure will be extended
in future commits to store specific Sub-Sub-TLVs, as they become
supported.
General Sub-TLV processing functions (i.e., copy, format, free, pack,
and unpack) perform a lookup of the specific handler for a Sub-TLV in
the `tlv_table`, and then call the specific handler to process the
Sub-TLV.
This commit adds the handlers for the SRv6 End SID Sub-TLV (stored in
`tlv_srv6_end_sid_ops`) to the `tlv_table`.
Add a new TLV context value for the SRv6 End SID Sub-TLV. It will be
needed to support unpacking of the Sub-Sub-TLVs of the SRv6 End SID
Sub-TLV in future commits.
isisd: Decode MTID when unpacking SRv6 Locator TLV
The SRv6 Locator TLV (RFC 9352 section #7.1) starts with the MTID field.
Let's expect the MTID as the first field when we are unpacking an SRv6
Locator TLV.
The SRv6 Locator TLV (RFC 9352 section #7.1) starts with the MTID field.
Let's put the MTID as the first field when we are packing an SRv6
Locator TLV.
isisd: Bind SRv6 Locator TLV ops to IS-IS TLV type
General TLV processing functions (i.e., copy, format, free, pack, and
unpack) perform a lookup of the specific handler for a TLV in the
`tlv_table`, and then call the specific handler to process the TLV.
This commit adds the handlers for the SRv6 Locator TLV (stored in
`tlv_srv6_locator_ops`) to the `tlv_table`.
Add the `IS-IS SRv6 SID Structure Sub-Sub-TLV Codepoint` as defined in the
`IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs` IANA registry. This codepoint
will be used as the Sub-Sub-TLV Type to advertise the SRv6 SID Structure
Sub-Sub-TLV in the SRv6 End SID, SRv6 End.X SID, and SRv6 LAN End.X SID
Sub-TLVs.
Add the `IS-IS SRv6 End SID Sub-TLV Codepoint` as defined in the
`IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability` IANA registry.
This codepoint will be used as the Sub-TLV
Type to advertise the SRv6 End SID Sub-TLV in the SRv6 Locator TLV.
Add a new TLV context value for the SRv6 Locator TLV. It will be needed
to support unpacking of the Sub-TLVs of the SRv6 Locator TLV in future
commits.
When zebra assigns a chunk to IS-IS, zebra sends a
ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK notification to IS-IS.
IS-IS invokes the `isis_zebra_process_srv6_locator_chunk()` callback to
process the received notification.
Actually, `isis_zebra_process_srv6_locator_chunk()` iterates over all
areas of the current IS-IS instance and looks for an area for which the
received chunk was requested.
If a match is found, the new chunk is added to the area's chunk list and
`lsp_regenerate_schedule()` is called to regenerate the LSPs to
advertise the new SRv6 locator.
This commit extends the `isis_zebra_process_srv6_locator_chunk()`
function to automatically allocate an SRv6 End SID from the received
chunk and install it in the data plane.
The SRv6 End SID is the instantiation of a Prefix-SID (RFC 8986 section
In some cases, IS-IS may attempt to remove routes that have not been
installed before. We can prevent IS-IS from doing this by aborting
`isis_zebra_route_del_route` when the ISIS_ROUTE_FLAG_ZEBRA_SYNCED flag
is unset, meaning that the route is not installed in the kernel.
zebra: Resolve default values for SRv6 flavor attr
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
zebra: Resolve default values for SRv6 flavor attr
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
When installing a local SID in the Linux kernel, `lcblock_len` and
`lcnode_fn_len` Netlink attributes are optional. When omitted, the
kernel uses the default values: lcblock_len=32 and lcnode_fn_len=16.
Let's use the same default values in FRR.
`struct seg6local_context` contains a `struct seg6local_flavors_info`
that carries SRv6 flavors information. The `seg6local_flavors_info`
data structure contains a field `flv_ops` that indicates which flavors
are enabled for the `seg6local` nexthop. `flv_ops` is a bit-map where
each bit indicates if a particular SRv6 flavor is enabled (bit set to
1) or not (bit set to 0).
This commit defines some macros that can be used to manipulate the SRv6
flavors bit-map:
* CHECK_SRV6_FLV_OP(OPS,OP) - check if a particular flavor is enabled;
* SET_SRV6_FLV_OP(OPS,OP) - enable a particular flavor (OP);
* UNSET_SRV6_FLV_OP(OPS,OP) - disable a particular flavor (OP);
* RESET_SRV6_FLV_OP(OPS) - disable all SRv6 flavors.
The RFC 8986 defines the SRv6 Network Programming concept and specifies
the base set of SRv6 behaviors that enables the creation of
interoperable overlays with underlay optimization. In addition, the RFC
8986 introduces the concept of "flavors", additional operations that can
modify or extend the existing SRv6 behaviors.
In the Linux kernel and in FRR, an SRv6 SID is implemented as a route
associated with a `seg6local` nexthop. A `seg6local` nexthop represents
an SRv6 behavior bound to a SID.
The Linux kernel already supports the ability to add a set of flavors
to a `seg6local` nexthop to modify or extend the associated behavior.
This commit aligns the `seg6local` nexthop implementation of FRR to the
Linux kernel. It extends the `seg6local` nexthop implementation by
adding a struct `seg6local_flavors_info` that encodes the SRv6
flavors information.
Currently, the `seg6local_flavors_info` data structure has three
members:
- `tlv_ops` indicates which flavors are enabled for the `seg6local`
nexthop;
- `lcblock_len`is the length of the Locator-Block part of the SID;
- `lcnode_func_len` is the length of the combined Node and Function
parts of the SID.
`lcblock_len` and `lcnode_func_len` define the SID structure. They are
required for some behaviors (e.g. NEXT-C-SID and REPLACE-C-SID). For
other flavors (e.g. PSP, USP, USD) these parameters are not required and
can be omitted.
The RFC 8986 defines the SRv6 Network Programming concept and specifies
the base set of SRv6 behaviors that enables the creation of
interoperable overlays with underlay optimization. In addition, the RFC
8986 introduces the concept of "flavors", additional operations that can
modify or extend the existing SRv6 behaviors.
This commit adds a new enum type `seg6local_flavor_op` to represent the
SRv6 flavors operations. Currently we define the following flavor
operations:
- PSP (defined in RFC 8986 section #4.16.1)
- USP (defined in RFC 8986 section #4.16.2)
- USD (defined in RFC 8986 section #4.16.3)
- NEXT-C-SID (defined in draft-ietf-spring-srv6-srh-compression-03 #4.1)
Add a function to allocate an SRv6 SID from an SRv6 locator chunk owned
by IS-IS. The chunk must be allocated by a previous call to
`isis_zebra_srv6_manager_get_locator_chunk()`.
Add the list of SRv6 SIDs allocated by the IS-IS instance to the per-area
SRv6 configuration. The list is area-specific. Each IS-IS area has its
own SRv6 SIDs list. The list is initialized when an IS-IS area is
created and freed when an IS-IS area is destroyed.
Add `struct isis_srv6_sid_structure` data structure to represent an SRv6
SID structure (as defined in RFC 8986 section #3.1).
The struct has the following members:
* loc_block_len: locator block length
* loc_node_len: locator node length
* func_len: function length
* arg_len: argument length
Add `struct isis_srv6_sid` data structure to represent an SRv6 SID.
The struct has the following members:
* next: pointer to the next SID, used to build linked lists of SRv6 SIDs
* flags: SID flags
* behavior: the behavior bound to the SRv6 SID (as defined in RFC 8986)
* value: the SID value (i.e., an IPv6 address)
* locator: a backpointer to the parent locator from which the SID has
been allocated.