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

From: Christian Hopps <[email-masked]>
Date: Mon, 03 Jan 2022 07:02:45 -0500

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

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 3 Jan 2022 17:04:55 +0100

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 <[email-masked]> wrote:

> Have we captured these "different deployment and operational requirements"
> anywhere? I think might be very useful...
>
> Thanks,
> Chris.
> [as wg member]
>
>
> > -- tony
> >

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 3 Jan 2022 11:20:36 -0800

I’d very much support applicability draft work!

Cheers,
Jeff

> On Jan 3, 2022, at 08:05, Tony Przygienda <[email-masked]> 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 
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Jan 2022 19:55:01 -0500

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 <[email-masked]>
wrote:

>> Have we captured these "different deployment and operational
>> requirements" anywhere? I think might be very useful...
>>
>> Thanks,
>> Chris.
>> [as wg member]
>>
>>
>> > -- tony
>> >
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 15:34:50 +0000

+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 <[email-masked]>
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

On Jan 3, 2022, at 08:05, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

-- tony

On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Chris.
[as wg member]

> [email-masked]<mailto:[email-masked]>> wrote:
>
>
>     From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
>     To: [email-masked]<mailto:[email-masked]>
>     [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr