Hi, Acee: No, I think the WG participations would like to enjoy the interested and correct direction topics. One technical considerations is the following: if IGP evolved into this direction, then the following connections loop diagram is also possible: L2-L1-L2-L1-L2-L1-…..-L2(back to the origin) Then, will we introduce the “AS number” to avoid loop, and various “Path Attributes” to influence the path selection within the IGP?
There is a rush to adopt this draft, we should not rush again to accomplish its WG last call. Aijun Wang China Telecom > On Dec 9, 2021, at 10:07, Acee Lindem (acee) > <[email protected]> wrote: > > > Hi Aijun, > > At least I’ve had several discussions with authors on the draft and you’ll > note my comments on the list. The lack of further discussion on the list is a > general problem in LSR. It seems many WG participants only want to discuss > the draft that they have authored and it is hard to get comment without > forcing the issue without an adoption or last call. I’m expecting at least > one more review on the draft. Technical comments on the draft would be > appreciated. > > Thanks, > Acee > > From: Aijun Wang <[email protected]> > Date: Wednesday, December 8, 2021 at 11:15 AM > To: Acee Lindem <[email protected]> > Cc: "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 > > Hi, Acee: > > I found there is no any technical discussion on the list for the mentioned > draft after its adoption(from 2020-7-6), even before its adoption. > There is only one presentation for its update at the IETF 111 meeting(1 > pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call > is issued. > > From the authors’ statement, there is only the author’s affiliation > implemented it, no interoperability problems can be found. > > From the discussion in these days, it is doubtful for IGP to evolve into this > direction as behaved by BGP. > > From the POV of the operator, we will not consider such strange design to > scale the IS-IS. > > From the documents itself, there are unsolved problems (for example in > section 7) which can only be solved by “sending alarm and declare > misconfiguration). > > Then, why it is ready to WG Last Call? > > > Aijun Wang > China Telecom > > > On Dec 8, 2021, at 06:28, Acee Lindem (acee) > <[email protected]> wrote: > > Hi Les, > > From: "Les Ginsberg (ginsberg)" <[email protected]> > Date: Tuesday, December 7, 2021 at 5:10 PM > To: "Acee Lindem (acee)" <[email protected]>, Acee Lindem > <[email protected]>, "[email protected]" <[email protected]> > Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" > -draft-ietf-lsr-isis-flood-reflection-05 > > Let me try to respond to Acee/Tony/Tony in one email. > > Acee – I don’t like any of the proposals. I believe they are all abusing the > protocols to some degree. > > That’s fine if you have technical concerns with the individual drafts. The > problem space discussion is a moot point since the WG has already adopted > these documents. > > Thanks, > Acee > > I fully believe that the authors are clever enough to figure out how to make > this work – but that doesn’t mean any of them are desirable. > So if I have to “vote” – I vote “no”. > > Tony Li – > > Area Proxy Introduction says in part: > > “Following the current rules of IS-IS, all spine routers would > necessarily be part of the Level 2 topology, plus all links between a > Level 2 leaf and the spines. In the limit, where all leaves need to > support Level 2, it implies that the entire L3LS topology becomes > part of Level 2. This is seriously problematic as it more than > doubles the LSDB held in the L3LS topology and eliminates any > benefits of the hierarchy.” > > Flood Reflection says: > > “In such scenarios, an > alternative approach is to consider multiple L2 flooding domains > connected together via L1 flooding domains. In other words, L2 > flooding domains are connected by "L1/L2 lanes" through the L1 areas > to form a single L2 backbone again. Unfortunately, in its simplest > implementation, this requires the inclusion of most, or all, of the > transit L1 routers as L1/L2 to allow traffic to flow along optimal > paths through such transit areas. Consequently, this approach fails > to reduce the number of L2 routers involved, so it fails to increase > the scalability of the L2 backbone.” > > > These problem statements seem fundamentally similar to me. > > No question the two drafts define very different solutions – but the problem > statements seem quite similar to me. > > Tony P – I would argue that a “20K perspective” is useful when deciding > whether the overall approach is a good one. > > And in response to Tony Li’s statement: “…the IETF is at its best when it is > documenting de facto standards” > > 1) I fully believe that our customers understand their requirements(sic) > better than we (vendors) do. But that does not mean that they understand what > is the best solution better than we do. > When a customer comes to me and says “Can you do this?” my first response is > usually “Please fully describe your requirements independent of the solution.” > > 2)Not clear to me that there is an existing “de facto standard” here – which > is reinforced by the fact that we have so many different solutions proposed. > > Les > > > > From: Acee Lindem (acee) <[email protected]> > Sent: Tuesday, December 7, 2021 10:31 AM > To: Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected] > Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" > -draft-ietf-lsr-isis-flood-reflection-05 > > Hi Les, > > From: Lsr <[email protected]> on behalf of "Les Ginsberg (ginsberg)" > <[email protected]> > Date: Tuesday, December 7, 2021 at 1:17 PM > To: "Acee Lindem (acee)" <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" > -draft-ietf-lsr-isis-flood-reflection-05 > > 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. > > Given the discussions of these solutions over the last two years in LSR, I > don’t think we need to rehash this – especially on the experimental track. > > 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.) > > Are you saying you don’t want any experimental solutions unless we have one > standardized solution that everybody agrees on? Please review this one as > part of WG last call. > > Thanks, > Acee > > 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 14th , > 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
