+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 <jefftant.i...@gmail.com>
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda <tonysi...@gmail.com>
Cc: Christian Hopps <cho...@chopps.org>; Les Ginsberg (ginsberg)
<ginsb...@cisco.com>; lsr <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>
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
<tonysi...@gmail.com<mailto:tonysi...@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
<cho...@chopps.org<mailto:cho...@chopps.org>> wrote:
Tony Przygienda <tonysi...@gmail.com<mailto:tonysi...@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....@dmarc.ietf.org<mailto:40cisco....@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-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf
> Of Acee Lindem (acee)
> Sent: Monday, November 22, 2021 11:47 AM
> To: lsr@ietf.org<mailto: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<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
