sorry, seems you didn't parse what I wrote in previous email and keep on generating FUD. The solution is loop free if the draft is correctly implemented in both tunnel and no-tunnel scenario. The rest is subtlety of how you deploy it (and implementation choices) that I tried to explain. I cannot put it more simply than that ...
-- tony On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang <[email protected]> wrote: > Hi, Tony: > > The advantage of IGP is that it can cure itself when there is any topology > change, no additional operator intervention involved. > But from your explanation below, there are situations that the draft > doesn’t covered for the possible loop scenarios. Additional route compare > rules or configuration requirements needed to be added when such thing > happens. Then can we call the current solution is not final? > And, if we lack one trust theory to avoid the loop, we will be stuck in > the emerged loop situations. > > Some additional replies inline. > > Aijun Wang > China Telecom > > On Dec 11, 2021, at 20:08, Tony Przygienda <[email protected]> wrote: > > > let's be more precise beyond sensationalist headlines ... Though it's nice > you found our documentation and based on that make first technical argument > ;-) > > a) transitory loops during convergence/tunnel setup may exist, those also > exist during normal ISIS convergence. Simple implementation techniques used > in other contexts since many years exist like e.g. holding the router in > overload until converged. That can be also easily implemented if e.g. a FR > client has no FR tunnel established. A draft/spec is not an implementation > description however so techniques deployed can be very different and > starting to put that in will lead to overspecification. > > > [WAJ] From the example that illustrated in the mentioned example, it seems > the loop is not transient. It seems when R1 is not act as FR client, the > loop will occur then? > > b) let's split the rest assuming full convergence scenario into tunnel; > and no L1 tunnels case > ib.) L1 tunnel case when all tunnels in place/converged is simple, it's > identical really to any shortcut forwarding where the next hop is a tunnel, > the packet just shows up magically @ the egress. this is AFAIS simpler > option to understand and deploy correctly. If you harbor fears and doubts > about the whole thing or looping potential, just use this. > > > [WAJ] Then the merit that you compared with TTZ will go away? > > b.ii) no tunnel case is more delicate (but hotly desired by many [arguably > sophisticated] customers hence the work). If the SPF is implemented > correctly no routing loops exist when converged. > > This preconditions also correct leaking of L1 into L2 (hence the "all > egress MUST be clients", it could work with a mix but the draft gets > unnecessarily complex) and section 5.2 of the draft provides the necessary > implementation on SPF to prevent loops in every case. > > [WAJ] As Acee pointe out also, this section is harder to understand and > not in clear logic. I doubt and am unconvinced that it can cover every case. > > However, as the documentation you found says it is easier to ensure that > L1 metrics when deployed are shorter than L2 metrics so the L1->L2 route > always takes preference towards the egress and not rely on the correct SPF > preferece outside metric comparison. > > > [WAJ] To achieve this, the design should be verified by manual carefully? > > As footnote: redistributing prefixes in ISIS is always delicate, nothing > new here, L1->L2->L1 was originally forbidden and only works with the RFC > and lots of tightly kept pref rules. With enough inventive re-distribution > on a system around the RFC and fiddiling via policy with redistributed > route properties you can loop up normal ISIS as well BTW. > > > [WAJ] Can I say that your solution is based on the original forbidden > design? To explore the forbidden, you introduce the additional SPF rules. > When the topology or interconnection scenario become complex, will the SPF > rules complex also? > > c) ECMP, yes, as our doc says it's not looping but it can be changed when > using b.ii) unless whole network is forklifted to flood reflection and e.g. > omits ECMP computed over FR adjacencies which again, is an implementation > technique that is optional complexity since FR adjacencies are not > forwarding (one could make them taht and stuff would still work but then we > would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP > inside L1 and ultimately shove e'thing though FRs, most customers think > that doing L2 hot potato forwarding out the area is actually far preferred > IME). > > And no, you will never achieve the same "globally optimal" routing through > the whole topology in L2 when abstracting some L1 things except when you > advertise a full mesh of links reflecting all ingress-egress metrics in L2 > being basically L1 shortest path (or assume that all ingress/egress > connections have infinite/same metric, it's called a chassis or more > precisely a switching fabric then ;-). Beside scaling very poorly as the > draft explains this can also cause a single link failing in L1 to cause a > havoc of advertisements in L2 and if you are experienced in operational > matters this is the last things you desire. In more abstract control theory > terms you are building with such a solution a negatively stable system of > control loops or in simpler terms an invisible big blast radius. Good for > fighter planes, very bad for networking if you experienced those effects. > > hope that's enough details, none of this is BTW pure speculation but > output of implemenation and extensive testing. > > --- tony > > On Sat, Dec 11, 2021 at 8:48 AM Aijun Wang <[email protected]> > wrote: > >> Please refer to “Routing Loops” section that described in your company’s >> documents: >> >> https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162 >> >> This is just the simplest transit scenario. I am worrying for its further >> applications. >> >> The overall routing path for L2 topologies that connected by several L1 >> is not determined by one L2 SPF algorithm, how can you assure no loop occur? >> >> Is it nightmare or mess for the operator to run its network in such >> challenges situations? >> >> Aijun Wang >> China Telecom >> >> On Dec 11, 2021, at 02:02, Tony Przygienda <[email protected]> wrote: >> >> >> What you describe is not technical reality when you're dealing with SPF >> in L2 ... You seem to be deeply confused (but honestly, I have a hard time >> to even figure out what kind of assumptions you're making about all kind of >> things in all those threads about IGPs these days and on what but personal >> preferences all those claims of "better" things are based) by the simple >> fact that there is only a single connected L2 area ever in ISIS, if you >> partition L2 you do not run ISIS within its viable envelope anymore, with >> or without extensions. And L2 SPF will never loop and flood reflector draft >> does not change the path taken in L2 so by first order logic you won't >> loop. That is BTW one of the reasons why you will want to deploy multiple >> flood reflectors per L1 (to not partition L2). >> >> As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2 >> could in ISIS from day one use L1 to "traverse across" (if you squint a bit >> ;-) in a sense and those drafts just improve the behavior so we are not >> even architecturally changing the topological properties of the protocol >> (whatever that means without delving deeply into graph theory definitions >> ;-) >> >> -- tony >> >> On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang <[email protected]> >> wrote: >> >>> Hi, Acee: >>> >>> No, I think the WG participations would like to enjoy the interested and >>> correct direction topics. >>> One technical considerations is the following: if IGP evolved into this >>> direction, then the following connections loop diagram is also possible: >>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin) >>> Then, will we introduce the “AS number” to avoid loop, and various “Path >>> Attributes” to influence the path selection within the IGP? >>> >>> There is a rush to adopt this draft, we should not rush again to >>> accomplish its WG last call. >>> >>> >>> Aijun Wang >>> China Telecom >>> >>> On Dec 9, 2021, at 10:07, Acee Lindem (acee) <acee= >>> [email protected]> wrote: >>> >>> >>> >>> Hi Aijun, >>> >>> >>> >>> At least I’ve had several discussions with authors on the draft and >>> you’ll note my comments on the list. The lack of further discussion on the >>> list is a general problem in LSR. It seems many WG participants only want >>> to discuss the draft that they have authored and it is hard to get comment >>> without forcing the issue without an adoption or last call. I’m expecting >>> at least one more review on the draft. Technical comments on the draft >>> would be appreciated. >>> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> >>> *From: *Aijun Wang <[email protected]> >>> *Date: *Wednesday, December 8, 2021 at 11:15 AM >>> *To: *Acee Lindem <[email protected]> >>> *Cc: *"Les Ginsberg (ginsberg)" <[email protected]>, "[email protected]" < >>> [email protected]> >>> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" >>> -draft-ietf-lsr-isis-flood-reflection-05 >>> >>> >>> >>> Hi, Acee: >>> >>> >>> >>> I found there is no any technical discussion on the list for the >>> mentioned draft after its adoption(from 2020-7-6), even before its adoption. >>> >>> There is only one presentation for its update at the IETF 111 meeting(1 >>> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call >>> is issued. >>> >>> >>> >>> From the authors’ statement, there is only the author’s affiliation >>> implemented it, no interoperability problems can be found. >>> >>> >>> >>> From the discussion in these days, it is doubtful for IGP to evolve into >>> this direction as behaved by BGP. >>> >>> >>> >>> From the POV of the operator, we will not consider such strange design >>> to scale the IS-IS. >>> >>> >>> >>> From the documents itself, there are unsolved problems (for example in >>> section 7) which can only be solved by “sending alarm and declare >>> misconfiguration). >>> >>> >>> >>> Then, why it is ready to WG Last Call? >>> >>> >>> >>> >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> >>> >>> On Dec 8, 2021, at 06:28, Acee Lindem (acee) <acee= >>> [email protected]> wrote: >>> >>> Hi Les, >>> >>> >>> >>> *From: *"Les Ginsberg (ginsberg)" <[email protected]> >>> *Date: *Tuesday, December 7, 2021 at 5:10 PM >>> *To: *"Acee Lindem (acee)" <[email protected]>, Acee >>> Lindem <[email protected]>, "[email protected]" <[email protected]> >>> *Subject: *RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" >>> -draft-ietf-lsr-isis-flood-reflection-05 >>> >>> >>> >>> Let me try to respond to Acee/Tony/Tony in one email. >>> >>> >>> >>> Acee – I don’t like any of the proposals. I believe they are all abusing >>> the protocols to some degree. >>> >>> >>> >>> That’s fine if you have technical concerns with the individual drafts. >>> The problem space discussion is a moot point since the WG has already >>> adopted these documents. >>> >>> >>> >>> Thanks, >>> >>> Acee >>> >>> >>> >>> I fully believe that the authors are clever enough to figure out how to >>> make this work – but that doesn’t mean any of them are desirable. >>> >>> So if I have to “vote” – I vote “no”. >>> >>> >>> >>> Tony Li – >>> >>> >>> >>> Area Proxy Introduction says in part: >>> >>> >>> >>> “Following the current rules of IS-IS, all spine routers would >>> >>> necessarily be part of the Level 2 topology, plus all links between a >>> >>> Level 2 leaf and the spines. In the limit, where all leaves need to >>> >>> support Level 2, it implies that the entire L3LS topology becomes >>> >>> part of Level 2. This is seriously problematic as it more than >>> >>> doubles the LSDB held in the L3LS topology and eliminates any >>> >>> benefits of the hierarchy.” >>> >>> >>> >>> Flood Reflection says: >>> >>> >>> >>> “In such scenarios, an >>> >>> alternative approach is to consider multiple L2 flooding domains >>> >>> connected together via L1 flooding domains. In other words, L2 >>> >>> flooding domains are connected by "L1/L2 lanes" through the L1 areas >>> >>> to form a single L2 backbone again. Unfortunately, in its simplest >>> >>> implementation, this requires the inclusion of most, or all, of the >>> >>> transit L1 routers as L1/L2 to allow traffic to flow along optimal >>> >>> paths through such transit areas. Consequently, this approach fails >>> >>> to reduce the number of L2 routers involved, so it fails to increase >>> >>> the scalability of the L2 backbone.” >>> >>> >>> >>> >>> >>> These problem statements seem fundamentally similar to me. >>> >>> >>> >>> No question the two drafts define very different solutions – but the >>> problem statements seem quite similar to me. >>> >>> >>> >>> Tony P – I would argue that a “20K perspective” is useful when deciding >>> whether the overall approach is a good one. >>> >>> >>> >>> And in response to Tony Li’s statement: “…the IETF is at its best when >>> it is documenting de facto standards” >>> >>> >>> >>> 1) I fully believe that our customers understand their requirements(sic) >>> better than we (vendors) do. But that does not mean that they understand >>> what is the best solution better than we do. >>> >>> When a customer comes to me and says “Can you do this?” my first >>> response is usually “Please fully describe your requirements independent of >>> the solution.” >>> >>> >>> >>> 2)Not clear to me that there is an existing “de facto standard” here – >>> which is reinforced by the fact that we have so many different solutions >>> proposed. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> >>> >>> *From:* Acee Lindem (acee) <[email protected]> >>> *Sent:* Tuesday, December 7, 2021 10:31 AM >>> *To:* Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem (acee) < >>> [email protected]>; [email protected] >>> *Subject:* Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" >>> -draft-ietf-lsr-isis-flood-reflection-05 >>> >>> >>> >>> Hi Les, >>> >>> >>> >>> *From: *Lsr <[email protected]> on behalf of "Les Ginsberg >>> (ginsberg)" <[email protected]> >>> *Date: *Tuesday, December 7, 2021 at 1:17 PM >>> *To: *"Acee Lindem (acee)" <[email protected]>, " >>> [email protected]" <[email protected]> >>> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" >>> -draft-ietf-lsr-isis-flood-reflection-05 >>> >>> >>> >>> When I look at this request, I see it in a larger context. >>> >>> >>> >>> There are two drafts which attempt to address the same problem in very >>> different ways: >>> >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/ >>> >>> >>> >>> and >>> >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ >>> >>> >>> >>> Both of them discuss in their respective introductions the motivation – >>> which is to address scaling issues in deployment scenarios where the >>> existing IS-IS hierarchy is being asked to “stand on its head” i.e., >>> interconnection between different L1 areas is not to be achieved by >>> utilizing an L2 backbone – rather it is the L1 areas themselves which are >>> required to be used for interconnection of sites (e.g., two datacenters) >>> and the scaling properties of the existing protocol hierarchy when used in >>> this way are not attractive. >>> >>> >>> >>> I find no technical basis on which to choose between the two proposed >>> solutions – so in my mind a last call for “Flood-Reflection” presupposes a >>> last call for “Area Proxy” – and therein lies my angst. >>> >>> The end result will be that multiple incompatible solutions to the same >>> problem will be defined. It will then be left to customers to try to >>> determine which of the solutions seems best to them – which in turn will >>> put the onus on vendors to support both solutions (depending on the set of >>> customers each vendor supports). >>> >>> This – to me – represents an utter failure of the standards process. We >>> are reduced to a set of constituencies which never find common ground – the >>> end result being sub-optimal for the industry as a whole. >>> >>> >>> >>> It seems to me that the proper role of the WG is to address the big >>> questions first: >>> >>> >>> >>> 1)Is this a problem which needs to be solved by link-state protocols? >>> >>> We certainly have folks who are clever enough to define solutions – the >>> two drafts are a proof of that. >>> >>> But whether this is a wise use of the IGPs I think has never been fully >>> discussed/answered. >>> >>> Relevant to this point is past experience with virtual links in OSPF – >>> use of which was problematic and which has largely fallen out of use. >>> >>> Also, many datacenters use BGP (w or w/o IGP) and therefore have other >>> ways to address such issues. >>> >>> Although I am familiar with the “one protocol is simpler” argument, >>> whether that justifies altering the IGPs in any of the proposed ways is >>> still an important question to discuss. >>> >>> >>> >>> Given the discussions of these solutions over the last two years in LSR, >>> I don’t think we need to rehash this – especially on the experimental >>> track. >>> >>> >>> >>> 2)If link state protocols do need to solve this problem, what is the >>> preferred way to do that? >>> >>> This requires meaningful dialogue and a willingness to engage on complex >>> technical issues. >>> >>> >>> >>> The alternative is to do what we seem to be doing – allowing multiple >>> solutions to move forward largely without comment. In which case I see no >>> basis on which to object – anyone who can demonstrate a deployment case >>> should then be allowed to move a draft forward – and there are then no >>> standardized solutions. >>> >>> (The Experimental Track status for these drafts reflects that reality.) >>> >>> >>> >>> Are you saying you don’t want any experimental solutions unless we have >>> one standardized solution that everybody agrees on? Please review this one >>> as part of WG last call. >>> >>> >>> >>> Thanks, >>> >>> Acee >>> >>> >>> >>> Les >>> >>> >>> >>> P.S. (Aside: There is a third draft offering a solution in this space >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/ - but as >>> that draft continues to promote its primary usage as a means of more easily >>> changing area boundaries (merging/splitting) I have not discussed it here. >>> However, if the authors of that draft claim it as a solution to the same >>> problem space claimed by Area Proxy/Flood Reflection then the WG would have >>> no basis but to also progress it – which would result in three solutions >>> being advanced.) >>> >>> >>> >>> >>> >>> >>> >>> *From:* Lsr <[email protected]> *On Behalf Of *Acee Lindem (acee) >>> *Sent:* Monday, November 22, 2021 11:47 AM >>> *To:* [email protected] >>> *Subject:* [Lsr] WG Last Call fo "IS-IS Flood Reflection" >>> -draft-ietf-lsr-isis-flood-reflection-05 >>> >>> >>> >>> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. >>> Please post your support or objection to this list by 12:00 AM UTC on Dec >>> 14th >>> , 2021. Also please post your comments on the draft. I’m allowing as >>> extra week as I like to get some additional reviews – although my comments >>> have been addressed. >>> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
