I agree with Les. This draft seems unnecessary.
The only thing that I would like to add is that the problem described by Zhuo is addressed by the use of route tags along with appropriate policy to avoid looping when doing redistribution between instances. Thanks, Ketan On Wed, Nov 9, 2022 at 10:03 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > 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. > > > > > > > > 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] > <[email protected]>] > > 发送时间: 2022年11月5日 2:17 > > 收件人: draft-yue-lsr-loop-detection-for-imported-routes.auth...@ietf.org > > 抄送: [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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
