I’d very much support applicability draft work! Cheers, Jeff
> On Jan 3, 2022, at 08:05, Tony Przygienda <[email protected]> wrote: > > > AFAIS this is a "operational and deployment" or "applicability" draft and not > part of a protocol specification. But yes, such a draft would have value > AFAIS, especially if it deals with both abstract node & reflection in one as > available solutions. More than happy to attack that once the specs have > moved to publication. > > -- tony > >> On Mon, Jan 3, 2022 at 1:05 PM 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
