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

As Co-Author of Area proxy from an operators POV I would be supportive of
applicability draft work as a means to end end to progress both drafts.

Kind Regards

Gyan

On Mon, Jan 3, 2022 at 2:21 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> I’d very much support applicability draft work!
>
> Cheers,
> Jeff
>
> On Jan 3, 2022, at 08:05, Tony Przygienda <tonysietf@gmail.com> 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 <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
>>
>> _______________________________________________
> 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
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*