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

[Christian Hopps <[e-mail]>]

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