Subject: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

From: Christian Hopps <[email-masked]>
Date: Wed, 10 Jun 2020 15:28:58 -0400

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Chris and Acee.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Jun 2020 12:30:33 -0700

Christian, thanks much for that. As there were already two different
threads over last months where a good amount of people/companies expressed
their support for the draft to progress as WG item, I don't expect to need
to pester them again but maybe more will chime in here ...

thanks

-- tony

On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps <[email-masked]> wrote:

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: [email-masked]
Date: Wed, 10 Jun 2020 12:40:13 -0700

> Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

I am not a lawyer nor an author, but the area proxy IPR filing (https://datatracker.ietf.org/ipr/4016/ <https://datatracker.ietf.org/ipr/4016/>)  may also apply to this draft.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Jun 2020 12:56:41 -0700

JNPR holds relevant IPR on the draft. We are in the process of disclosing
it ASAP

thanks

-- tony

---

From: Melchior Aelmans <[email-masked]>
Date: Thu, 11 Jun 2020 18:06:46 +0200

Hi,

As stated previously I support adoption of this draft.

Cheers,
Melchior

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 11 Jun 2020 17:19:58 +0000

Supported previously and support now to adopt this draft as Experimental track.

On 6/10/20, 3:28 PM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

      https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK9G2SBpfU$

    Thanks,
    Chris and Acee.
    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!CQl3mcHX2A!Wvc4ZhBJ0lg7kMhLROfmvJ9oqsIFnxb7RxEonglDJO1hoOcohBd0gTK98dpWojk$

---

From: Christian Hopps <[email-masked]>
Date: Thu, 11 Jun 2020 14:07:53 -0400

As you are an author please provide the requested feedback on IPR.

Thanks,
Chris.

> On Jun 11, 2020, at 1:19 PM, Lee, Yiu <[email-masked]> wrote:
>

---

From: Jordan Head <[email-masked]>
Date: Thu, 11 Jun 2020 19:03:51 +0000

Support.

The draft identifies and addresses the problem, and quite cleanly I might add.

Jordan Head

On 6/10/20, 3:29 PM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    [External Email. Be cautious of content]

      https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdksRshic$

    Thanks,
    Chris and Acee.
    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdWR4R6q4$

Non-Juniper

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 12 Jun 2020 14:34:55 -0700

yes/support the adoption

Cheers,
Jeff

---

From: <[email-masked]>
Date: Sat, 13 Jun 2020 08:31:12 +0800 (CST)

Support the adoption.

Thanks,

Sandy

原始邮件

发件人：ChristianHopps <[email-masked]>
收件人：[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;Christian Hopps <[email-masked]>;
日 期 ：2020年06月11日 03:29
主 题 ：[Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

Thanks,
Chris and Acee.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 13 Jun 2020 03:22:20 +0000

Support the adoption of the draft.

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Melchior Aelmans
Sent: Thursday, June 11, 2020 12:07 PM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

Hi,

Cheers,
Melchior

On Wed, Jun 10, 2020 at 9:29 PM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!Wh2LAMEYdFSnXzfnXR0Nt24EUffnbytujVxpDh-zcAbWqwmFm2YCrrUcY-k9ZXfI$>

Thanks,
Chris and Acee.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Wh2LAMEYdFSnXzfnXR0Nt24EUffnbytujVxpDh-zcAbWqwmFm2YCrrUcY6_RqU7o$>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 13 Jun 2020 20:10:05 +0000

Speaking as WG  member: 

I support WG adoption of this draft on the experimental track. I think it is better for the WG to move forward and get some data points on these competing solutions than to be gridlocked. 

I'm not that concerned with the tunneling requirement for L1/L2 routers given that this can be accomplished very easily with segment routing (e.g., as in TI-LFA). 

One technical comment:

   If the client has a direct L2 adjacency with the flood reflector it SHOULD 
  use it instead of instantiating a new tunnel.

Perhaps this would be clearer:

    If the client has a direct L1 adjacency with the flood reflector it SHOULD
    not instantiate a tunnel for the L2 flooding reflector adjacency. 

Thanks,
Acee

On 6/10/20, 3:29 PM, "Christian Hopps" <[email-masked]> wrote:

    Thanks,
    Chris and Acee.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Jun 2020 00:52:29 -0400

I support this draft as experimental track.

Thanks

Gyan

On Sat, Jun 13, 2020 at 4:10 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Speaking as WG  member:
>
> I support WG adoption of this draft on the experimental track. I think it
> is better for the WG to move forward and get some data points on these
> competing solutions than to be gridlocked.
>
> I'm not that concerned with the tunneling requirement for L1/L2 routers
> given that this can be accomplished very easily with segment routing (e.g.,
> as in TI-LFA).
>
> One technical comment:
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jun 2020 13:17:11 -0700

support as co-author. not aware of any additional IPR beside the one
disclosed on the tracker already

thx

== t

---

From: John Scudder <[email-masked]>
Date: Fri, 19 Jun 2020 19:42:45 +0000

Hi All,

I just did a full read-through of -01. Without denigrating any other solutions, I support adoption of this one.

I do have a few comments and nits, below.

- Paragraph 2 of section 9 is unclear, IMO; I hope this can be improved in the next version. It reads exactly like a protocol expert writing for another protocol expert; as we know, a good spec has to be written so that as little as possible is left to the creativity of the implementor. This paragraph seems to require creativity.

- Please decide whether to do the right thing, and call the protocol “IS-IS”, or the wrong thing, and call it “ISIS”. Whatever the decision, standardize on that one instead of randomly adding and dropping hyphens.

- Section 8 mentions “route reflector clients”, probably what was meant was “flood reflector clients”.

Thanks,

—John

> On Jun 10, 2020, at 3:28 PM, Christian Hopps <[email-masked]> wrote:
> 
>  https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WwSo3XAAATjZjcHHk7EGQ6xt6K1-gAsQFmMVapPciPpj41XxzXiyLxQehiD8ew$
>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 19 Jun 2020 13:47:28 -0700

On Fri, Jun 19, 2020 at 12:43 PM John Scudder <jgs=
[email-masked]> wrote:

> Hi All,
>
> I just did a full read-through of -01. Without denigrating any other
> solutions, I support adoption of this one.
>
> - Paragraph 2 of section 9 is unclear, IMO; I hope this can be improved in
> the next version. It reads exactly like a protocol expert writing for
> another protocol expert; as we know, a good spec has to be written so that
> as little as possible is left to the creativity of the implementor. This
> paragraph seems to require creativity.
>

yepp, would benefit from an example. Nothing speaks against that.

>
> - Please decide whether to do the right thing, and call the protocol
> “IS-IS”, or the wrong thing, and call it “ISIS”. Whatever the decision,
> standardize on that one instead of randomly adding and dropping hyphens.
>

no opinion but Les will keep me honest ;-)

> was “flood reflector clients”.

oops ;-) Sincerest form of flattery ;-)

