Zhuo – Let’s just start with the basics.
Your draft proposes to advertise three things: 1)S flag This is functionally equivalent to X flag in RFC 7794. 2)R flag This is functionally equivalent to the R flag in RFC 7794 3)Router ID This is functionally equivalent to the Router-ID sub-TLVs defined in RFC 7794. However, you use “system-id” whereas RFC 7794 supports IPv4 and/or IPv6 IDs. Using IP/IPv6 addresses for the ID is much more useful since the system-id of the router in the source area will be unknown in the destination area – but we can still have knowledge and a path to the IP/IPv6 addresses of the source in the destination area. So anything that can be done with your proposed advertisements can be done with RFC 7794. This should be sufficient to end consideration of your draft. A few other comments based on the example below. You seem to suggest (though your draft does not actually say this) that the “router-id” is actually intended to be a list of router ids, which increases in length as you redistribute from instance 1 to instance 2 to instance 3 to … But redistribution is not only done between one IS-IS instance and another, but also between different protocols (e.g., OSPF-> IS-IS) – which means that the “history” you propose to maintain is not guaranteed to be available. In addition, in an area where there are multiple ABRs, redistribution will likely occur on all of the ABRs – further complicating any attempt to track redistribution history. Thanx. Les From: yuezhuo <[email protected]> Sent: Tuesday, November 8, 2022 6:36 PM To: Les Ginsberg (ginsberg) <[email protected]>; draft-yue-lsr-loop-detection-for-imported-routes.auth...@ietf.org Cc: [email protected] Subject: Reply: Comments on draft-yue-lsr-loop-detection-for-imported-routes Hi Les, Thanks for your comments about the draft. There is no doubt that TLVs defined in RFC 7794 could solve some routing loop problems. However, when mutual route imported are configured among more than two IS-IS instance, there still might be routing loop problems. Shown as the following scenario, route 1.1.1.1/32 is imported among three IS-IS areas. [cid:[email protected]] In step 1, when the route 1.1.1.1/32 is imported to IS-IS 2 area from IS-IS 1 area without inherit-cost, the External Prefix Flag will be set and the source ID of RTA will be advertised to IS-IS 2 area, we mark this route as (1.1.1.1, X, RTA, RTC) in the format of (prefix, X-flag, source router, redistribute router list). RTD will calculate a route to 1.1.1.1, with the cost being 20 and the outbound of interface is Interface D.1。 RTG will calculate a route to 1.1.1.1, with the cost being 20 and the outbound of interface is Interface G.1。 In step 2, the route is imported to IS-IS 3 area，the route can be marked as (1.1.1.1, X, RTA, RTC-RTD), RTG will calculate a route to 1.1.1.1, with the cost being 10 ，which is smaller than that (20) of the route calculated by IS-IS 2, and the outbound of interface is Interface G.2。 In step 3, the route is imported and advertised to IS-IS 2 area again by RTG , the route can be marked as (1.1.1.1, X, RTA, RTC-RTD-RTG). After RTG imported the route 1.1.1.1 from IS-IS 3 , there will be two route source(RTC, RTG) for prefix 1.1.1.1 in the area of IS-IS 2. There is no difference between route (1.1.1.1, X, RTA, RTC) and route (1.1.1.1, X, RTA, RTC-RTD-RTG) in IS-IS 2 area, they are both external prefix with the same priority. Thus, RTD will calculate a route to 1.1.1.1 with cost being 10, which is smaller than that (20) of the route calculated previously in step 1, and the outbound of interface will be interface D.2. After the active route to 1.1.1.1 on RTD is updated, IS-IS process 3 still imports the route from IS-IS process 2 as the route remains active, and continues to advertise/update an LSP. A stable routing loop is formed. Assuming that traffic is injected from RTE, routing loop occurs between RTD and RTG。 With the extend TLV we introduced in the draft, After step 3, when IS-IS process 3 still imports the route from IS-IS process 2, RTD can find it’s router id in the re-distribution list and realize the imported route has already been advertise by itself and there might be routing loop problems. The sub-TLV we proposed in the draft can help detect the routing loop when mutual route import happen among more than two IGP areas. Looking forward to further discussions. Best, Zhuo -----邮件原件----- 发件人: Les Ginsberg (ginsberg) [mailto:[email protected]] 发送时间: 2022年11月5日 2:17 收件人: draft-yue-lsr-loop-detection-for-imported-routes.auth...@ietf.org<mailto:draft-yue-lsr-loop-detection-for-imported-routes.auth...@ietf.org> 抄送: [email protected]<mailto:[email protected]> 主题: Comments on draft-yue-lsr-loop-detection-for-imported-routes Draft authors - I have read the draft. Everything you propose has already been defined in RFC 7794. This draft is completely redundant and should be abandoned. In light of this, you should consider withdrawing your item from the WG meeting agenda - there is no reason for the WG to consider this draft. Les
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
