DETAILED ACTION
Response to Remark
This communication is considered fully responsive to the amendment filed on 07/27/26.
Independent claims have been amended.
Claims 2, 8, 12, 15-19, and 24 have been canceled.
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 of this title, 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, 7, 9, 11, 20, 21, and 25-28 are rejected under 35 U.S.C. 103 as being unpatentable over Means et al. (US 2020/0412601, “Means”) in view of Cassar (US 7,185,107, “Cassar”).
Regarding claim 1, Means discloses a method implemented by a first network device, wherein the method comprises:
- obtaining a first Border Gateway Protocol (BGP) route (See 119 Fig.2, recovery RR; See ¶.9, establishing a BGP SET in the recovery RR that manages a first provider edge BGP state between the recovery RR and the first set of provider edge devices. The BGP set may be a container that includes all neighbor configuration policies and parameters; See 123 Fig.2, the Recovery RR contains BGP SET-1, SET-2, & SET-3 information); and
- forwarding, to a second network device when the first network device is operational (See 119 Fig.2, recovery RR is operational) and fails to recurse the first BGP route by failing to resolve next-hop information in the first BGP route (See ¶.35, when a primary RR (e.g. RR1 101) fails. In that case, the BGP state between the recovery RR 119 and RR1 101 is idle. The change of BGP state is the trigger used by the activation module 122 on the recovery RR 119 to activate a peer relationship with the set of PEs (e.g. PE1A 107 and PE1B 109) associated with the primary RR (RR1 101) that failed), the first BGP route (See 315 Fig.3, monitor a first BGP state between the primary RR and the recovery RR; monitor a second BGP state between the second primary RR and the recovery RR; when the first BGP state is idle, i.e. fail, establish a peer session between the recovery RR and the first set of PEs; See ¶.35 for rerouting a new path procedure when the primary RR1 fails to forward for the next hops such as PE1A & PE2A)
- wherein the first network device is a first route reflector (RR) (See 119 Fig.2, recovery RR).
Means does not explicitly disclose newly added claim limitations, “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route.” However, Cassar discloses the method of “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route (Cassar, See Col.9, lns.31-32, indicates that this would be through recursion since a BGP hop installs recursive routes; See Col.14, lns.13-20, this PE would advertise any prefixes learnt from CE routers using an IP address in the transport network as the next hop address. This prefix would be propagated to the route reflector in SP3 as a VPNv4 update. The route reflector would reflect the VPNv4 updates to the rest of the PE routers in SP3 and it would also propagate the VPNv4 updates to the route reflectors in SP1 and SP2. The next hop would still be of an interface on PE3).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the method of “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route” as taught by Cassar into the system of Means, so that it provides a way the router reflector to reflect VPNv4 updates to the rest of the PE routers (Cassar, See Col.14, lns.11-25).
Regarding claim 7, Means discloses “the first network device and the second network device are External Border Gateway Protocol (eBGP) neighbors, or wherein the first network device and the second network device are Internal Border Gateway Protocol (IBGP) neighbors (See ¶.3 and ¶.5, eBPG and iBGP).”
Regarding claim 9, Means discloses “the first network device is a level-1 RR or a level-2 RR (See 119 Fig.1-2, the recovery RR as a level-1 RR).”
Regarding claim 11, it is a network device claim corresponding to the method claim 1, except the limitation “a memory and one or more processors (See Fig.5, a memory and a processor)” and is therefore rejected for the similar reasons set forth in the rejection of the claim.
Regarding claim 20, it is a non-transitory computer readable medium claim corresponding to the method claim 1 and is therefore rejected for the similar reasons set forth in the rejection of the claim.
Regarding claim 21, Means discloses “the first network device is the first RR comprises the first network device sharing BGP routes learned from one client with other clients (See ¶.5, the RR mechanism allows a iBGP router to act as a RR that advertises (reflects) the routes it learns from one iBGP router to other iBGP peers within the AS).”
Regarding claim 25, Means discloses “the first network device has both a route reflection function and a forwarding function (See Fig.2, RR).”
Regarding claim 26, Means discloses “obtaining the first BGP route comprises receiving the first BGP route from a third network device, wherein the method further comprises identifying, based on the first BGP route, an egress port used to reach the third network device when the first network device successfully recurses the first BGP route, and wherein the egress port is used to guide forwarding of traffic sent to the third network device (Means, See Fig.2; Cassar, See Fig.7 for forwarding to PEs).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 27, Means discloses “forwarding the first BGP route to the second network device comprises adding a router identifier of the first network device to a cluster list attribute of the first BGP route without modifying next-hop information in the first BGP route (Means, See ¶.6, the internal peers that connect to an RR are classified as RR client peers. An RR along with its client peers form a cluster. Each cluster can have multiple RRs which helps avoid a single point of failure and achieve redundancy. It is also possible to have multiple RRs within an AS where each RR is a non-client peer to another RR).”
Regarding claim 28, Means discloses “failing to resolve next-hop information in the first BGP route comprises failing to find, in a routing forwarding table of the first network device, an egress port to a next-hop node indicated by the next-hop information (See ¶.8, monitoring a BGP state between the first RR and the recovery RR and a BGP state between the second RR and the recovery RR. Establishing a peer session between the recovery RR and the first set of provider edge devices when the first RR fails and the first BGP state is idle).”
Claims 3, 4, 13-14, and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Means in view of Cassar and further in view of Sivabalan et al. (US 2022/0086078, “Sivabalan”).
Regarding claim 3, Means and Cassar do not explicitly disclose what Sivabalan discloses “the first BGP route is for a Segment Routing over Internet Protocol version 6 (SRv6) network, and wherein the first BGP route comprises a first segment identifier (SID) for indicating a destination network device (Sivabalan, See ¶.20, In SRv6, the SRGB is the set of global SRv6 SIDs in the SR domain; See ¶.17, destination based unicast forwarding).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “the first BGP route is for a Segment Routing over Internet Protocol version 6 (SRv6) network, and wherein the first BGP route comprises a first segment identifier (SID) for indicating a destination network device” as taught by Sivabalan into the system of Means and Cassar, so that segment routing provides full control over the path without the dependency on network state or signaling to set up a path (Sivabalan, See ¶.19).”
Regarding claim 4, Means discloses “forwarding, to the second network device and in response to detecting that the first BGP route fails to be recursed, the first BGP route” as rejected in claim 1, but Means and Cassar fail to disclose what Sivabalan discloses “detecting, based on the first SID not being locally stored, that the first BGP route fails to be recursed (Sivabalan, See ¶.23, when the head-end node receives a packet with an active segment matching the BSID of a local SR Policy, the head-end node steers the packet into the associated SR Policy; See ¶.25, SR also provides local protection via a mechanism called TI-LFA in which IGPs (OSPF, ISIS) compute a backup path for local failure; See ¶.26, with SR-TE, when a network element (link/node) fails, a head-end or PCE learns about the failure via IGP/BGP-LS, re-computes paths excluding the failed network element, and installs the new paths (i.e., re-optimized paths); See ¶.31, probing a local backup path utilizing the stored advertisement information, including a SID for the local backup path).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the method of “detecting, based on the first SID not being locally stored, that the first BGP route fails to be recursed” as taught by Sivabalan into the system of Means and Cassar, so that it provides a way for the head-end node to receive a packet with an active segment matching the BSID of a local SR Policy and then to steer the packet into the associated SR Policy (Sivabalan, See ¶.23).
Regarding claims 13 and 14, they are claims corresponding to claims 3 & 4, respectively and are therefore rejected for the similar reasons set forth in the rejection of the claims.
Regarding claim 22, Means and Sivabalan disclose “pre-configuring a forwarding policy (Means, See ¶.19, routing policy controlled by a central; Sivabalan, See ¶.18, end-to-end policy; See ¶.23 a head-end node of the SR policy binds a Binding SID (BSID) to its policy. … It is of special significance at the head-end node where the policy is programmed in forwarding); and directly forwarding, to the second network device without recursing the first BGP route (See Fig.1), the first BGP route when the forwarding policy indicates to not recurse the first BGP route (See Fig.1-2), wherein recursing the first BGP route comprises obtaining a next-hop node of the first BGP route (See ¶.3, next hop BGP router), and wherein forwarding, to the second network device when the first BGP route fails to be recursed (See Fig.2, fails to be recursed), the first BGP route comprises still forwarding, to the second network device when the first BGP route fails to be recursed (See Fig.2 and ¶.20, update BGP router to find neighbors BPG router), the first BGP route when the forwarding policy indicates to forward the first BGP route when recursing fails (see Fig.2 and ¶.35, when the primary RR1 101 fails, forwarding the BGP route).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “pre-configuring a forwarding policy” as taught by Sivabalan into the system of Means and Cassar, so that it provides a way of having a head-end node SR policy (Sivabalan, See ¶.23).
Regarding claim 23, Means and Cassar do not explicitly disclose what Sivabalan discloses “recursing fails comprises a segment identifier (SID) of the next hop node of the first BGP route not being locally stored by the first network device (Sivabalan, see ¶.3, enables the testing of backup paths to detect faulty backup paths before network failure automatically; See ¶.4, the steps can further include probing a local backup path utilizing the stored advertisement information including a SID for the local backup path; See ¶.26, with SR-TE, when a network element (link/node) fails, a head-end or PCE learns about the failure via IGP/BGP-LS, re-computes paths excluding the failed network element, and installs the new paths (i.e., re-optimized paths)).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “recursing fails comprises a segment identifier (SID) of the next hop node of the first BGP route not being locally stored by the first network device” as taught by Sivabalan into the system of Means and Cassar, so that it provides a way of recomputing paths excluding the failed network element (Sivabalan, See ¶.26).
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Means in view of Cassar and further in view of Heron et al. (US 2020/0099610, “Heron”).
Regarding claim 5, Means and Cassar do not explicitly disclose what Heron discloses “the first network device and the second network device are on a Segment Routing over Internet Protocol version 6-Best Effort (SRv6-BE) tunnel, or wherein the first network device and the second network device are on a Segment Routing over Internet Protocol version 6-Traffic Engineering (SRv6-TE) tunnel (Heron, ¶.15-16, SRv6 based on best effort (BE)).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “the first network device and the second network device are on a Segment Routing over Internet Protocol version 6-Best Effort (SRv6-BE) tunnel, or wherein the first network device and the second network device are on a Segment Routing over Internet Protocol version 6-Traffic Engineering (SRv6-TE) tunnel” as taught by Heron into the system of Means and Cassar, so that it provides a way for SR path to be based on best effort inter-domain reachability (Heron, See ¶.18).
Regarding claim 6, Means and Cassar do not explicitly what Heron discloses “receiving, from a third network device, the first BGP route, wherein the third network device has a Segment Routing over Internet Protocol version 6-Best Effort (SRv6-BE) tunnel established with the second network device, or wherein the third network device has a SRv6-TE tunnel established with the second network device (See ¶.15 and ¶.18, SRv6 based on BE for the tunneling mechanism).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 5.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Means in view of Cassar and further in view of Filsfils et al. (US 2018/0109450, “Filsfils”).
Regarding claim 10, Means and Cassar do not explicitly disclose what Filsfils discloses “the first network device and the second network device are in a multicast virtual private network (MVPN) (Filsfils, See ¶.44, multicast VPN for IPv6).” Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “the first network device and the second network device are in a multicast virtual private network (MVPN)” as taught by Filsfils into the system of Means and Cassar, so that it provides a way of allowing BGP update messages to carry routing information for multiple network layers and address families (Filsfils, See ¶.44).
Allowable Subject Matters
Claim 29 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed have been considered. But, in view of the applicant’s amendment to the claims, examiner has clarified and remapped the rejection to the argued claim limitations, using the prior art of record in the current prosecution of the claims and a new prior art by Cassar for the newly added claim limitations. The previous 102 rejection by Means has been replaced with a new 103 rejection over Means in view of Cassar.
At pages 8-12, with respect to claim 1, applicant’s key argument is that “therefore, Means fails to forward, to a second network device when a first network device is operational and fails to recurse a first BGP route, the first BGP route, and install the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route. As such, Means fails to disclose at least one limitation of independent claims 1, 11, and 20, and consequently fails to anticipate claims 1, 7, 9, 11, and 20-21.”
In reply, As shown in Fig.1, Means discloses that recovery RR and RR1-3 has the function of route reflector and Means discloses that BGP protocol has the function of forwarding BGP update and the Recovery RR has the function of BGP as shown 123 Fig.1. Para.[0003] of Means also shows the details of BGP function on the method of forwarding BGP update, saying “Border Gateway Protocol (BGP) is the routing protocol of the Internet. It is used to exchange routing information between Autonomous Systems (AS) and routing traffic across the Internet. Forwarding BGP updates within an AS introduces a couple of challenges. First, BGP requires a BGP router to add its own AS number (ASN) entry to the AS_PATH attribute when forwarding BGP route updates to another AS. The AS_Path attribute identifies the ASes through which an UPDATE message has passed and lists in reverse order the ASes traversed by a prefix, with the last AS placed at the beginning of the list. The primary purpose of AS_PATH is to provide loop-prevention during inter-AS routing. Second, to avoid routing loops, BGP drops a route if a BGP router sees its own ASN in the AS_PATH list. Thus, when forwarding a BGP route advertisement through the routers within an AS, each BGP edge router will add its own ASN to the AS_PATH list. But the next hop BGP router, which is in the same AS, sees its own ASN in the AS_PATH list, assumes that a loop has occurred and drops the route. Although this can be overcome by redistributing all BGP routes into an interior gateway protocol (IGP), and not using BGP, the large number of routes advertised by BGP can cause IGP to crash. To avoid this an internal BGP (iBGP) is used to forward route advertisements received from an external BGP router through the internal network. With iBGP, a router within an AS does not exchange routing updates to another iBGP router. The ASN is added and routes are advertised only when they are being sent to a BGP router in another autonomous system, i.e. to an eBGP router. However, because routing updates learned are not advertised to other iBGP peers to prevent loops, route reachability must be achieved by using a full-mesh topology between all the iBGP peers. This means that every device within an AS is logically connected to every other device through a peering relationship.” Further, as rejected in a new 103 rejection, Cassar discloses the method of recursing BGP route and installing the BGP route in a forwarding table.
In other words, Means does not explicitly disclose the method of “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route.” However, Cassar discloses the method of “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route (Cassar, See Col.9, lns.31-32, indicates that this would be through recursion since a BGP hop installs recursive routes; See Col.14, lns.13-20, this PE would advertise any prefixes learnt from CE routers using an IP address in the transport network as the next hop address. This prefix would be propagated to the route reflector in SP3 as a VPNv4 update. The route reflector would reflect the VPNv4 updates to the rest of the PE routers in SP3 and it would also propagate the VPNv4 updates to the route reflectors in SP1 and SP2. The next hop would still be of an interface on PE3)” as rejected in claim 1. Therefore, ordinary skill in the art applies the method of “installing the first BGP route in a forwarding plane to forward traffic based on the first BGP route when the first network device is operational and successfully recurses the first BGP route” as taught by Cassar into the system of Means in order for the router reflector to reflect BGP route updates to the rest of the PE routers. Therefore, the examiner respectfully disagrees.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jung H Park whose telephone number is 571-272-8565. The examiner can normally be reached M-F: 7:00 AM-3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Derrick Ferris can be reached on 571-272-3123. 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.
/JUNG H PARK/
Primary Examiner, Art Unit 2411
Prosecution Insights