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

[Tony Przygienda <[e-mail]>]

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 ...

-- tony

On Wed, Jan 12, 2022 at 5:16 PM Acee Lindem (acee) <[e-mail]> 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 <[e-mail]>
> *Date: *Monday, January 10, 2022 at 2:36 PM
> *To: *Acee Lindem <[e-mail]>
> *Cc: *Aijun Wang <[e-mail]>, Christian Hopps <
> [e-mail]>, "Les Ginsberg (ginsberg)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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) <[e-mail]> 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" <[e-mail]> 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=
> [e-mail]> 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" <[e-mail]> wrote:
>     >
>     >
>     >    Tony Przygienda <[e-mail]> 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=
>     >> [e-mail]> 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 <[e-mail]> On Behalf Of Acee Lindem (acee)
>     >>    Sent: Monday, November 22, 2021 11:47 AM
>     >>    To: [e-mail]
>     >>    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
>     >>    [e-mail]
>     >>    https://www.ietf.org/mailman/listinfo/lsr
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Lsr mailing list
>     >> [e-mail]
>     >> https://www.ietf.org/mailman/listinfo/lsr
>     >
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/lsr
>
>