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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Jan 2022 16:09:58 +0000

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

    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: Aijun Wang <[email-masked]>
Date: Tue, 11 Jan 2022 00:38:16 +0800

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Jan 2022 17:04:45 +0000

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

    Aijun Wang
    China Telecom

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 10 Jan 2022 20:35:42 +0100

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) <[email-masked]> 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
>
>     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
>
>     > 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
>     >
>     >    Have we captured these "different deployment and operational
> requirements" anywhere? I think might be very useful...
>     >
>     >    Thanks,
>     >    Chris.
>     >    [as wg member]
>     >
>     >
>     >> -- tony
>     >>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Jan 2022 16:16:40 +0000

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 <[email-masked]>
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, Christian Hopps <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:

    Aijun Wang
    China Telecom

    > On Jan 11, 2022, at 00:10, Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
    >
    > On 1/3/22, 7:05 AM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:
    >
    >
    >    Tony Przygienda <[email-masked]<mailto:[email-masked]>> writes:
    >
    >> [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]>
    > [email-masked]<mailto:[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 12 Jan 2022 17:52:36 +0100

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

> 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 <[email-masked]>
> *Date: *Monday, January 10, 2022 at 2:36 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Aijun Wang <[email-masked]>, Christian Hopps <
> [email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood
> Reflection"-draft-ietf-lsr-isis-flood-reflection-05
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 Jan 2022 17:03:30 +0000

Acee –

I have previously expressed my concerns about progressing multiple solutions simultaneously.
Ideally the work on the deployment draft would have started 2 years ago when the multiple solutions were first proposed.

But we are where we are – and I do appreciate the desires of people to deploy.

So I continue to wish we did not have to proceed to RFC state at this time  – but consider my objection as a “friendly” one.

   Les

From: Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, January 12, 2022 8:17 AM
To: Tony Przygienda <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Christian Hopps <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"-draft-ietf-lsr-isis-flood-reflection-05

Thanks,
Acee

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"-draft-ietf-lsr-isis-flood-reflection-05

thanks

-- tony

    Aijun Wang
    China Telecom

---

From: Christian Hopps <[email-masked]>
Date: Thu, 13 Jan 2022 06:21:19 -0500

Tony Przygienda <[email-masked]> 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 ... 
>

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.

>     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
>
>      
>
>     Cc: Aijun Wang <[email-masked]>, Christian Hopps <
>     [email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]
>     >, "[email-masked]" <[email-masked]>
>     Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood
>     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
>     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.
>
>      
>
>     considerations" or some such draft once those documents move up
>     to publication  so we have stable references to talk about ...
>
>      
>
>     thanks
>
>      
>
>     -- tony
>
>      
>
>         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" <[email-masked]
>         > 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=
>             >
>             > 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" <
>         [email-masked]> wrote:
>             >
>             >
>             >    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
>             >
>             >
>             > _______________________________________________
>             > Lsr mailing list
>             > [email-masked]
>             > https://www.ietf.org/mailman/listinfo/lsr
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 13 Jan 2022 15:05:49 +0000

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

    Thanks,
    Chris.

    >             > Speaking as a WG member, these documents are all
    >             >    Have we captured these "different deployment and

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 13 Jan 2022 15:07:35 +0000

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)" <[email-masked] on behalf of acee=[email-masked]> wrote:

    Hi Chris, 

    Thanks,
    Acee

        Thanks,
        Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 13 Jan 2022 19:01:38 +0000

All, 
I think there is some confusion here (at least on my part). My original message was to gauge how many of the WG members who supported work on deployment considerations for this IS-IS use case of using L1 as transit for L2 felt that this should precede advancement of the flooding reflection draft. It seems we really only had 1 or 2 WG members opposed to advancement. In the past, we haven't mandated deployment considerations prior to solution document advancement. I see now that Chris was actually agreeing with me in that we don't want to hold up advancement (my apologies). As I was conveying below, we have had multiple documents in the same space in the past and it hasn't prevented us from moving forward. Also, as I stated previously and others have agreed, the IS-IS flooding reflection draft takes a different approach than the IS-IS area proxy/TTZ drafts. 

Given this context, are there further comments? It seems Shraddha and I were the only ones providing detailed technical review (apologies if I missed anyone). 

Thanks,
Acee

    Hi Chris, 

    Thanks,
    Acee

        Thanks,
        Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 20 Jan 2022 20:34:12 +0000

All,
I've captured the objection on multiple solutions in the shepherd's report. We will move forward with this draft on the experimental track. 
Thanks,
Acee

On 1/13/22, 2:02 PM, "Acee Lindem (acee)" <acee=[email-masked]> wrote:

    All, 

    Thanks,
    Acee

        Hi Chris, 

        Thanks,
        Acee

            Thanks,
            Chris.