Furthermore, I can't understand why there is so much reluctance to provide
technical review and comment on the draft.
Thanks,
Acee
On 1/13/22, 10:06 AM, "Lsr on behalf of Acee Lindem (acee)"
<lsr-boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
Hi Chris,
Actually, we have progressed multiple experimental OSPF MANET drafts. Two
of the them did have deployment but it is limited and there wasn't enough
interest to move any of them to standards track. There are elements of these
drafts in some of the flooding reduction proposals and it somewhat surprises me
that we haven't dusted them off.
As far as flooding reduction is concerned, we have one frame work that
supports any number of centralized or distributed algorithms. I'm certainly
glad we didn't relegate ourselves to a single mode or single algorithm.
In short, I don't think we should stop progression of experimental drafts
just because there are alternative proposals. IMO, the draft in question is a
technically different approach than the other two and is it is unlikely that we
are going to reach consensus on a single approach.
Thanks,
Acee
On 1/13/22, 6:39 AM, "Christian Hopps" <cho...@chopps.org> wrote:
Tony Przygienda <tonysi...@gmail.com> writes:
> I wonder whether this is now a general rule for all future ISIS
> drafts suggesting extensions or a one off random thing and we can
> come up for future drafts with arbitrary list of related drafts that
> we will precondition to gate publish/acceptance/whatever ...
>
> just trying to figure out what the process is here ...
Well since he was "Speaking as a document shepherd", it can't be a new
general rule, b/c document shepherds don't get to set general rules for a WG. :)
I sense some frustration here, though.
As a WG, we generally haven't advanced multiple solutions like we have
in this case. So, I don't think we can talk about any sort of previously
existing standard process. And with my WG chair hat on I'll say: I hope we
don't repeat this method very often in the future.
As WG Member: I didn't intend to pause forward progress when I
originally asked if any guidance had been captured to help users select between
the multiple options. It was just a natural thing to ask when you mentioned
that certain network designs lined up better with one solution or the other.
Thanks,
Chris.
>
> -- tony
>
> On Wed, Jan 12, 2022 at 5:16 PM Acee Lindem (acee) <a...@cisco.com>
> wrote:
>
>
> Speaking as document shepherd:
>
>
>
> Who thinks we should delay this draft while waiting for a
> deployment draft? I know some people supported this but I believe
> it would be better to move forward with this experimental draft.
> Given that there were 3 separate proposals for this topology to
> use level-1 as a transit for level-2. We’ve already established
> that there is a requirement.
>
>
>
> Also, I agree with Tony in that comments should be technical
> rather than simply that you don’t like it or you think it is
> complex.
>
>
>
> Thanks,
> Acee
>
>
>
> From: Tony Przygienda <tonysi...@gmail.com>
> Date: Monday, January 10, 2022 at 2:36 PM
> To: Acee Lindem <a...@cisco.com>
> Cc: Aijun Wang <wangai...@tsinghua.org.cn>, Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com
> >, "lsr@ietf.org" <lsr@ietf.org>
> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood
> Reflection"-draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> yes, first, if you abstract in _any_ way (except a full mesh for
> a single metric) you will end up with suboptimal paths (compared
> to global, flat topology view) traversing an abstracted subgraph
> and different ECMP behavior in corner cases, it's basic graph
> theory (aggravated by hop-by-hop or loose-source route forwarding
> planes) and is a well-known problem encountered in any
> hierarchical network, be it IGP, seamless MPLS or even BGP (look
> @ AIGP). FR deployed with underlying tunnels in L1 does not loop
> and neither does it when deployed correctly with prefix leaking.
>
>
>
> I cannot help it if a single person on this list is harboring
> fears, preferences and doubts without hard technical arguments to
> make for a meaningful discussion so I think it's time to put that
> repetitive sub-thread aside.
>
>
>
> As I said, I will be more than happy to help on a "deployment
> considerations" or some such draft once those documents move up
> to publication so we have stable references to talk about ...
>
>
>
> thanks
>
>
>
> -- tony
>
>
>
> On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee) <
> a...@cisco.com> wrote:
>
> I'll defer to Tony but my understanding is that there could
> be suboptimal paths if there are both Level-1 and Level-2
> paths but not loops.
> Thanks,
> Acee
>
> On 1/10/22, 11:38 AM, "Aijun Wang" <wangai...@tsinghua.org.cn
> > wrote:
>
> But there are unsolved issues for this draft—— BGP has
> loop prevention mechanism, current flood reflection draft
> hasn’t, the operator must design the topology/link metric
> carefully to avoid the possible loop.
>
> Aijun Wang
> China Telecom
>
> > On Jan 11, 2022, at 00:10, Acee Lindem (acee) <acee=
> 40cisco....@dmarc.ietf.org> wrote:
> >
> > Speaking as a WG member, these documents are all
> "experimental" and, IMO, it would really stifle innovation to
> require a single experimental solution. We've never done that
> in the past. Also, while all three solutions have the goal
> of reducing control plane overhead when using Level-1 areas
> as a transit, the flood reflection draft solves the problem
> with a different approach than the area proxy and TTZ
> drafts. While the latter two focus on abstracting the
> transit area, the former also focusing on reducing the number
> of adjacencies and allows the reflector to be out of the data
> path (similar to the standardized and widely deployed BGP
> route reflection) I see no need to differentiate to stall
> advancement.
> >
> > Thanks,
> > Acee
> >
> > On 1/3/22, 7:05 AM, "Christian Hopps" <
> cho...@chopps.org> wrote:
> >
> >
> > Tony Przygienda <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> 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> 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
_______________________________________________
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