-- tony

---

From: Loa Andersson <[email-masked]>
Date: Sat, 20 Jun 2020 11:25:23 +0800

Working Group,

I support the adoption of this document.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          loa.pi.nu@gmail
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 21 Jun 2020 14:36:28 +0000

I support WG adoption of https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection .

(I also support the WG adoption of  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )

I believe the problem space addressed by these two drafts warrants attention.

I am not yet overly enthused about approaches which promote non-hierarchical network architectures. But it seems clear that there is interest in deploying non-hierarchical solutions and both drafts present solutions

which merit further evaluation.

The easy road for the WG to take would be to simply allow both drafts to proceed to Experimental RFCs, but I hope we are able to do more than this. Multiple solutions place undesirable burdens on vendors and providers alike.

To the extent they feel comfortable, I encourage folks who wish to deploy such solutions to share their requirements and discuss how each of the solutions

address their requirements/fall short of addressing their requirements. I think this would help the WG discover better ways forward.

   Les

> -----Original Message-----

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps

> Sent: Wednesday, June 10, 2020 12:29 PM

> To: [email-masked]

> Cc: [email-masked]; [email-masked]; Christian Hopps

> <[email-masked]>

> Subject: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

> Authors, please respond to the list indicating whether you are aware of any

> IPR that applies to this draft.

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 21 Jun 2020 08:19:03 -0700

thanks Les, albeit the authors got already lots of helpful comments from
you and Peter over beers in a bar I hope for further discussions.
Especially your opinion on

a) special case where FR is 1-hop away from the leafs should not need a
tunnel. I think most people would agree it's a good thing
b) some example/better text on the computation as John poked at
c) to give no favorite treatment to either data-tunnels or no-data-tunnels
shortcutting since both of those variants have its own camp of non-likers
;-) ; both shall be equally documented over time I think.
d) some people pine for FR hierarchy which would have the advantage of
being "future-proof" while I fear the rathole involved when looking @ my
RR-hierarchy-deployment-scar-tissues. Maybe we can cook something up that
buys us an option to add it in the future in backwards compatible fashion
without doing work now. I didn't think through the issue though.

Ultimately, and in the danger of sounding a bit like a broken record, your
view on hierarchy is IMO bitsy sideways. Customer would do like a generic,
summarizing, self-building, non-looping hierarchy (i.e. not forced to be
star-like) but as I think became obvious, only realistic distributed option
without connection setup and crank-back is unfortunately a rather rigidly
configured star without sideways transits (or high instability in hierarchy
if arbitrary edges are introduced and hierarchy is 'renegotiated'). And
it's not even protocol mechanics, it's fairly grounded in graph theory (if
you summarize, i.e. information flow is only partial). Another way to think
about it that Clos is actually nothing but such a
star-no-horizontal-transit networks (well, to an extent, this discussion
leads into ABR alternate behavior and shortcuts we lived and was "solved"
for 2 levels only as well) and hence automatically building hierarchy from
the defined center out is safe (just as RPL [which forces basically a CLOS
and would be possibly an option for ISIS but don't forget that RPL to work
needs arc-direction packet format change to prevent looping so that would
need looking at] or RIFT [which largely assumes CLOS with some variants so
is basically only good in discovering automatically a constraint it already
posed ;-) ]).  We may evolve over time to all networks topologies being
Banyan-variants exclusively (well, where locality is given, we already do)
but I consider that unlikely in generic WANs hence sprung the need for this
draft.

thanks

--- tony

On Sun, Jun 21, 2020 at 7:37 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> I support WG adoption of
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection ..
>
>
>
> (I also support the WG adoption of
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )
>
>
>
> I am not yet overly enthused about approaches which promote
> non-hierarchical network architectures. But it seems clear that there is
> interest in deploying non-hierarchical solutions and both drafts present
> solutions
>
> The easy road for the WG to take would be to simply allow both drafts to
> proceed to Experimental RFCs, but I hope we are able to do more than this.
> Multiple solutions place undesirable burdens on vendors and providers alike.
>
>
>
> To the extent they feel comfortable, I encourage folks who wish to deploy
> such solutions to share their requirements and discuss how each of the
> solutions
>
> address their requirements/fall short of addressing their requirements. I
> think this would help the WG discover better ways forward.
>
>
>
>    Les
>
>
>
>
>
> > https://www..ietf.org/mailman/listinfo/lsr
> <https://www.ietf.org/mailman/listinfo/lsr>

---

From: [email-masked]
Date: Sun, 21 Jun 2020 09:42:43 -0700

Hi Les,

> which merit further evaluation.

I think that there’s some confusion here. The point is very much to have a hierarchical design.  The key point is that the IGP hierarchy must not require a hierarchical data plane.  While a hierarchical data plane may suffice in a WAN topology, imposing that restriction on mega-scale multi-dimensional Clos fabrics simply doesn’t fly.  

We want the hierarchy provided by the IGP.  We need tools for extreme scaling. We need the IGP abstractions decoupled from the data plane architecture.

Looked at sideways, we’re simply trying to generalize the IS-IS area mechanism. We need transit areas that do not impact the scale of L2.

Apologies if I’m simply restating what Tony P. has already said.

Regards,
Tony

---

From: Chris Bowers <[email-masked]>
Date: Wed, 24 Jun 2020 11:58:12 -0500

I support WG adoption of draft-przygienda-lsr-flood-reflection.  The only
IPR that I am aware of that may be related to this draft has already been
disclosed.

Chris

---

From: Christian Hopps <[email-masked]>
Date: Mon, 29 Jun 2020 17:12:39 -0400

The work is adopted.

Authors, please resubmit with new name draft-ietf-lsr-flood-reflection and updating the track to experimental.

Thanks,
Chris.