DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/19/25 has been entered.
Response to Arguments
Applicant’s argument on 11/19/25 have been carefully considered, but they are not persuasive.
For claim 1, Applicant’s argues: Suryanarayana in view of Tang fails to disclose or suggest "withdrawing, by the SDN controller and based on the determination that the next hop of the VPN route is not reachable via the underlay network, the VPN route from any network peers to which the VPN route was previously advertised," for the reasons set forth in Applicant's previous response, particularly in the context of the discussion above regarding the absence of negative limitations as it relates to "the determination that the next hop of the VPN route is not reachable via the underlay network" which refers back to "determining, based on determining the SDN controller does not store an underlay network route having a destination prefix that matches the next hop of the VPN route," as set forth earlier in amended claim 1.
In response, Examiner respectfully disagrees:
First, Applicant’s arguments are moot because claim 1 has been amended and the previous response has not updated. For the purpose of compact prosecution, Examiner’s responses are as follows:
In the previous response dated 7/18/25, Applicant argues:
a) First, cited passage (c10/l17-23) “does not disclose any relationship between routing information for the physical network and the overlay networks” (p10, 1st para);
b) second, the cited Tang passage describing a reachability determination by “monitoring communication” with the target device (FIGs. 1-7 and [0022]) “has no relation to the basis” for the claim limitation “… based on that the next hop is not reachable via an underlay network”;
c) Suryanarayanana in view of Tang fail to disclose the claim limitation “withdrawing, … the VPN route from any network peers to which the VPN route was previously advertised”.
To which Examiner’s responses are as follows:
a) Applicant’s argument is moot because FOA cited a different passage (c22/l57-62) that Applicant did not address;
b) Tang clearly teaches the relationship between routing information for the physical network and the overlay networks in [0022] as cited in Office Action; [0039] “… the SDN controller can dynamically select a new computing device in response to monitoring communication with the previously selected computing device and determining that the previously selected computing device is unreachable due to, for example, an operating fault.”;
c) Suryanarayanana teaches the cited claim limitation as disclosed by OA in c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged …”.
For claim 11, Applicant argues: Suryanarayanana fails to teach the subject matter of “establishing, by the compute node, a fault detection protocol session with a leaf switch of an Internet Protocol (IP) fabric of an underlay network to communicate a reachability status of the compute node to the leaf switch”.
In response, Examiner respectfully disagrees:
Suryanarayanana teaches the subject matter in FIGs. 1-7 and the relevant text, such as c10/l17-23, wherein SDN controller manages routing/forwarding tables for nodes that include leaf switches.
Therefore, Applicant’s arguments are not persuasive.
Other arguments are all based on the arguments to claims 1 and 11, to which Examiner’s responses are the same.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-7 and 9-19 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (US 10200274 B1) in view of Tang (US 20190140944 A1).
For claim 1, D1 discloses a method comprising:
receiving, by a Software Defined Networking (SDN) controller, a virtual private network (VPN) route specifying a next hop (c2/l56-60, “a method includes by a Software Defined Networking (SDN) controller, receiving one or more virtual routes to virtual interfaces from a first virtual router agent managed by the SDN controller, the one or more virtual routes received via a messaging protocol session between the SDN controller and the first virtual router agent” and c9/l31-40 “… any of the virtual routes may include a prefix, a next hop address associated with a server of servers 26, and a label or other data to identify a virtual routing and forwarding instance configured at the next hop server. A virtual route may include a Route Distinguisher (RD). Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.”);
determining, based on determining the SDN controller does not store an underlay network route having a destination prefix that matches the next hop of the VPN route (c22/l57-62, “The SDN controller 32 determines the messaging protocol session has closed (254), such as by failing to receive communications over the messaging protocol session for a pre-defined time period. The session may close due to, for example, the virtual router agent failing.”; note that “session closed” suggests that SDN controller does not has any information for a destination prefix matches the next hop of the VPN route); and
withdrawing, by the SDN controller and based on the determination that the next hop of the VPN route is not reachable via the underlay network, the VPN route from any network peers to which the VPN route was previously advertised (FIG. 1-7 and the text associated with it, such as c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; and c22/l62-67, “In response to determining the messaging protocol session has closed, the SDN controller marks the virtual routes that were received from the virtual router agent in the data structure as stale routes, such as by setting a flag associated with the virtual router agent in routing information (256).”; note that “Routes are marked as stale” or “session has closed” suggests withdrawing the VPN route is not reachable).
D1 does not specifically state but Tang, in the same field of SDN communication, discloses: based on that the next hop is not reachable via an underlay network (FIGs. 1-7 and the relevant text, such as [0022] “… The SDN controller can appear to logical network elements as a single logical switch. The SDN controller uses a set of protocols to control the flow of traffic in SDN networks by configuring physical network devices and selecting routes for forwarding network traffic. Communication between elements of an SDN network, including applications that use the SDN network, and network devices are processed through the SDN controller. The SDN controller is aware of each network element (physical or logic) associated with an SDN network” and [0039] “… the SDN controller can dynamically select a new computing device in response to monitoring communication with the previously selected computing device and determining that the previously selected computing device is unreachable due to, for example, an operating fault.”; note that a destination device of the physical network suggests a leaf switch). OOSA would have been motivated to apply the teaching of Tang above to the SDN controller to yield a predictable result of dynamic routing according to MPEP 2143(D).
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Tang for the benefit of dynamic routing ([0039] of Tang).
For claim 11, D1 discloses a method comprising:
advertising, by a compute node managed by a Software Defined Networking (SDN) controller, the compute node as a next hop for a virtual private network (VPN) route (FIGs. 1-7 and relevant text, c3/l19-30 “a Software Defined Networking (SDN) controller includes a compute node executing a messaging protocol process configured to receive one or more virtual routes to virtual interfaces from a first virtual router agent managed by the SDN controller, the one or more virtual routes received via a messaging protocol session between the SDN controller and the first virtual router agent, wherein the compute node stores the one or more virtual routes to a data structure of the SDN controller; a routing protocol process configured to advertise the one or more virtual routes from the data structure to routing protocol peers of the SDN controller …”; note that “routes” suggests “next hop”);
establishing, by the compute node, a fault detection protocol session with a leaf switch of an Internet Protocol (IP) fabric of an underlay network to communicate a reachability status of the compute node to the leaf switch (FIGs. 1-7 and the relevant text, such as c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “stale” suggests fault detection and that each of TOR switch 24A to 24N is a leaf switch); and
receiving, by the compute node, traffic destined for the VPN route only when the fault detection protocol session indicates that the compute node is reachable (FIGs. 1-7 and the relevant text, such as c10/l17-23 “SDN controller 32 maintains a routing information base, e.g., one or more routing tables that store routing information for the physical network as well as one or more overlay networks of data center 10. Similarly, chassis switches 22, TOR switches 24 and virtual routers 42 maintain routing information, such as one or more routing and/or forwarding tables”; and c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “stale” suggests fault detection and that each of TOR switch 24A to 24N is a leaf switch).
D1 does not specifically state but Tang, in the same field of endeavor field of endeavor, disclose traffic destined for the VPN route only indicates to the leaf switch of the IP fabric ([0022] “… The SDN controller can appear to logical network elements as a single logical switch. The SDN controller uses a set of protocols to control the flow of traffic in SDN networks by configuring physical network devices and selecting routes for forwarding network traffic. Communication between elements of an SDN network, including applications that use the SDN network, and network devices are processed through the SDN controller. The SDN controller is aware of each network element (physical or logic) associated with an SDN network” and [0003] “… the method then includes routing, using the routing data, the received packet to the selected computing device to route to the destination element.”; note that a destination device of the physical network suggests a leaf switch). OOSA would have been motivated to apply the teaching of Tang above to the SDN controller to yield a predictable result of conducting routing according to MPEP 2143(D).
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and Tang for the benefit of routing ([0003] of Tang).
Claim 16 is rejected because it is a method of a SDN controller that performs the method of claim 1 and have the same subject matter.
Claim 19 is rejected because it is a method of a SDN controller that performs the method of claim 11 and have the same subject matter.
As to claims 2 and 17, D1 in view of Tang discloses claims 1 and 16, further discloses: refraining, by the SDN controller and based on the determination that the next hop of the VPN route is not reachable via the underlay network, from advertising the VPN route (D1: FIGs. 1-7 and relevant text, such as c3/l19-30 “a Software Defined Networking (SDN) controller includes a compute node executing a messaging protocol process …; a routing protocol process configured to advertise the one or more virtual routes from the data structure to routing protocol peers of the SDN controller …” and c13/l31-36 “… whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “unresponsive” or “stale flag” suggests “unreachable” and it is obvious to OOSA not to advertise the VPN route if the session is closed; Tang also teaches it in [0039] “… the SDN controller can dynamically select a new computing device in response to monitoring communication with the previously selected computing device and determining that the previously selected computing device is unreachable due to, for example, an operating fault.”; note that “dynamically select …” a staled node include refraining from advertising route to specific node). The motivation of combining D1 and Tang is the same as stated in the parent claims.
As to claims 3 and 18, D1 in view of Tang discloses claims 1 and 16, further discloses: wherein determining that the next hop is not reachable via the underlay network comprises checking underlay routing information maintained by the SDN controller, wherein the underlay routing information stores routes advertised to the SDN controller by the IP fabric of the underlay network (D1: FIGs. 1-7 and relevant text, such as c3/l19-30 “a Software Defined Networking (SDN) controller includes a compute node executing a messaging protocol process …; a routing protocol process configured to advertise the one or more virtual routes from the data structure to routing protocol peers of the SDN controller …” and c13/l31-36 “… whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “unresponsive” or “stale flag” suggests “unreachable” and it is obvious to OOSA not to advertise the VPN route if the session is closed; Tang also teaches it in [0039] “… the SDN controller can dynamically select a new computing device in response to monitoring communication with the previously selected computing device and determining that the previously selected computing device is unreachable due to, for example, an operating fault.”; note that “dynamically select …” a staled node include refraining from advertising route to specific node). The motivation of combining D1 and Tang is the same as stated in the parent claims.
As to claim 4, D1 in view of Tang discloses claim 3, D1 further discloses: receiving, by the SDN controller and via a Border Gateway Protocol session between the SDN controller and a spine switch of the IP fabric, a plurality of underlay network routes to active tunnel endpoints of the underlay network, wherein the underlay network route comprises one of the plurality of underlay network routes, wherein the active tunnel endpoints comprise tunnel endpoints indicated as reachable based on a fault detection protocol session between the active tunnel endpoints and a leaf switch of the IP fabric (FIGs. 1-7 and relevant text, such as c3/l19-30 “a Software Defined Networking (SDN) controller includes a compute node executing a messaging protocol process …; a routing protocol process configured to advertise the one or more virtual routes from the data structure to routing protocol peers of the SDN controller …” and c13/l31-36 “… whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56” in view of the parent claims; note that “unresponsive” or “stale flag” suggests “unreachable”).
As to claim 6, D1 in view of Tang discloses claim 1, D1 further discloses: by the SDN controller and prior to determining that the next hop of the VPN route is not reachable (FIG. 1-7 and the text associated with it, such as and c13/l31-36 “… whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “unresponsive” or “stale flag” suggests “unreachable”); advertising the VPN route to at least one of a compute node or an SDN gateway device (FIGs. 1-7 and relevant text, such as c3/l19-30 “a Software Defined Networking (SDN) controller includes a compute node executing a messaging protocol process …; a routing protocol process configured to advertise the one or more virtual routes from the data structure to routing protocol peers of the SDN controller …”).
As to claim 7, D1 in view of Tang discloses claim 1, D1 further discloses: receiving, by the SDN controller, a message from a node in an IP fabric indicating the underlay network route is withdrawn because its destination is unreachable by the IP fabric; updating, by the SDN controller, and based on receiving the message, stored underlay routing information to remove the underlay network route; and wherein withdrawing the VPN route comprises: sending, to at least one of a compute node or an SDN gateway device, a message withdrawing the VPN route (FIG. 1-7 and the text associated with it, such as c9/l17-40 “each of servers 26 includes a corresponding one of VR agents 36A-36X that communicates with SDN controller 32 and, responsive thereto, directs virtual router 42 so as to control the overlay of virtual networks 46 and coordinate the routing of data packets within server 26. In general, each VR agent 36 communicates with SDN controller 32, which generates commands to control routing of packets through data center 10. Each of VR agents 36 may send messages to SDN controller 32 over XMPP sessions, the messages conveying virtual routes to the virtual interfaces (virtual addresses) of the VMs of servers 26. SDN controller 32 receives the messages and stores the virtual routes, and may in turn advertise one or more of the virtual routes from a first VR agent 36 to other VR agents 36. In some examples, any of the virtual routes may include a prefix, a next hop address associated with a server of servers 26, and a label or other data to identify a virtual routing and forwarding instance configured at the next hop server. A virtual route may include a Route Distinguisher (RD). Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.” In view of the parent claim; note that FIG. 5B shows advertising the underlay IP network route to the at least one of a compute node via Overlay Tunnels and that IP networks are underlay networks; and BGP allows a node in IP network to detect if its destination is unreachable).
As to claim 9, D1 in view of Tang discloses claim 7, D1 further discloses determining, by a leaf switch of the IP fabric and via a fault detection protocol session established between the leaf switch and a compute node of the underlay network, that the compute node is not responding on the fault detection protocol session; and propagating, by the leaf switch and in response to the determining that the compute node is not responding, a route withdrawal message through the IP fabric withdrawing an underlay network route for the compute node, wherein the node in the IP fabric comprises a spine switch that received a corresponding message based on the propagating (FIG. 1-7 and the text associated with it, such as c9/l24-40 “Each of VR agents 36 may send messages to SDN controller 32 over XMPP sessions, the messages conveying virtual routes to the virtual interfaces (virtual addresses) of the VMs of servers 26. SDN controller 32 receives the messages and stores the virtual routes, and may in turn advertise one or more of the virtual routes from a first VR agent 36 to other VR agents 36. In some examples, any of the virtual routes may include a prefix, a next hop address associated with a server of servers 26, and a label or other data to identify a virtual routing and forwarding instance configured at the next hop server. A virtual route may include a Route Distinguisher (RD). Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.” In view of parent claims; note that FIG. 5B shows advertising the underlay IP network route to the at least one of a compute node via Overlay Tunnels and IP networks are underlay networks and that FIG. 1 shows a spine switch as one of CHASSIS switch 22A to 22M).
As to claim 10, D1 in view of Tang discloses claim 1, D1 further discloses: wherein the next hop of the VPN route comprises a host address for a compute node managed by the SDN controller, and wherein the VPN route comprises a VPN route advertised by the compute node (FIGs. 1-7 and the relevant text, such as c13/l31-48 “The stale routes are still retained in the routing table and still eligible for best path election, outbound advertisement, etc. The control node 54 also triggers a GR timer to begin after a configurable time period (e.g., 1 minute). This time period before the GR timer is triggered to begin may be referred to as a GR wait period. If and when control node 54 detects that the session comes back up, and relearns some or all paths from the resumed session, control node 54 clears the stale flag (only for those relearned paths). When the GR timer expires, control node 54 walks the table again and any paths that are still marked as Stale are swept (deleted) from the table by the control node 54” and c9/l34-40 “Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.”; note that IP networks are underlay networks).
As to claim 12, D1 in view of Tang discloses claim 11, D1 further discloses: advertising, by the compute node and to the leaf switch via a Border Gateway Protocol (BGP) session between the compute node and the leaf switch, an underlay network route to the compute node (FIGs. 1-7 and relevant text, such as c2/l34-38 “The techniques avoid the need to rely on a more heavy-weight network protocol such as a Border Gateway Protocol (BGP) to provide graceful restart functionality by using a BGP session between the SDN controller and the virtual agents to exchange the virtual routes” and c7/l19-32 “The techniques avoid the need to rely on a more heavy-weight network protocol such as a Border Gateway Protocol (BGP) to provide graceful restart functionality by using a BGP session between the SDN controller and the virtual agents to exchange the virtual routes”; note that each of TOR switch 24A to 24N is a leaf switch).
As to claim 13, D1 in view of Tang discloses claim 12, D1 further discloses wherein establishing the fault detection protocol session comprises establishing a Bidirectional Forwarding Detection session over the BGP session between the compute node and the leaf switch (FIGs. 1-7 and the relevant text, such as c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “stale” suggests fault detection and that each of TOR switch 24A to 24N is a leaf switch).
As to claim 14, D1 in view of Tang discloses claim 11, D1 further discloses: receiving, by the compute node operating as a messaging protocol client over a messaging protocol session between the SDN controller and the compute node, a plurality of VPN routes to other compute nodes managed by the SDN controller; and receiving, by the compute node operating as the messaging protocol client, a message withdrawing one of the plurality of VPN routes in response to the SDN controller receiving from a spine switch in the IP fabric a message withdrawing a corresponding underlay network route to one of the other compute nodes (FIG. 1-7 and the text associated with it, such as c9/l24-40 “Each of VR agents 36 may send messages to SDN controller 32 over XMPP sessions, the messages conveying virtual routes to the virtual interfaces (virtual addresses) of the VMs of servers 26. SDN controller 32 receives the messages and stores the virtual routes, and may in turn advertise one or more of the virtual routes from a first VR agent 36 to other VR agents 36. In some examples, any of the virtual routes may include a prefix, a next hop address associated with a server of servers 26, and a label or other data to identify a virtual routing and forwarding instance configured at the next hop server. A virtual route may include a Route Distinguisher (RD). Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.”, and c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “stale” suggests fault detection; note that FIG. 5B shows advertising the underlay IP network route to the at least one of a compute node via Overlay Tunnels; IP networks are underlay networks; and that FIG. 1 shows a spine switch as one of CHASSIS switch 22A to 22M).
As to claim 15, D1 in view of Tang discloses claim 11, D1 further discloses wherein advertising the compute node as the next hop for a VPN route comprises advertising the VPN route to the SDN controller as a messaging protocol client of the compute node operating as a messaging protocol server, wherein the VPN route comprises a virtual route to a virtual interface (FIG. 1-7 and the text associated with it, such as c9/l17-40 “each of servers 26 includes a corresponding one of VR agents 36A-36X that communicates with SDN controller 32 and, responsive thereto, directs virtual router 42 so as to control the overlay of virtual networks 46 and coordinate the routing of data packets within server 26. In general, each VR agent 36 communicates with SDN controller 32, which generates commands to control routing of packets through data center 10. Each of VR agents 36 may send messages to SDN controller 32 over XMPP sessions, the messages conveying virtual routes to the virtual interfaces (virtual addresses) of the VMs of servers 26. SDN controller 32 receives the messages and stores the virtual routes, and may in turn advertise one or more of the virtual routes from a first VR agent 36 to other VR agents 36. In some examples, any of the virtual routes may include a prefix, a next hop address associated with a server of servers 26, and a label or other data to identify a virtual routing and forwarding instance configured at the next hop server. A virtual route may include a Route Distinguisher (RD). Further details of BGP-signaled IP/VPNs are described in S. Mackie, BGP-signaled end-system IP/VPNs, Network Working Group Internet-Draft, Dec. 15, 2016, the entire contents of which are incorporated by reference herein.”; note that FIG. 5B shows advertising the underlay network route to the at least one of a compute node via Overlay Tunnels and IP networks are underlay networks).
Claims 5 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over D1 in view of Tang, further in view of Wang (US 20180159790 A1).
As to claim 5, D1 in view of Tang discloses claim 4, D1 is silent but Wang, in the same field of virtual routing, discloses wherein the fault detection protocol session comprises a Bidirectional Forwarding Detection (BFD) protocol session (suggested by “[0014] Here, to limit delay in the communication of control packets for fault detection, such as BFD and Border Gateway Protocol (BGP) packets, the network interface of the host computing systems may be used to prioritize the packets as they are communicated”). OOSA would be motivated to use the known technique of Wang above to the known SDN routing by D1 in view of Tang to yield the predictable results of quick failure response according to MEPE 2143 (D).
Therefore, it would have been obvious to OOSA before the time when the application was filed to combine D1 in view of Tang and Wang to use underlay network route as an indicator of a reachability status in the underlay network for routing of the particular one of the virtual routers for the benefit of quick fault detection ([0014] of Wang).
As to claim 20, D1 in view of Tang discloses claim 19, D1 further discloses being further configured to: advertise to the leaf switch via a Border Gateway Protocol (BGP) session between the computing device and the leaf switch, an underlay network route to the computing device (FIGs. 1-7 and the relevant text, such as c13/l25-36 “In accordance with the techniques of this disclosure, each of the control nodes 54 may be configured to employ a “mark and sweep” approach to retain and later purge routes. Routes are marked as stale and later purged if they have not been updated by the time a graceful restart timer associated with the XMPP session expires. More specifically, whenever a control node 54 detects that an XMPP session is closed (e.g., which may happen due to the VR agent 36 becoming unresponsive), control node 54 marks as stale all routes learned from VR agent 36 associated with the closed session with a stale flag in state data 56”; note that “stale” suggests fault detection and that each of TOR switch 24A to 24N is a leaf switch),
D1 in view of Tang is silent but Wang, in the same field of virtual routing, discloses wherein the fault detection protocol session comprises a Bidirectional Forwarding Detection session running over the BGP session between the computing device and the leaf switch (suggested by “[0014] Here, to limit delay in the communication of control packets for fault detection, such as BFD and Border Gateway Protocol (BGP) packets, the network interface of the host computing systems may be used to prioritize the packets as they are communicated” and “0017] To provide the SDNs, control packets, such as BFD packets, BGP packets, or some other control packets, are exchanged between physical host computing systems to provide various operations”; note both BFD may be chosen to run over BGP since the control protocols such as BFD and BGP may run co-currently). OOSA would be motivated to use the known technique of Wang above to the known SDN routing by D1 in view of Tang to yield the predictable results of quick failure response ([0014] of Wang) according to MEPE 2143 (D).
Therefore, it would have been obvious to OOSA before the time when the application was filed to combine D1 in view of Tang and Wang to use underlay network route as an indicator of a reachability status in the underlay network for routing of the particular one of the virtual routers for the benefit of quick fault detection ([0014] of Wang).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached on (571) 272-3927. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JIANYE WU/Primary Examiner, Art Unit 2462