Tony Przygienda <[email protected]> writes:
I wonder whether this is now a general rule for all future ISIS drafts suggesting extensions or a one off random thing and we can come up for future drafts with arbitrary list of related drafts that we will precondition to gate publish/acceptance/whatever ... just trying to figure out what the process is here ...
Well since he was "Speaking as a document shepherd", it can't be a new general rule, b/c document shepherds don't get to set general rules for a WG. :) I sense some frustration here, though. As a WG, we generally haven't advanced multiple solutions like we have in this case. So, I don't think we can talk about any sort of previously existing standard process. And with my WG chair hat on I'll say: I hope we don't repeat this method very often in the future. As WG Member: I didn't intend to pause forward progress when I originally asked if any guidance had been captured to help users select between the multiple options. It was just a natural thing to ask when you mentioned that certain network designs lined up better with one solution or the other. Thanks, Chris.
-- tony On Wed, Jan 12, 2022 at 5:16 PM Acee Lindem (acee) <[email protected]> wrote: Speaking as document shepherd: Who thinks we should delay this draft while waiting for a deployment draft? I know some people supported this but I believe it would be better to move forward with this experimental draft. Given that there were 3 separate proposals for this topology to use level-1 as a transit for level-2. We’ve already established that there is a requirement. Also, I agree with Tony in that comments should be technical rather than simply that you don’t like it or you think it is complex. Thanks, Acee From: Tony Przygienda <[email protected]> Date: Monday, January 10, 2022 at 2:36 PM To: Acee Lindem <[email protected]> Cc: Aijun Wang <[email protected]>, Christian Hopps < [email protected]>, "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 yes, first, if you abstract in _any_ way (except a full mesh for a single metric) you will end up with suboptimal paths (compared to global, flat topology view) traversing an abstracted subgraph and different ECMP behavior in corner cases, it's basic graph theory (aggravated by hop-by-hop or loose-source route forwarding planes) and is a well-known problem encountered in any hierarchical network, be it IGP, seamless MPLS or even BGP (look @ AIGP). FR deployed with underlying tunnels in L1 does not loop and neither does it when deployed correctly with prefix leaking. I cannot help it if a single person on this list is harboring fears, preferences and doubts without hard technical arguments to make for a meaningful discussion so I think it's time to put that repetitive sub-thread aside. As I said, I will be more than happy to help on a "deployment considerations" or some such draft once those documents move up to publication so we have stable references to talk about ... thanks -- tony On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee) < [email protected]> wrote: I'll defer to Tony but my understanding is that there could be suboptimal paths if there are both Level-1 and Level-2 paths but not loops. Thanks, Acee On 1/10/22, 11:38 AM, "Aijun Wang" <[email protected] > wrote: But there are unsolved issues for this draft—— BGP has loop prevention mechanism, current flood reflection draft hasn’t, the operator must design the topology/link metric carefully to avoid the possible loop. Aijun Wang China Telecom > On Jan 11, 2022, at 00:10, Acee Lindem (acee) <acee= [email protected]> wrote: > > Speaking as a WG member, these documents are all "experimental" and, IMO, it would really stifle innovation to require a single experimental solution. We've never done that in the past. Also, while all three solutions have the goal of reducing control plane overhead when using Level-1 areas as a transit, the flood reflection draft solves the problem with a different approach than the area proxy and TTZ drafts. While the latter two focus on abstracting the transit area, the former also focusing on reducing the number of adjacencies and allows the reflector to be out of the data path (similar to the standardized and widely deployed BGP route reflection) I see no need to differentiate to stall advancement. > > Thanks, > Acee > > On 1/3/22, 7:05 AM, "Christian Hopps" < [email protected]> wrote: > > > Tony Przygienda <[email protected]> writes: > >> One thing Les is missing here is that proxy & reflection present in >> terms of deployment requirements and ultimate properties very >> different engineering & operational trade-offs. Different customers >> follow different philosophies here IME >> >> So we are not strictly standardizing here 2 solutions for the same >> thing, we are standardizing two solutions that meet very different >> deployment and operational requirements albeit from 20K feet view all >> that stuff looks the same of course as any other thing does ... > > Have we captured these "different deployment and operational requirements" anywhere? I think might be very useful... > > Thanks, > Chris. > [as wg member] > > >> -- tony >> >> On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg) <ginsberg= >> [email protected]> wrote: >> >> >> 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. >> >> >> >> 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.) >> >> >> >> 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 14 ^th , 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
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
