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 ... -- 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
