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=40cisco....@dmarc.ietf.org> 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" <cho...@chopps.org> wrote: > > > Tony Przygienda <tonysi...@gmail.com> 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= >> 40cisco....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) >> Sent: Monday, November 22, 2021 11:47 AM >> To: lsr@ietf.org >> 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 >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
