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
