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

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 <chopps@chopps.org> wrote:

>
> Tony Przygienda <tonysietf@gmail.com> 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=
> > 40cisco.com@dmarc.ietf.org> 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 <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
> >     Sent: Monday, November 22, 2021 11:47 AM
> >     To: lsr@ietf.org
> >     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
> >     Lsr@ietf.org
> >     https://www.ietf.org/mailman/listinfo/lsr
> >
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
>