Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

["Les Ginsberg (ginsberg)" <[e-mail]>]

+1
Hopefully this would help us understand the use cases better and why/if more than one solution might be appropriate.

Can’t happen too soon IMO. 😊

    Les

From: Jeff Tantsura <[e-mail]>
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda <[e-mail]>
Cc: Christian Hopps <[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>; lsr <[e-mail]>; Acee Lindem (acee) <[e-mail]>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

I’d very much support applicability draft work!
Cheers,
Jeff


On Jan 3, 2022, at 08:05, Tony Przygienda <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:

Tony Przygienda <[e-mail]<mailto:[e-mail]>> 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=
> [e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Acee Lindem (acee)
>     Sent: Monday, November 22, 2021 11:47 AM
>     To: [e-mail]<mailto:[e-mail]>
>     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
>     [e-mail]<mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/lsr
>
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr