Network Working Group M. Portoles Internet-Draft B. Pitta Intended status: Informational S. Hooda Expires: 20 April 2026 Cisco Systems 17 October 2025 LISP Delegated Mappings draft-portoles-lisp-delegated-mappings-00 Abstract The LISP protocol with its inherent decoupling of control-plane and data-plane, offers the flexibility to support modern networking paradigms. This document specifies how to use the LISP protocol to enable centralized onboarding and management of EIDs within a network from an external controller or orchestration system. Requirements Notation 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. 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 20 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Portoles, et al. Expires 20 April 2026 [Page 1] Internet-Draft lisp-delegated-mappings October 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 3. General Procedures . . . . . . . . . . . . . . . . . . . . . 4 3.1. Reference System . . . . . . . . . . . . . . . . . . . . 4 3.2. Flow Sequence to distribute Delegated Mappings . . . . . 5 3.3. Distribution of Delegated Mappings . . . . . . . . . . . 6 3.4. Map-Server procedures . . . . . . . . . . . . . . . . . . 6 3.5. ETR procedures . . . . . . . . . . . . . . . . . . . . . 7 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . 7 4.1. Map-Register . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Map-Notify . . . . . . . . . . . . . . . . . . . . . . . 8 5. Sending EID access information . . . . . . . . . . . . . . . 8 6. Implementation Considerations . . . . . . . . . . . . . . . . 10 6.1. Virtual Private Network Considerations . . . . . . . . . 10 6.2. EID Mobility Considerations . . . . . . . . . . . . . . . 11 6.3. Reliable Transport Considerations . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction As new compute system environments emerge, routing networks have been adapting to serve their communication needs. In many of these cases, network controllers or orchestration engines are used to organize resources or enforce network policies in a centralized manner. Examples of these types of systems range from wireless systems in enterprise environments, Software-Defined Networks (SDN) (e.g., in WAN, Datacenter, or Campus environments), and include public (or private) cloud networks. Portoles, et al. Expires 20 April 2026 [Page 2] Internet-Draft lisp-delegated-mappings October 2025 In all these cases, it is common that a centralized controller or orchestrator drives how endpoints authenticate, join, leave, or move within the network. In many cases, this centralized controller is also the point of reference that determines the policies that need to be enforced. Networks running the LISP protocol can exploit the vantage point of these controllers for early and faster onboarding and movement of endpoints at selected locations of the network. Controllers that deploy or authenticate sites and endpoints can interface directly with the Mapping System to distribute this information to selected locations (xTRs). This document specifies Delegated Mappings, where a controller can use its interface to a LISP Mapping System to delegate ownership of specific EIDs to selected xTRs of the network. The document provides a detailed description of the mechanisms used to distribute this type of mappings in a network running the LISP protocol. In particular, the specification describes: * How a controller may use the LISP Map-Register and Map-Notify interfaces to distribute Delegated Mappings to LISP sites that should take ownership of specific EIDs. * The procedures that an ETR follows to take ownership of a Delegated Mapping so that an EID can be resolved using LISP protocol procedures. * Finally, it also details how the controller can make use of specific LCAF encodings such as ELPs and multiple data-planes (see [RFC8060]), to convey EID access information to the corresponding ETR. Note also that Delegated Mappings can be combined with the procedures specified in [I-D.ietf-lisp-eid-mobility] to support controller-based mobility in a network running the LISP protocol. 2. Definition of terms The document uses the terms defined in Section 3 of documents [RFC9300] and [RFC9301]. Additionally, this document introduces the following terms: Delegated Mapping: This is the term used in this document to Portoles, et al. Expires 20 April 2026 [Page 3] Internet-Draft lisp-delegated-mappings October 2025 identify a Mapping record registered with the Mapping system so that it is relayed (delegated) to a corresponding xTR (or xTRs) of a LISP site. xTR-Controller: This term designates a network element that uses Delegated Mappings to distribute EID records to the corresponding LISP sites where they are connected to. 3. General Procedures 3.1. Reference System Figure 1 illustrates a reference system model used to support the discussion of Delegated Mappings through this section. ------------ | xTR | | Controller |------------, | | | ------------ | +----+----+ | Map | | Server | +----+----+ _..-._.--._..._.,.-|._._.-._.-_._.-.. .-.' '.-. ( ) ( ) '.-..-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-.' | | RLOC=IP_A RLOC=IP_B +-+--+--+ +-+--+--+ .| xTR A |.-. .| xTR B |.-. ( +-+--+--+ ) ( +-+--+--+ ) .' Site A ) .' Site B ) ( . ( . '--'._.'. ) '--'._.'. ) | '--' | '--' '--------' '--------' : Host 1 : : Host 2 : '--------' '--------' IP: 10.0.0.1 IP: 10.1.1.2 Figure 1: Reference System Architecture with delegated Mappings A xTR-controller implements LISP control-plane interfaces so that it can interact with the LISP Mapping System, represented with a single Map-Server in the figure. The interconnection between the xTR- Portoles, et al. Expires 20 April 2026 [Page 4] Internet-Draft lisp-delegated-mappings October 2025 controller and the Map-Server is out of the scope of this specification, but the Map-Server MUST be able to handle Map Registration procedures through this connection. The network running the LISP protocol has two sites (A and B) with the corresponding xTRs providing access to them. There is a local endpoint on each one of the sites (host 1 and 2) For the purpose of this specification the xTR-Controller knows when endpoints are connected, authenticated or released from each one of the sites. The controller is also aware of the xTRs (and their corresponding RLOC addresses) that provide access to each one of the sites. 3.2. Flow Sequence to distribute Delegated Mappings When a xTR-Controller attempts to use the process of Delegated Mappings to distribute EID Mappings to target LISP sites, it MUST know beforehand the RLOCs of the xTRs providing access to those sites. Using Figure 1 as reference, the xTR-controller knows that IP_A is the RLOC of xTR A, associated to site A. Using this information, the xTR-controller uses Delegated Mappings to distribute information about Host 1 to Site A using the following procedures: 1. The xTR-Controller builds a Map-Register with the EID record information it wants to distribute. The Map-Register carries the Delegated Mapping (D) bit set (see Section 4). Using the reference example, the xTR-Controller sends a Map-Register to the Map-Server that carries the EID-to-RLOC mapping of EID=<10.0.0.1> -> RLOC=IP_A and is built with the D-bit set. 2. When a Map-Server receives a Map-Register with the D-bit set, it prepares a Map-Notify with the same EID record that also has the D-bit set. This Map-Notify is sent to all the RLOCs in the RLOC record of the Mapping. Following the example, the Map-Server sends a Map-Notify with the D-bit set to IP_A (RLOC of xTR A). 3. When an ETR receives a Map-Notify with the D-bit set, it verifies that its own RLOC is in the RLOC record of the Mapping in the message. When that is the case, the ETR creates an entry for the EID in its database mapping. Continuing with the example, xTR A receives the Map-Notify with the D-bit set and learns that EID=<10.0.0.1> is local to site A. Portoles, et al. Expires 20 April 2026 [Page 5] Internet-Draft lisp-delegated-mappings October 2025 4. Once the ETR verifies the presence of the EID in the site, it confirms the EID with a new Map-Register to the Map-Server. This is a regular Map-Register, without the D-bit and marked as authoritative. In the example the ETR sends an authoritative Map-Register with EID-to-RLOC mapping of EID=<10.0.0.1> -> RLOC=IP_A. This operation repeats for every EID and for every site that the xTR- Controller wants to distribute information to. 3.3. Distribution of Delegated Mappings The distribution of Delegated Mappings relies on the use of the D-bit (see Section 4) both in the Map-Register and Map-Notify messages. The xTR-Controller sending a Delegated Mapping MUST NOT set the authoritative bit in the EID record. Only the site ETR, after accepting a Delegated Mapping can set this bit when registering the EID prefix. Equally, a Map-Register carrying a Delegated Mapping MUST NOT have the Proxy Map-Reply bit (P-bit) or the security-capable (S-bit) set. Since the xTR-controller is not authoritative for the Mapping, it cannot set either of these bits. Only the authoritative ETR for the destination site can set these bits with its corresponding Map- Register, when accepting the Delegated Mapping. A Delegated Mapping can also be removed. In that case the xTR- Controller MUST send the Map-Register with the D-bit and with a TTL with value 0 in the EID record. This removal MUST carry the RLOC record corresponding to the site that the Delegated Mapping is being removed from. The Map-Notify with the D-bit set is sent to all the RLOCs in the RLOC record with the same TTL of value 0. 3.4. Map-Server procedures A Map-Server that supports Delegated Mappings, SHOULD send a Map- Notify with the D-bit to all the RLOCs in the RLOC record of the Delegated Mapping. A Map-Server MAY record in its registration table a Delegated Mapping, but it MUST NOT use a Delegated Mapping Record to send a proxy Map-Reply in response to a Map-Request for the EID in the Mapping. In such a case, the Map-Server MAY forward the Map-Request to one of the RLOCs in the record, following [RFC9301]. Portoles, et al. Expires 20 April 2026 [Page 6] Internet-Draft lisp-delegated-mappings October 2025 This restriction extends to the procedures described in [RFC9437]. A Map-Server MUST NOT send Map-Notify with a Delegated Mapping as a publication message for EID subscribers. Only the Map-Register from the authoritative ETR can be published following LISP Publish/ Subscribe procedures. In order to avoid periodic Map-Register and Map-Notification messages, Delegated Mappings MAY be distributed using a reliable transport as described in [I-D.ietf-lisp-map-server-reliable-transport]. 3.5. ETR procedures When an ETR receives Map-Notify with a Delegated Mapping (D-bit set) that carries its own RLOC in the RLOC record it SHOULD verify the reachability of the EID in the site before accepting the mapping. The verification process is out of scope of this document. Once the Mapping is accepted the ETR adds the EID in its local mapping database and it MUST send a Map-Register with the EID Record setting the authoritative bit (A-bit). The ETR MUST be able to follow procedures described in [RFC9300] and [RFC9301] when handling EID records learned through the Delegated Mapping procedure. When the ETR receives a Map-Notify with a Delegated Mapping with a TTL of value 0 it SHOULD remove the EID from the local mapping database. When the ETR receives a Delegated Mapping that does not carry its own RLOC in the RLOC record it MUST follow the procedures described in [I-D.ietf-lisp-eid-mobility] and handle this as a mobility event. 4. Message Extensions This document proposes an extension of the Map-Register and Map- Notify messages to carry the notion that a Mapping is being distributed as a Delegated Mapping. This information is used by both Map-Server and ETRs to implement the procedures described in this specification. 4.1. Map-Register The Map-Register header, as defined in [RFC9301] is extended with an additional field, the Delegated Mapping bit (D-bit). Portoles, et al. Expires 20 April 2026 [Page 7] Internet-Draft lisp-delegated-mappings October 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3 |P|S|I|D| Reserved |E|T|a|R|M| Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D: This is the Delegated Mapping bit in the Map-Register header. It should be set to 1 when Map-Register messages carry Delegated Mappings. When D-bit is set the P-bit and S-bit MUST be 0. 4.2. Map-Notify a The Map-Notify header, as defined in [RFC9301], is extended with an additional field, the Delegated Mapping bit. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=4 |D| Reserved | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D: This is the Delegated Mapping bit in the Map-Notify header. It should be set to 1 when the Map-Notify message carries a Delegated Mapping. 5. Sending EID access information In many cases a controller using Delegated Mappings needs to convey EID access information to the ETRs that receive the EID record. This access information indicates what is the path that the ETR can take to reach the EID within the local site. As a reference example, if we take site B in the reference system, Figure 2 illustrates the case when there is an intermediate router (r) between xTR B and Host 2. In this example xTR B must route traffic through the intermediate router to reach the endpoint: Portoles, et al. Expires 20 April 2026 [Page 8] Internet-Draft lisp-delegated-mappings October 2025 | RLOC=IP_B +-+--+--+ | xTR B | +-+--+--+ | (IP_r) +-+--+--+ | r | +-+--+--+ | '--------' : Host 2 : '--------' IP: 10.1.1.2 Figure 2: routed EID reachability in site B A xTR-Controller MAY use ELPs (LCAF type 10 in [RFC8060]) in Delegated Mappings to convey information to the ETR about how to access the EID, when required. The ETR can use this information to program a forwarding path to the EID and also to verify reachability of the EID before accepting a Delegated Mapping. The First locator in the ELP sequence MUST correspond to the RLOC of the ETR and the rest of locators MUST correspond to the sequence of hops that the ETR should follow to reach the EID. It is worth noting also that local site reachability between the ETR and the endpoint may not require encapsulation or alternative encapsulations to the one used in the rest of the network. To solve this case each locator in the ELP is sent using the Multiple Data- Planes LCAF (Type 16 in [RFC8060]) and selecting the bit corresponding to the encapsulation type. When no encapsulation is needed Type 16 is also used but with all encapsulation bits set to 0. In order to illustrate this, Figure 3 exemplifies the use of the ELP and Multiple Data-Plane LCAFs for the figure above. In this reference encoding, the ELP carries both the IP address of xTR B and the intermediate router r. The IP of the intermmediate router is disttribured indicating that no encapsulation is needed and xTR B can access Host 2 routing packets through IP_r. Portoles, et al. Expires 20 April 2026 [Page 9] Internet-Draft lisp-delegated-mappings October 2025 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | EID-AFI = 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix (10.1.1.2) | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c /| Priority | Weight | M Priority | M Weight | o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r R | Unused Flags |L|p|R| AFI = 16387 | d L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O | Rsvd1 | Flags | Type = 10 | Rsvd2 | | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Length | Rsvd3 |L|P|S| | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | AFI = 1 or 2 | IP_B ~ | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O ~ IP_B | | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | Rsvd3 |L|P|S| AFI = 16387 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | Rsvd1 | Flags | Type = 16 | Rsvd2 | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P | Length | 0 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 0 | AFI = 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| IP_r | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 6. Implementation Considerations Delegated Mappings can be used in environments running the LISP protocol that implement VPN based segmentation ([I-D.ietf-lisp-vpn]) and EID mobility ([I-D.ietf-lisp-eid-mobility]). 6.1. Virtual Private Network Considerations Delegated Mappings can be distributed using VPN segmentation procedures, following the procedures described in [I-D.ietf-lisp-vpn]. When the xTR-controller intents to distribute EIDs within specific VPN segments, it MUST use the same IID that is used in the target LISP site for that segment. Portoles, et al. Expires 20 April 2026 [Page 10] Internet-Draft lisp-delegated-mappings October 2025 Following the same procedures, a Map-Register and Map-Notify with the D-bit set carry the XEID encoded using the Instance-id LCAF ([RFC8060]) in the EID record. An ETR receiving a Map-Notify with the D-bit set and with an IID that is not known or used, SHOULD ignore the Map-Notify. It is NOT RECOMMENDED to use Delegated Mappings with extranet encoding to distribute Mappings across IID boundaries. The Map- Server SHOULD prevent this distribution. 6.2. EID Mobility Considerations When Delegated Mappings are combined with the procedures of [I-D.ietf-lisp-eid-mobility], a controller can be used to drive the mobility of EIDs through the network. A Map-Server that receives a Map-Register with the D-bit set, SHOULD generate a Map-Notify with the D-bit set to all ETRs that have an active registration of the Mapping. When an ETR receives a Delegated Mapping with a RLOC record that does not have any local RLOC on the ETR, it must treat the Mapping as a mobility event and follow the procedures in [I-D.ietf-lisp-eid-mobility] 6.3. Reliable Transport Considerations Delegated Mappings can be distributed using a reliable transport as described in [I-D.ietf-lisp-map-server-reliable-transport]. Since both Map-Register and Map-Notify encodings are reuse when sending Reliable Registrations and Reliable Notifications, the same D-bit is used in this case to indicate the distribution of a Delegated Mapping. 7. Security Considerations Map-Register and Map-Notify messages MUST be authenticated following the procedures specified in [RFC9301]. XTR-Controllers follow the same procedures. Map-Notify messages carrying Delegated Mappings are handled by ETRs as unsolicited Map-Notify messages, following [RFC9301]. The Map- Server MUST use the pre-shared key associated to the target Site of the Delegated Mapping to authenticate the Map-Notify. Portoles, et al. Expires 20 April 2026 [Page 11] Internet-Draft lisp-delegated-mappings October 2025 8. IANA Considerations This memo includes no request to IANA. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, . [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, . [RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, S., and M. Boucadair, "Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)", RFC 9437, DOI 10.17487/RFC9437, August 2023, . 9.2. Informative References [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno, V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-mobility-16, 8 May 2025, . Portoles, et al. Expires 20 April 2026 [Page 12] Internet-Draft lisp-delegated-mappings October 2025 [I-D.ietf-lisp-map-server-reliable-transport] Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D., Kouvelas, I., and C. Cassar, "LISP Map Server Reliable Transport", Work in Progress, Internet-Draft, draft-ietf- lisp-map-server-reliable-transport-07, 2 October 2025, . [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Work in Progress, Internet-Draft, draft- ietf-lisp-vpn-12, 19 September 2023, . Authors' Addresses Marc Portoles Comeras Cisco Systems 170 Tasman Drive San Jose, CA 95134 United States of America Email: mportole@cisco.com Balaji Pitta Cisco Systems Tasman Drive San Jose, CA 95134 United States of America Email: bvenkata@cisco.com Sanjay Hooda Cisco Systems 170 Tasman Drive San Jose, California 95134 United States of America Email: shooda@cisco.com Portoles, et al. Expires 20 April 2026 [Page 13]