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

[Christian Hopps <[e-mail]>]

Tony Przygienda <[e-mail]> 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) <[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
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr