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

[Acee Lindem (acee)]

> From: Tony Przygienda 
> Date: Monday, January 10, 2022 at 2:36 PM
>     To: Acee Lindem 
        >     Cc: Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)" 
 >, "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" 
 > 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)  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  writes:
> >
> >> One thing Les is missing here is that proxy &
>  

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

[Acee Lindem (acee)]

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

On 1/13/22, 10:06 AM, "Lsr on behalf of Acee Lindem (acee)" 
 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"  wrote:


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

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

[Acee Lindem (acee)]

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)" 
 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"  wrote:


Tony Przygienda  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) 
> 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 
> Date: Monday, January 10, 2022 at 2:36 PM
        > To: Acee Lindem 
    > Cc: Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)"  >, "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 techn

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

[Acee Lindem (acee)]

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"  wrote:


Tony Przygienda  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) 
> 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 
> Date: Monday, January 10, 2022 at 2:36 PM
    > To: Acee Lindem 
    >     Cc: Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)"  >, "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
>
>  
>

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

[Christian Hopps]

Tony Przygienda  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) 
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 
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem 
Cc: Aijun Wang , Christian Hopps <
cho...@chopps.org>, "Les Ginsberg (ginsberg)" , "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"  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)  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
    >

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

[Les Ginsberg (ginsberg)]

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) 
Sent: Wednesday, January 12, 2022 8:17 AM
To: Tony Przygienda 
Cc: Aijun Wang ; Christian Hopps 
; Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood 
Reflection"-draft-ietf-lsr-isis-flood-reflection-05

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 mailto:tonysi...@gmail.com>>
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>, 
Christian Hopps mailto:cho...@chopps.org>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto: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) 
mailto: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" 
mailto: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) 
mailto: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" 
mailto:cho...@chopps.org>> wrote:
>
>
>Tony Przygienda mailto: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
>> deploy

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

[Tony Przygienda]

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)  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 
> *Date: *Monday, January 10, 2022 at 2:36 PM
> *To: *Acee Lindem 
> *Cc: *Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)" , "
> 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)  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"  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)  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"  wrote:
> >
> >
> >Tony Przygienda  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 ...
> >
&

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

[Acee Lindem (acee)]

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 
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem 
Cc: Aijun Wang , Christian Hopps 
, "Les Ginsberg (ginsberg)" , 
"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) 
mailto: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" 
mailto: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) 
mailto: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" 
mailto:cho...@chopps.org>> wrote:
>
>
>Tony Przygienda mailto: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) > 40cisco@dmarc.ietf.org<mailto: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-iet

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

[Tony Przygienda]

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

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

[Acee Lindem (acee)]

gt;> 
>> 
>> 
>>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  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

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

[Aijun Wang]

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

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

[Acee Lindem (acee)]

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

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

[Les Ginsberg (ginsberg)]

+1
Hopefully this would help us understand the use cases better and why/if more 
than one solution might be appropriate.

Can’t happen too soon IMO. 😊

Les

From: Jeff Tantsura 
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda 
Cc: Christian Hopps ; Les Ginsberg (ginsberg) 
; lsr ; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

I’d very much support applicability draft work!
Cheers,
Jeff


On Jan 3, 2022, at 08:05, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

AFAIS this is a "operational and deployment" or "applicability" draft and not 
part of a protocol specification. But yes, such a draft would have value AFAIS, 
especially if it deals with both abstract node & reflection in one as available 
 solutions. More than happy to attack that once the specs have moved to 
publication.

-- tony

On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Tony Przygienda mailto: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)  40cisco@dmarc.ietf.org<mailto: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

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

[Gyan Mishra]

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jeff Tantsura]

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

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

[Tony Przygienda]

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

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

[Christian Hopps]

Tony Przygienda  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)  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  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 

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

[Tony Przygienda]

inline. last email from my side in this thread.


On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang 
wrote:

> Hi, Tony:
>
> The advantage of IGP is that it can cure itself when there is any topology
> change, no additional  operator intervention involved.
>

neither is it in FR case. if you lose all FRs it's not different than
traversing L1 today by means of L1/L2 routers and losing all such routers.
if you have FRs you have all the IGP properties.


> But from your explanation below, there are situations that the draft
> doesn’t covered for the possible loop scenarios. Additional route compare
> rules or configuration requirements needed to be added when such thing
> happens. Then can we call the current solution is not final?
>

nothing needs be added except what the draft describes unless you have
real, concrete examples where the draft rules are not enough assuming a
correctly working implementation.


> And, if we lack one trust theory to avoid the loop, we will be stuck in
> the emerged loop situations.
>

I cannot control what you trust or don't trust based simply on an opinion
you harbor without concrete technical arguments or operational experience.
And unfortunately I am of a distinct "opinion" that whatever technical
explanation I gi8ve you will not change your "opinion" here anyway.


>
> let's be more precise beyond sensationalist headlines ... Though it's nice
> you found our documentation and based on that make first technical argument
> ;-)
>
> a) transitory loops during convergence/tunnel setup may exist, those also
> exist during normal ISIS convergence. Simple implementation techniques used
> in other contexts since many years exist like e.g. holding the router in
> overload until converged. That can be also easily implemented if e.g. a FR
> client has no FR tunnel established. A draft/spec is not an implementation
> description however so techniques deployed can be very different and
> starting to put that in will lead to overspecification.
>
>
> [WAJ] From the example that illustrated in the mentioned example, it seems
> the loop is not transient. It seems when R1 is not act as FR client, the
> loop will occur then?
>

sigh, now I start to explain documentation instead of you reading &
understanding the draft and that's not really the purpose of this list. The
condition can be only transitory or otherwise R1 is separate from R0 in L1
(if it is not then it will form the tunnel to FR via R0 [and there is also
a very weird case of R0 being in overload which however also works]). If
it's separated from R0 in L1 R0 will not see the leaked route and hence
cannot loop via leaked L2->L1. If you have an implementation that is a
client but will not form the FR tunnel persistently despite being L1
connected to FR while nevertheless leaking L2->L1 then it's simply a buggy
implementation and nothing can prevent anything from happening then.

I wish personally this doc section was never written or published BTW
though it was surely well-meant as "operational help".


>
> b) let's split the rest assuming full convergence scenario into tunnel;
> and no L1 tunnels case
> ib.) L1 tunnel case when all tunnels in place/converged is simple, it's
> identical really to any shortcut forwarding where the next hop is a tunnel,
> the packet just shows up magically @ the egress. this is AFAIS simpler
> option to understand and deploy correctly. If you harbor fears and doubts
> about the whole thing or looping potential, just use this.
>
>
> [WAJ] Then the merit that you compared with TTZ will go away?
>

 no, FR does NOT expose the L1 tunnel mesh if you have it in L2 contrary to
TTZ (which floods equivalent of a full tunnel mesh to the outside).
Actually the mesh does not even have to be flooded in L1 in flood
reflection case so ISIS is stable (but it can depending on e.g. liveliness
requirements and so on). I have to remark frankly, it seems to me your
grasp of even the most fundamental properties of the different
solutions/trade-offs in all those drafts is tenuous.


> b.ii) no tunnel case is more delicate (but hotly desired by many [arguably
> sophisticated] customers hence the work). If the SPF is implemented
> correctly no routing loops exist when converged.
>
> This preconditions  also correct leaking of L1 into L2 (hence the "all
> egress MUST be clients", it could work with a mix but the draft gets
> unnecessarily complex) and section 5.2 of the draft provides the necessary
> implementation on SPF to prevent loops in every case.
>
> [WAJ] As Acee pointe out also, this section is harder to understand and
> not in clear logic. I doubt and am unconvinced that it can cover every case.
>

this is a spec and not a story except the introduction section maybe. Specs
are written by defining rules. The section gives all the rules SPF needs to
implement for the solution to work correctly.


>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics s

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

[Tony Przygienda]

ever achieve the same "globally optimal" routing through
> the whole topology in L2 when abstracting some L1 things except when you
> advertise a full mesh of links reflecting all ingress-egress metrics in L2
> being basically L1 shortest path (or assume that all ingress/egress
> connections have infinite/same metric, it's called a chassis or more
> precisely a switching fabric then ;-). Beside scaling very poorly as the
> draft explains this can also cause a single link failing in L1 to cause a
> havoc of advertisements in L2 and if you are experienced in operational
> matters this is the last things you desire. In more abstract control theory
> terms you are building with such a solution a negatively stable system of
> control loops or in simpler terms an invisible big blast radius. Good for
> fighter planes, very bad for networking if you experienced those effects.
>
> hope that's enough details, none of this is BTW pure speculation but
> output of implemenation and extensive testing.
>
> --- tony
>
> On Sat, Dec 11, 2021 at 8:48 AM Aijun Wang 
> wrote:
>
>> Please refer to “Routing Loops” section that described in your company’s
>> documents:
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162
>>
>> This is just the simplest transit scenario. I am worrying for its further
>> applications.
>>
>> The overall routing path for L2 topologies that connected by several L1
>> is not determined by one L2 SPF algorithm, how can you assure no loop occur?
>>
>> Is it nightmare or mess for the operator to run its network in such
>> challenges situations?
>>
>> Aijun Wang
>> China Telecom
>>
>> On Dec 11, 2021, at 02:02, Tony Przygienda  wrote:
>>
>> 
>> What you describe is not technical reality when you're dealing with SPF
>> in L2 ... You seem to be deeply confused (but honestly, I have a hard time
>> to even figure out what kind of assumptions you're making about all kind of
>> things in all those threads about IGPs these days and on what but personal
>> preferences all those claims of "better" things are based) by the simple
>> fact that there is only a single connected L2 area ever in ISIS, if you
>> partition L2 you do not run ISIS within its viable envelope anymore, with
>> or without extensions. And L2 SPF will never loop and flood reflector draft
>> does not change the path taken in L2 so by first order logic you won't
>> loop. That is BTW one of the reasons why you will want to deploy multiple
>> flood reflectors per L1 (to not partition L2).
>>
>> As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2
>> could in ISIS from day one use L1 to "traverse across" (if you squint a bit
>> ;-)  in a sense and those drafts just improve the behavior so we are not
>> even architecturally changing the topological properties of the protocol
>> (whatever that means without delving deeply into graph theory definitions
>> ;-)
>>
>> -- tony
>>
>> On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Acee:
>>>
>>> No, I think the WG participations would like to enjoy the interested and
>>> correct direction topics.
>>> One technical considerations is the following: if IGP evolved into this
>>> direction, then the following connections loop diagram is also possible:
>>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
>>> Then, will we introduce the “AS number” to avoid loop, and various “Path
>>> Attributes” to influence the path selection within the IGP?
>>>
>>> There is a rush to adopt this draft, we should not rush again to
>>> accomplish its WG last call.
>>>
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Dec 9, 2021, at 10:07, Acee Lindem (acee) >> 40cisco@dmarc.ietf.org> wrote:
>>>
>>> 
>>>
>>> Hi Aijun,
>>>
>>>
>>>
>>> At least I’ve had several discussions with authors on the draft and
>>> you’ll note my comments on the list. The lack of further discussion on the
>>> list is a general problem in LSR. It seems many WG participants only want
>>> to discuss the draft that they have authored and it is hard to get comment
>>> without forcing the issue without an adoption or last call. I’m expecting
>>> at least one more review on the draft. Technical comments on the draft
>>> would be appreciated.
>>>
>>>
>>>
>>> Thanks,
>

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

[Aijun Wang]

avoc of advertisements in L2 and if you are experienced in operational 
> matters this is the last things you desire. In more abstract control theory 
> terms you are building with such a solution a negatively stable system of 
> control loops or in simpler terms an invisible big blast radius. Good for 
> fighter planes, very bad for networking if you experienced those effects. 
> 
> hope that's enough details, none of this is BTW pure speculation but output 
> of implemenation and extensive testing. 
> 
> --- tony 
> 
>> On Sat, Dec 11, 2021 at 8:48 AM Aijun Wang  wrote:
>> Please refer to “Routing Loops” section that described in your company’s 
>> documents:
>>   
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162
>> 
>> This is just the simplest transit scenario. I am worrying for its further 
>> applications. 
>> 
>> The overall routing path for L2 topologies that connected by several L1 is 
>> not determined by one L2 SPF algorithm, how can you assure no loop occur?
>> 
>> Is it nightmare or mess for the operator to run its network in such 
>> challenges situations?
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Dec 11, 2021, at 02:02, Tony Przygienda  wrote:
>>>> 
>>> 
>>> What you describe is not technical reality when you're dealing with SPF in 
>>> L2 ... You seem to be deeply confused (but honestly, I have a hard time to 
>>> even figure out what kind of assumptions you're making about all kind of 
>>> things in all those threads about IGPs these days and on what but personal 
>>> preferences all those claims of "better" things are based) by the simple 
>>> fact that there is only a single connected L2 area ever in ISIS, if you 
>>> partition L2 you do not run ISIS within its viable envelope anymore, with 
>>> or without extensions. And L2 SPF will never loop and flood reflector draft 
>>> does not change the path taken in L2 so by first order logic you won't 
>>> loop. That is BTW one of the reasons why you will want to deploy multiple 
>>> flood reflectors per L1 (to not partition L2). 
>>> 
>>> As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2 
>>> could in ISIS from day one use L1 to "traverse across" (if you squint a bit 
>>> ;-)  in a sense and those drafts just improve the behavior so we are not 
>>> even architecturally changing the topological properties of the protocol 
>>> (whatever that means without delving deeply into graph theory definitions 
>>> ;-) 
>>> 
>>> -- tony 
>>> 
>>>> On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang  
>>>> wrote:
>>>> Hi, Acee:
>>>> 
>>>> No, I think the WG participations would like to enjoy the interested and 
>>>> correct direction topics. 
>>>> One technical considerations is the following: if IGP evolved into this 
>>>> direction, then the following connections loop diagram is also possible:
>>>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
>>>> Then, will we introduce the “AS number” to avoid loop, and various “Path 
>>>> Attributes” to influence the path selection within the IGP?
>>>> 
>>>> There is a rush to adopt this draft, we should not rush again to 
>>>> accomplish its WG last call.
>>>> 
>>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>> 
>>>>>> On Dec 9, 2021, at 10:07, Acee Lindem (acee) 
>>>>>>  wrote:
>>>>>> 
>>>>> 
>>>>> Hi Aijun,
>>>>> 
>>>>>  
>>>>> 
>>>>> At least I’ve had several discussions with authors on the draft and 
>>>>> you’ll note my comments on the list. The lack of further discussion on 
>>>>> the list is a general problem in LSR. It seems many WG participants only 
>>>>> want to discuss the draft that they have authored and it is hard to get 
>>>>> comment without forcing the issue without an adoption or last call. I’m 
>>>>> expecting at least one more review on the draft. Technical comments on 
>>>>> the draft would be appreciated.
>>>>> 
>>>>>  
>>>>> 
>>>>> Thanks,
>>>>> Acee
>>>>> 
>>>>>  
>>>>> 
>>>>> From: Aijun Wang 
>>>>> Date: Wednesday

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

[Tony Przygienda]

 by the simple
> fact that there is only a single connected L2 area ever in ISIS, if you
> partition L2 you do not run ISIS within its viable envelope anymore, with
> or without extensions. And L2 SPF will never loop and flood reflector draft
> does not change the path taken in L2 so by first order logic you won't
> loop. That is BTW one of the reasons why you will want to deploy multiple
> flood reflectors per L1 (to not partition L2).
>
> As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2
> could in ISIS from day one use L1 to "traverse across" (if you squint a bit
> ;-)  in a sense and those drafts just improve the behavior so we are not
> even architecturally changing the topological properties of the protocol
> (whatever that means without delving deeply into graph theory definitions
> ;-)
>
> -- tony
>
> On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang 
> wrote:
>
>> Hi, Acee:
>>
>> No, I think the WG participations would like to enjoy the interested and
>> correct direction topics.
>> One technical considerations is the following: if IGP evolved into this
>> direction, then the following connections loop diagram is also possible:
>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
>> Then, will we introduce the “AS number” to avoid loop, and various “Path
>> Attributes” to influence the path selection within the IGP?
>>
>> There is a rush to adopt this draft, we should not rush again to
>> accomplish its WG last call.
>>
>>
>> Aijun Wang
>> China Telecom
>>
>> On Dec 9, 2021, at 10:07, Acee Lindem (acee) > 40cisco@dmarc.ietf.org> wrote:
>>
>> 
>>
>> Hi Aijun,
>>
>>
>>
>> At least I’ve had several discussions with authors on the draft and
>> you’ll note my comments on the list. The lack of further discussion on the
>> list is a general problem in LSR. It seems many WG participants only want
>> to discuss the draft that they have authored and it is hard to get comment
>> without forcing the issue without an adoption or last call. I’m expecting
>> at least one more review on the draft. Technical comments on the draft
>> would be appreciated.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>> *From: *Aijun Wang 
>> *Date: *Wednesday, December 8, 2021 at 11:15 AM
>> *To: *Acee Lindem 
>> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
>> lsr@ietf.org>
>> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
>> -draft-ietf-lsr-isis-flood-reflection-05
>>
>>
>>
>> Hi, Acee:
>>
>>
>>
>> I found there is no any technical discussion on the list for the
>> mentioned draft after its adoption(from 2020-7-6), even before its adoption.
>>
>> There is only one presentation for its update at the IETF 111 meeting(1
>> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call
>> is issued.
>>
>>
>>
>> From the authors’ statement, there is only the author’s affiliation
>> implemented it, no interoperability problems can be found.
>>
>>
>>
>> From the discussion in these days, it is doubtful for IGP to evolve into
>> this direction as behaved by BGP.
>>
>>
>>
>> From the POV of the operator, we will not consider such strange design to
>> scale the IS-IS.
>>
>>
>>
>> From the documents itself, there are unsolved problems (for example in
>> section 7) which can only be solved by “sending alarm and declare
>> misconfiguration).
>>
>>
>>
>> Then, why it is ready to WG Last Call?
>>
>>
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> On Dec 8, 2021, at 06:28, Acee Lindem (acee) > 40cisco@dmarc.ietf.org> wrote:
>>
>> Hi Les,
>>
>>
>>
>> *From: *"Les Ginsberg (ginsberg)" 
>> *Date: *Tuesday, December 7, 2021 at 5:10 PM
>> *To: *"Acee Lindem (acee)" , Acee
>> Lindem , "lsr@ietf.org" 
>> *Subject: *RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
>> -draft-ietf-lsr-isis-flood-reflection-05
>>
>>
>>
>> Let me try to respond to Acee/Tony/Tony in one email.
>>
>>
>>
>> Acee – I don’t like any of the proposals. I believe they are all abusing
>> the protocols to some degree.
>>
>>
>>
>> That’s fine if you have technical concerns with the individual drafts.
>> The problem space discussion is a moot point s

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

[Aijun Wang]

Please refer to “Routing Loops” section that described in your company’s 
documents:
  
https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-isis-flood-reflectors.html#jd0e162

This is just the simplest transit scenario. I am worrying for its further 
applications. 

The overall routing path for L2 topologies that connected by several L1 is not 
determined by one L2 SPF algorithm, how can you assure no loop occur?

Is it nightmare or mess for the operator to run its network in such challenges 
situations?

Aijun Wang
China Telecom

> On Dec 11, 2021, at 02:02, Tony Przygienda  wrote:
> 
> 
> What you describe is not technical reality when you're dealing with SPF in L2 
> ... You seem to be deeply confused (but honestly, I have a hard time to even 
> figure out what kind of assumptions you're making about all kind of things in 
> all those threads about IGPs these days and on what but personal preferences 
> all those claims of "better" things are based) by the simple fact that there 
> is only a single connected L2 area ever in ISIS, if you partition L2 you do 
> not run ISIS within its viable envelope anymore, with or without extensions. 
> And L2 SPF will never loop and flood reflector draft does not change the path 
> taken in L2 so by first order logic you won't loop. That is BTW one of the 
> reasons why you will want to deploy multiple flood reflectors per L1 (to not 
> partition L2). 
> 
> As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2 
> could in ISIS from day one use L1 to "traverse across" (if you squint a bit 
> ;-)  in a sense and those drafts just improve the behavior so we are not even 
> architecturally changing the topological properties of the protocol (whatever 
> that means without delving deeply into graph theory definitions ;-) 
> 
> -- tony 
> 
>> On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang  wrote:
>> Hi, Acee:
>> 
>> No, I think the WG participations would like to enjoy the interested and 
>> correct direction topics. 
>> One technical considerations is the following: if IGP evolved into this 
>> direction, then the following connections loop diagram is also possible:
>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
>> Then, will we introduce the “AS number” to avoid loop, and various “Path 
>> Attributes” to influence the path selection within the IGP?
>> 
>> There is a rush to adopt this draft, we should not rush again to accomplish 
>> its WG last call.
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Dec 9, 2021, at 10:07, Acee Lindem (acee) 
>>>>  wrote:
>>>> 
>>> 
>>> Hi Aijun,
>>> 
>>>  
>>> 
>>> At least I’ve had several discussions with authors on the draft and you’ll 
>>> note my comments on the list. The lack of further discussion on the list is 
>>> a general problem in LSR. It seems many WG participants only want to 
>>> discuss the draft that they have authored and it is hard to get comment 
>>> without forcing the issue without an adoption or last call. I’m expecting 
>>> at least one more review on the draft. Technical comments on the draft 
>>> would be appreciated.
>>> 
>>>  
>>> 
>>> Thanks,
>>> Acee
>>> 
>>>  
>>> 
>>> From: Aijun Wang 
>>> Date: Wednesday, December 8, 2021 at 11:15 AM
>>> To: Acee Lindem 
>>> Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 
>>> 
>>> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
>>> -draft-ietf-lsr-isis-flood-reflection-05
>>> 
>>>  
>>> 
>>> Hi, Acee:
>>> 
>>>  
>>> 
>>> I found there is no any technical discussion on the list for the mentioned 
>>> draft after its adoption(from 2020-7-6), even before its adoption.
>>> 
>>> There is only one presentation for its update at the IETF 111 meeting(1 
>>> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call 
>>> is issued.
>>> 
>>>  
>>> 
>>> From the authors’ statement, there is only the author’s affiliation 
>>> implemented it, no interoperability problems can be found.
>>> 
>>>  
>>> 
>>> From the discussion in these days, it is doubtful for IGP to evolve into 
>>> this direction as behaved by BGP.
>>> 
>>>  
>>> 
>>> From the POV of the operator, we will not consider such strange design to 
>>> scale the IS-IS.
>>> 
>>

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

[Tony Przygienda]

What you describe is not technical reality when you're dealing with SPF in
L2 ... You seem to be deeply confused (but honestly, I have a hard time to
even figure out what kind of assumptions you're making about all kind of
things in all those threads about IGPs these days and on what but personal
preferences all those claims of "better" things are based) by the simple
fact that there is only a single connected L2 area ever in ISIS, if you
partition L2 you do not run ISIS within its viable envelope anymore, with
or without extensions. And L2 SPF will never loop and flood reflector draft
does not change the path taken in L2 so by first order logic you won't
loop. That is BTW one of the reasons why you will want to deploy multiple
flood reflectors per L1 (to not partition L2).

As Acee pointed out, unlike OSPF (discounting alternate ABR behavior) L2
could in ISIS from day one use L1 to "traverse across" (if you squint a bit
;-)  in a sense and those drafts just improve the behavior so we are not
even architecturally changing the topological properties of the protocol
(whatever that means without delving deeply into graph theory definitions
;-)

-- tony

On Fri, Dec 10, 2021 at 1:40 AM Aijun Wang 
wrote:

> Hi, Acee:
>
> No, I think the WG participations would like to enjoy the interested and
> correct direction topics.
> One technical considerations is the following: if IGP evolved into this
> direction, then the following connections loop diagram is also possible:
> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
> Then, will we introduce the “AS number” to avoid loop, and various “Path
> Attributes” to influence the path selection within the IGP?
>
> There is a rush to adopt this draft, we should not rush again to
> accomplish its WG last call.
>
>
> Aijun Wang
> China Telecom
>
> On Dec 9, 2021, at 10:07, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Hi Aijun,
>
>
>
> At least I’ve had several discussions with authors on the draft and you’ll
> note my comments on the list. The lack of further discussion on the list is
> a general problem in LSR. It seems many WG participants only want to
> discuss the draft that they have authored and it is hard to get comment
> without forcing the issue without an adoption or last call. I’m expecting
> at least one more review on the draft. Technical comments on the draft
> would be appreciated.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Aijun Wang 
> *Date: *Wednesday, December 8, 2021 at 11:15 AM
> *To: *Acee Lindem 
> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> Hi, Acee:
>
>
>
> I found there is no any technical discussion on the list for the mentioned
> draft after its adoption(from 2020-7-6), even before its adoption.
>
> There is only one presentation for its update at the IETF 111 meeting(1
> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call
> is issued.
>
>
>
> From the authors’ statement, there is only the author’s affiliation
> implemented it, no interoperability problems can be found.
>
>
>
> From the discussion in these days, it is doubtful for IGP to evolve into
> this direction as behaved by BGP.
>
>
>
> From the POV of the operator, we will not consider such strange design to
> scale the IS-IS.
>
>
>
> From the documents itself, there are unsolved problems (for example in
> section 7) which can only be solved by “sending alarm and declare
> misconfiguration).
>
>
>
> Then, why it is ready to WG Last Call?
>
>
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Dec 8, 2021, at 06:28, Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Hi Les,
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Tuesday, December 7, 2021 at 5:10 PM
> *To: *"Acee Lindem (acee)" , Acee Lindem
> , "lsr@ietf.org" 
> *Subject: *RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> Let me try to respond to Acee/Tony/Tony in one email.
>
>
>
> Acee – I don’t like any of the proposals. I believe they are all abusing
> the protocols to some degree.
>
>
>
> That’s fine if you have technical concerns with the individual drafts. The
> problem space discussion is a moot point since the WG has already adopted
> these documents.
>
>
>
> Thanks,
>
> Acee
>
>
>
> I fully believe that the authors are clever enough to figure out how to
> make this work – but

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

[Aijun Wang]

Hi, Tony:

I am referring to the “flood reflection” solution.
I think “area proxy” is one better solution if we want actually the L1 zone to 
be the transited by L2 zone.

Aijun Wang
China Telecom

> On Dec 10, 2021, at 13:13, Tony Li  wrote:
> 
> 
> 
> Hi Aijun,
> 
>> No, I think the WG participations would like to enjoy the interested and 
>> correct direction topics. 
>> One technical considerations is the following: if IGP evolved into this 
>> direction, then the following connections loop diagram is also possible:
>> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
>> Then, will we introduce the “AS number” to avoid loop, and various “Path 
>> Attributes” to influence the path selection within the IGP?
> 
> 
> I think you misunderstand how Area Proxy works.
> 
> In fact, the L1 area actually is running L1L2, so there is no need for 
> additional loop detection mechanisms.  Within the L2 LSDB, the area’s topology
> is simply abstracted away and only the interconnections with L2 systems are 
> visible. The area effectively looks like a single node.
> 
> Tony
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

Hi Aijun,

> No, I think the WG participations would like to enjoy the interested and 
> correct direction topics. 
> One technical considerations is the following: if IGP evolved into this 
> direction, then the following connections loop diagram is also possible:
> L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
> Then, will we introduce the “AS number” to avoid loop, and various “Path 
> Attributes” to influence the path selection within the IGP?


I think you misunderstand how Area Proxy works.

In fact, the L1 area actually is running L1L2, so there is no need for 
additional loop detection mechanisms.  Within the L2 LSDB, the area’s topology
is simply abstracted away and only the interconnections with L2 systems are 
visible. The area effectively looks like a single node.

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Acee:

No, I think the WG participations would like to enjoy the interested and 
correct direction topics. 
One technical considerations is the following: if IGP evolved into this 
direction, then the following connections loop diagram is also possible:
L2-L1-L2-L1-L2-L1-…..-L2(back to the origin)
Then, will we introduce the “AS number” to avoid loop, and various “Path 
Attributes” to influence the path selection within the IGP?

There is a rush to adopt this draft, we should not rush again to accomplish its 
WG last call.


Aijun Wang
China Telecom

> On Dec 9, 2021, at 10:07, Acee Lindem (acee) 
>  wrote:
> 
> 
> Hi Aijun,
>  
> At least I’ve had several discussions with authors on the draft and you’ll 
> note my comments on the list. The lack of further discussion on the list is a 
> general problem in LSR. It seems many WG participants only want to discuss 
> the draft that they have authored and it is hard to get comment without 
> forcing the issue without an adoption or last call. I’m expecting at least 
> one more review on the draft. Technical comments on the draft would be 
> appreciated.
>  
> Thanks,
> Acee
>  
> From: Aijun Wang 
> Date: Wednesday, December 8, 2021 at 11:15 AM
> To: Acee Lindem 
> Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 
> 
> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
> -draft-ietf-lsr-isis-flood-reflection-05
>  
> Hi, Acee:
>  
> I found there is no any technical discussion on the list for the mentioned 
> draft after its adoption(from 2020-7-6), even before its adoption.
> There is only one presentation for its update at the IETF 111 meeting(1 
> pages, 5 minutes) and after it’s presentation at IETF 112, the WG Last Call 
> is issued.
>  
> From the authors’ statement, there is only the author’s affiliation 
> implemented it, no interoperability problems can be found.
>  
> From the discussion in these days, it is doubtful for IGP to evolve into this 
> direction as behaved by BGP.
>  
> From the POV of the operator, we will not consider such strange design to 
> scale the IS-IS.
>  
> From the documents itself, there are unsolved problems (for example in 
> section 7) which can only be solved by “sending alarm and declare 
> misconfiguration).
>  
> Then, why it is ready to WG Last Call? 
>  
>  
> Aijun Wang
> China Telecom
> 
> 
> On Dec 8, 2021, at 06:28, Acee Lindem (acee) 
>  wrote:
> 
> Hi Les,
>  
> From: "Les Ginsberg (ginsberg)" 
> Date: Tuesday, December 7, 2021 at 5:10 PM
> To: "Acee Lindem (acee)" , Acee Lindem 
> , "lsr@ietf.org" 
> Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
> -draft-ietf-lsr-isis-flood-reflection-05
>  
> Let me try to respond to Acee/Tony/Tony in one email.
>  
> Acee – I don’t like any of the proposals. I believe they are all abusing the 
> protocols to some degree.
>  
> That’s fine if you have technical concerns with the individual drafts. The 
> problem space discussion is a moot point since the WG has already adopted 
> these documents.
>  
> Thanks,
> Acee
>  
> I fully believe that the authors are clever enough to figure out how to make 
> this work – but that doesn’t mean any of them are desirable.
> So if I have to “vote” – I vote “no”.
>  
> Tony Li –
>  
> Area Proxy Introduction says in part:
>  
> “Following the current rules of IS-IS, all spine routers would
>necessarily be part of the Level 2 topology, plus all links between a
>Level 2 leaf and the spines.  In the limit, where all leaves need to
>support Level 2, it implies that the entire L3LS topology becomes
>part of Level 2.  This is seriously problematic as it more than
>doubles the LSDB held in the L3LS topology and eliminates any
>benefits of the hierarchy.”
>  
> Flood Reflection says:
>  
> “In such scenarios, an
>alternative approach is to consider multiple L2 flooding domains
>connected together via L1 flooding domains.  In other words, L2
>flooding domains are connected by "L1/L2 lanes" through the L1 areas
>to form a single L2 backbone again.  Unfortunately, in its simplest
>implementation, this requires the inclusion of most, or all, of the
>transit L1 routers as L1/L2 to allow traffic to flow along optimal
>paths through such transit areas.  Consequently, this approach fails
>to reduce the number of L2 routers involved, so it fails to increase
>the scalability of the L2 backbone.”
>  
>  
> These problem statements seem fundamentally similar to me.
>  
> No question the two drafts define very different solutions – but the problem 
> statements 

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

[Acee Lindem (acee)]

Hi Aijun,

At least I’ve had several discussions with authors on the draft and you’ll note 
my comments on the list. The lack of further discussion on the list is a 
general problem in LSR. It seems many WG participants only want to discuss the 
draft that they have authored and it is hard to get comment without forcing the 
issue without an adoption or last call. I’m expecting at least one more review 
on the draft. Technical comments on the draft would be appreciated.

Thanks,
Acee

From: Aijun Wang 
Date: Wednesday, December 8, 2021 at 11:15 AM
To: Acee Lindem 
Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 

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

Hi, Acee:

I found there is no any technical discussion on the list for the mentioned 
draft after its adoption(from 2020-7-6), even before its adoption.
There is only one presentation for its update at the IETF 111 meeting(1 pages, 
5 minutes) and after it’s presentation at IETF 112, the WG Last Call is issued.

From the authors’ statement, there is only the author’s affiliation implemented 
it, no interoperability problems can be found.

From the discussion in these days, it is doubtful for IGP to evolve into this 
direction as behaved by BGP.

From the POV of the operator, we will not consider such strange design to scale 
the IS-IS.

From the documents itself, there are unsolved problems (for example in section 
7) which can only be solved by “sending alarm and declare misconfiguration).

Then, why it is ready to WG Last Call?


Aijun Wang
China Telecom


On Dec 8, 2021, at 06:28, Acee Lindem (acee)  
wrote:
Hi Les,

From: "Les Ginsberg (ginsberg)" 
Date: Tuesday, December 7, 2021 at 5:10 PM
To: "Acee Lindem (acee)" , Acee Lindem 
, "lsr@ietf.org" 
Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

Let me try to respond to Acee/Tony/Tony in one email.

Acee – I don’t like any of the proposals. I believe they are all abusing the 
protocols to some degree.

That’s fine if you have technical concerns with the individual drafts. The 
problem space discussion is a moot point since the WG has already adopted these 
documents.

Thanks,
Acee

I fully believe that the authors are clever enough to figure out how to make 
this work – but that doesn’t mean any of them are desirable.
So if I have to “vote” – I vote “no”.

Tony Li –

Area Proxy Introduction says in part:

“Following the current rules of IS-IS, all spine routers would
   necessarily be part of the Level 2 topology, plus all links between a
   Level 2 leaf and the spines.  In the limit, where all leaves need to
   support Level 2, it implies that the entire L3LS topology becomes
   part of Level 2.  This is seriously problematic as it more than
   doubles the LSDB held in the L3LS topology and eliminates any
   benefits of the hierarchy.”

Flood Reflection says:

“In such scenarios, an
   alternative approach is to consider multiple L2 flooding domains
   connected together via L1 flooding domains.  In other words, L2
   flooding domains are connected by "L1/L2 lanes" through the L1 areas
   to form a single L2 backbone again.  Unfortunately, in its simplest
   implementation, this requires the inclusion of most, or all, of the
   transit L1 routers as L1/L2 to allow traffic to flow along optimal
   paths through such transit areas.  Consequently, this approach fails
   to reduce the number of L2 routers involved, so it fails to increase
   the scalability of the L2 backbone.”


These problem statements seem fundamentally similar to me.

No question the two drafts define very different solutions – but the problem 
statements seem quite similar to me.

Tony P – I would argue that a “20K perspective” is useful when deciding whether 
the overall approach is a good one.

And in response to Tony Li’s statement:  “…the IETF is at its best when it is 
documenting de facto standards”

1) I fully believe that our customers understand their requirements(sic) better 
than we (vendors) do. But that does not mean that they understand what is the 
best solution better than we do.
When a customer comes to me and says “Can you do this?” my first response is 
usually “Please fully describe your requirements independent of the solution.”

2)Not clear to me that there is an existing “de facto standard” here – which is 
reinforced by the fact that we have so many different solutions proposed.

   Les



From: Acee Lindem (acee) 
Sent: Tuesday, December 7, 2021 10:31 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

Hi Les,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Tuesday, December 7, 2021 a

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

[Aijun Wang]

Hi, Acee:

I found there is no any technical discussion on the list for the mentioned 
draft after its adoption(from 2020-7-6), even before its adoption.
There is only one presentation for its update at the IETF 111 meeting(1 pages, 
5 minutes) and after it’s presentation at IETF 112, the WG Last Call is issued.

From the authors’ statement, there is only the author’s affiliation implemented 
it, no interoperability problems can be found.

From the discussion in these days, it is doubtful for IGP to evolve into this 
direction as behaved by BGP.

From the POV of the operator, we will not consider such strange design to scale 
the IS-IS.

From the documents itself, there are unsolved problems (for example in section 
7) which can only be solved by “sending alarm and declare misconfiguration).

Then, why it is ready to WG Last Call? 


Aijun Wang
China Telecom

> On Dec 8, 2021, at 06:28, Acee Lindem (acee) 
>  wrote:
> 
> Hi Les,
>  
> From: "Les Ginsberg (ginsberg)" 
> Date: Tuesday, December 7, 2021 at 5:10 PM
> To: "Acee Lindem (acee)" , Acee Lindem 
> , "lsr@ietf.org" 
> Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
> -draft-ietf-lsr-isis-flood-reflection-05
>  
> Let me try to respond to Acee/Tony/Tony in one email.
>  
> Acee – I don’t like any of the proposals. I believe they are all abusing the 
> protocols to some degree.
>  
> That’s fine if you have technical concerns with the individual drafts. The 
> problem space discussion is a moot point since the WG has already adopted 
> these documents.
>  
> Thanks,
> Acee
>  
> I fully believe that the authors are clever enough to figure out how to make 
> this work – but that doesn’t mean any of them are desirable.
> So if I have to “vote” – I vote “no”.
>  
> Tony Li –
>  
> Area Proxy Introduction says in part:
>  
> “Following the current rules of IS-IS, all spine routers would
>necessarily be part of the Level 2 topology, plus all links between a
>Level 2 leaf and the spines.  In the limit, where all leaves need to
>support Level 2, it implies that the entire L3LS topology becomes
>part of Level 2.  This is seriously problematic as it more than
>doubles the LSDB held in the L3LS topology and eliminates any
>benefits of the hierarchy.”
>  
> Flood Reflection says:
>  
> “In such scenarios, an
>alternative approach is to consider multiple L2 flooding domains
>connected together via L1 flooding domains.  In other words, L2
>flooding domains are connected by "L1/L2 lanes" through the L1 areas
>to form a single L2 backbone again.  Unfortunately, in its simplest
>implementation, this requires the inclusion of most, or all, of the
>transit L1 routers as L1/L2 to allow traffic to flow along optimal
>paths through such transit areas.  Consequently, this approach fails
>to reduce the number of L2 routers involved, so it fails to increase
>the scalability of the L2 backbone.”
>  
>  
> These problem statements seem fundamentally similar to me.
>  
> No question the two drafts define very different solutions – but the problem 
> statements seem quite similar to me.
>  
> Tony P – I would argue that a “20K perspective” is useful when deciding 
> whether the overall approach is a good one.
>  
> And in response to Tony Li’s statement:  “…the IETF is at its best when it is 
> documenting de facto standards”
>  
> 1) I fully believe that our customers understand their requirements(sic) 
> better than we (vendors) do. But that does not mean that they understand what 
> is the best solution better than we do.
> When a customer comes to me and says “Can you do this?” my first response is 
> usually “Please fully describe your requirements independent of the solution.”
>  
> 2)Not clear to me that there is an existing “de facto standard” here – which 
> is reinforced by the fact that we have so many different solutions proposed.
>  
>Les
>  
>  
>  
> From: Acee Lindem (acee)  
> Sent: Tuesday, December 7, 2021 10:31 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
> ; lsr@ietf.org
> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
> -draft-ietf-lsr-isis-flood-reflection-05
>  
> Hi Les,
>  
> From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 
> 
> Date: Tuesday, December 7, 2021 at 1:17 PM
> To: "Acee Lindem (acee)" , "lsr@ietf.org" 
> 
> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
> -draft-ietf-lsr-isis-flood-reflection-05
>  
> 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 
&

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

[Tony Przygienda]

On Tue, Dec 7, 2021 at 11:53 PM Tony Li  wrote:

>
> Les,
>


Les,


> And in response to Tony Li’s statement:  “…the IETF is at its best when it
> is documenting de facto standards”
>
> 1) I fully believe that our customers understand their requirements(sic)
> better than we (vendors) do. But that does not mean that they understand
> what is the best solution better than we do.
> When a customer comes to me and says “Can you do this?” my first response
> is usually “Please fully describe your requirements independent of the
> solution.”
>
>
>
> If it matters at all, Area Proxy is the result of a customer explaining
> his issues and my attempt to address them.  I’m sorry you don’t like my
> proposal.
>
>

which funny enough is precisely what happened in case of flood reflection
as well ;-) Given that customers are different, their networks tend to be
different, timelines, deployed sets of technologies and ultimately scar
tissue and resulting preferences for better or for worse are different, you
end up sometimes with different solutions based on different equirements
for "roughly" similar problem if want to ship the stuff, run it and move
the world on in a teimely and cost-effective manner.

As Acee said, not the time now to think whether IGP should address this
problem space (that was draft acceptance timeframe), now the question is
how to make sure all possible technical holes are closed & best possible
drafts with an eye on future extensibility and an eye on making sure we
have something backwards compatible is asked for I'd say ...

-- tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

Les,

> And in response to Tony Li’s statement:  “…the IETF is at its best when it is 
> documenting de facto standards”
>  
> 1) I fully believe that our customers understand their requirements(sic) 
> better than we (vendors) do. But that does not mean that they understand what 
> is the best solution better than we do.
> When a customer comes to me and says “Can you do this?” my first response is 
> usually “Please fully describe your requirements independent of the solution.”


If it matters at all, Area Proxy is the result of a customer explaining his 
issues and my attempt to address them.  I’m sorry you don’t like my proposal.

 
> 2)Not clear to me that there is an existing “de facto standard” here – which 
> is reinforced by the fact that we have so many different solutions proposed.


There isn’t. Yet. Thus, it’s not time to pick one vs. the other.

Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Les,

From: "Les Ginsberg (ginsberg)" 
Date: Tuesday, December 7, 2021 at 5:10 PM
To: "Acee Lindem (acee)" , Acee Lindem 
, "lsr@ietf.org" 
Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

Let me try to respond to Acee/Tony/Tony in one email.

Acee – I don’t like any of the proposals. I believe they are all abusing the 
protocols to some degree.

That’s fine if you have technical concerns with the individual drafts. The 
problem space discussion is a moot point since the WG has already adopted these 
documents.

Thanks,
Acee

I fully believe that the authors are clever enough to figure out how to make 
this work – but that doesn’t mean any of them are desirable.
So if I have to “vote” – I vote “no”.

Tony Li –

Area Proxy Introduction says in part:

“Following the current rules of IS-IS, all spine routers would
   necessarily be part of the Level 2 topology, plus all links between a
   Level 2 leaf and the spines.  In the limit, where all leaves need to
   support Level 2, it implies that the entire L3LS topology becomes
   part of Level 2.  This is seriously problematic as it more than
   doubles the LSDB held in the L3LS topology and eliminates any
   benefits of the hierarchy.”

Flood Reflection says:

“In such scenarios, an
   alternative approach is to consider multiple L2 flooding domains
   connected together via L1 flooding domains.  In other words, L2
   flooding domains are connected by "L1/L2 lanes" through the L1 areas
   to form a single L2 backbone again.  Unfortunately, in its simplest
   implementation, this requires the inclusion of most, or all, of the
   transit L1 routers as L1/L2 to allow traffic to flow along optimal
   paths through such transit areas.  Consequently, this approach fails
   to reduce the number of L2 routers involved, so it fails to increase
   the scalability of the L2 backbone.”


These problem statements seem fundamentally similar to me.

No question the two drafts define very different solutions – but the problem 
statements seem quite similar to me.

Tony P – I would argue that a “20K perspective” is useful when deciding whether 
the overall approach is a good one.

And in response to Tony Li’s statement:  “…the IETF is at its best when it is 
documenting de facto standards”

1) I fully believe that our customers understand their requirements(sic) better 
than we (vendors) do. But that does not mean that they understand what is the 
best solution better than we do.
When a customer comes to me and says “Can you do this?” my first response is 
usually “Please fully describe your requirements independent of the solution.”

2)Not clear to me that there is an existing “de facto standard” here – which is 
reinforced by the fact that we have so many different solutions proposed.

   Les



From: Acee Lindem (acee) 
Sent: Tuesday, December 7, 2021 10:31 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

Hi Les,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

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 u

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

[Les Ginsberg (ginsberg)]

Let me try to respond to Acee/Tony/Tony in one email.

Acee – I don’t like any of the proposals. I believe they are all abusing the 
protocols to some degree.
I fully believe that the authors are clever enough to figure out how to make 
this work – but that doesn’t mean any of them are desirable.
So if I have to “vote” – I vote “no”.

Tony Li –

Area Proxy Introduction says in part:

“Following the current rules of IS-IS, all spine routers would
   necessarily be part of the Level 2 topology, plus all links between a
   Level 2 leaf and the spines.  In the limit, where all leaves need to
   support Level 2, it implies that the entire L3LS topology becomes
   part of Level 2.  This is seriously problematic as it more than
   doubles the LSDB held in the L3LS topology and eliminates any
   benefits of the hierarchy.”

Flood Reflection says:

“In such scenarios, an
   alternative approach is to consider multiple L2 flooding domains
   connected together via L1 flooding domains.  In other words, L2
   flooding domains are connected by "L1/L2 lanes" through the L1 areas
   to form a single L2 backbone again.  Unfortunately, in its simplest
   implementation, this requires the inclusion of most, or all, of the
   transit L1 routers as L1/L2 to allow traffic to flow along optimal
   paths through such transit areas.  Consequently, this approach fails
   to reduce the number of L2 routers involved, so it fails to increase
   the scalability of the L2 backbone.”


These problem statements seem fundamentally similar to me.

No question the two drafts define very different solutions – but the problem 
statements seem quite similar to me.

Tony P – I would argue that a “20K perspective” is useful when deciding whether 
the overall approach is a good one.

And in response to Tony Li’s statement:  “…the IETF is at its best when it is 
documenting de facto standards”

1) I fully believe that our customers understand their requirements(sic) better 
than we (vendors) do. But that does not mean that they understand what is the 
best solution better than we do.
When a customer comes to me and says “Can you do this?” my first response is 
usually “Please fully describe your requirements independent of the solution.”

2)Not clear to me that there is an existing “de facto standard” here – which is 
reinforced by the fact that we have so many different solutions proposed.

   Les



From: Acee Lindem (acee) 
Sent: Tuesday, December 7, 2021 10:31 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

Hi Les,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

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

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

[Tony Przygienda]

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

-- tony

On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg)  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  *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 14th
> , 2021. Also 

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

[Tony Li]

Hi Les,

> 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’m not sure where you got that perspective about Area Proxy. That is not the 
intent at all.

Legacy IS-IS forces a provider to expose some of the topology of an L1 area in 
L2 if the L1 area is to provide transit.  You literally have to make big chunks 
of the topology L1L2 and it all shows up in the L2 database. As a result, the 
amount of abstraction that’s achieved is minimal: only the portions of the L1 
area that are NOT L1L2 are abstracted away.

Area Proxy turns up the abstraction dial. Nothing more, nothing less. Abstract 
away ALL of the L1 area topology. The L1L2 portion of the topology is still 
present, it’s just no longer visible in the L2 LSDB outside of the area. That’s 
the scalability win.

There is still an L2 backbone, that is unchanged. Only the abstraction has 
changed.


> 1)Is this a problem which needs to be solved by link-state protocols?


Yes. IS-IS has an inherent scalability limitation without some additional 
abstraction.


> Also, many datacenters use BGP (w or w/o IGP) and therefore have other ways 
> to address such issues.


The problem comes from exactly this use case: what happens when your data 
center becomes a transit node for your backbone?


> 2)If link state protocols do need to solve this problem, what is the 
> preferred way to do that?


I don’t see this as an either/or choice, nor is it one where we’re going to 
make a useful decision without some market input.


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


I would suggest that, as always, the IETF is at its best when it is documenting 
de facto standards. :-)

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Les,

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" , "lsr@ietf.org" 

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

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.

Given the discussions of these solutions over the last two years in LSR, I 
don’t think we need to rehash this – especially on the experimental track.

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

Are you saying you don’t want any experimental solutions unless we have one 
standardized solution that everybody agrees on? Please review this one as part 
of WG last call.

Thanks,
Acee

   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  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 14th , 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

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

[Les Ginsberg (ginsberg)]

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  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 14th , 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

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

[Aijun Wang]

It may be useful in some corner case and under careful design, but not the 
evolution of IGP, or the widespread deployment trend within operators.

Let’s see in futures how many ISPs will evolve their infrastructure into this 
direction.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Tony Przygienda  
Sent: Tuesday, December 7, 2021 2:55 AM
To: Aijun Wang 
Cc: Acee Lindem (acee) ; lsr 
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

 

 

 

On Mon, Dec 6, 2021 at 4:42 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Do not support its publication.

 

Very curious  which operator will have such network design that the L1 routers 
locate in the middle but the L2 routers sits around them.

 

Do read the draft carefully to understand that this is an evolution of a L2 
network (which large amount of providers world-wide run since 20+ years by now) 
and not description of current deployment. This technology is being deployed by 
large operators currently who face the challenge of ISIS L2 not scaling to the 
numbers they seek based on several drivers. 

 

-- tony 

 

 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Chris Bowers]

I support publication of this document, as a co-author.

Chris

On Mon, Nov 22, 2021 at 1:47 PM Acee Lindem (acee)  wrote:

> 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 14th
> , 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

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

[Lee, Yiu]

I support WG LC for this draft.

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, November 22, 2021 at 14:47
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 14th , 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

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

[Tony Przygienda]

On Mon, Dec 6, 2021 at 4:42 PM Aijun Wang  wrote:

> Do not support its publication.
>
> Very curious  which operator will have such network design that the L1
> routers locate in the middle but the L2 routers sits around them.
>

Do read the draft carefully to understand that this is an evolution of a L2
network (which large amount of providers world-wide run since 20+ years by
now) and not description of current deployment. This technology is being
deployed by large operators currently who face the challenge of ISIS L2 not
scaling to the numbers they seek based on several drivers.

-- tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Do not support its publication.

Very curious  which operator will have such network design that the L1 routers 
locate in the middle but the L2 routers sits around them.
There are also situations that the sub-optimal forwarding path will be emerged 
as also described in the draft which indicates such design and solutions should 
be carefully reviewed and operated in real deployment.
The operations challenges surpasses the scalability advantages that it claims.

Aijun Wang
China Telecom

> On Dec 3, 2021, at 23:00, Acee Lindem (acee) 
>  wrote:
> 
> 
> Speaking as WG Co-Chair:
>  
> While not mandatory for advancement, I’d really like for some the long-time 
> IS-IS contributors to review the draft. You know who you are…
>  
> Thanks,
> Acee
>  
> From: Lsr  on behalf of "Acee Lindem (acee)" 
> 
> Date: Monday, November 22, 2021 at 2:48 PM
> 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 14th , 
> 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

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

[Acee Lindem (acee)]

Speaking as WG Co-Chair:

While not mandatory for advancement, I’d really like for some the long-time 
IS-IS contributors to review the draft. You know who you are…

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, November 22, 2021 at 2:48 PM
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 14th , 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

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

[zhang.zheng]

Support the publishment of this draft. 
Thanks,
Sandy



--原始邮件--
发件人：AceeLindem(acee)
收件人：lsr@ietf.org;
日 期 ：2021年11月23日 03:48
主 题 ：[Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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 14th , 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

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

[Tony Przygienda]

+1 as co-author

On Tue, Nov 23, 2021 at 5:42 PM Acee Lindem (acee)  wrote:

> Speaking as a WG member:
>
>
>
> I support publication of this experimental extension to IS-IS.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Monday, November 22, 2021 at 2:48 PM
> *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 14th
> , 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

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

[Acee Lindem (acee)]

Speaking as a WG member:

I support publication of this experimental extension to IS-IS.
Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, November 22, 2021 at 2:48 PM
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 14th , 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

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

[Parag Kaneriya]

I support this Draft.

Regards
Parag

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, November 23, 2021 1:17 AM
To: lsr@ietf.org
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

[External Email. Be cautious of content]

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 14th , 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

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

[Jeff Tantsura]

Yes/support

Cheers,
Jeff

> On Nov 22, 2021, at 14:47, Acee Lindem (acee) 
>  wrote:
> 
> 
> 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 14th , 
> 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] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Acee Lindem (acee)]

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 14th , 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