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

From: Aijun Wang <[email-masked]>
Date: Thu, 9 Dec 2021 00:15:07 +0800

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) <acee=[email-masked]> wrote:
> 
> Hi Les,
>  
> From: "Les Ginsberg (ginsberg)" <[email-masked]>
> Date: Tuesday, December 7, 2021 at 5:10 PM
> To: "Acee Lindem (acee)" <acee=[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
> 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) <acee=[email-masked]> 
> Sent: Tuesday, December 7, 2021 10:31 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05
>  
> Hi Les,
>  
> From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
> Date: Tuesday, December 7, 2021 at 1:17 PM
> To: "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>
> 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 <[email-masked]> On Behalf Of Acee Lindem (acee)
> Sent: Monday, November 22, 2021 11:47 AM
> To: [email-masked]
> Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05
>  
> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please post your support or objection to this list by 12:00 AM UTC on Dec 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Dec 2021 02:07:14 +0000

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 <[email-masked]>
Date: Wednesday, December 8, 2021 at 11:15 AM
To: Acee Lindem <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Hi, Acee:

Aijun Wang
China Telecom

Thanks,
Acee

Tony Li –

Flood Reflection says:

“In such scenarios, an

   Les

Hi Les,

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

and

Thanks,
Acee

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Monday, November 22, 2021 11:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Thanks,
Acee

---

From: Aijun Wang <[email-masked]>
Date: Fri, 10 Dec 2021 08:34:34 +0800

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) <acee=[email-masked]> wrote:
> 
> 
> Hi Aijun,
>

---

From: Tony Li <[email-masked]>
Date: Thu, 9 Dec 2021 21:12:43 -0800

Hi Aijun,

> 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

---

From: Aijun Wang <[email-masked]>
Date: Fri, 10 Dec 2021 13:28:12 +0800

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 <[email-masked]> wrote:
> 
> 
> 
> Hi Aijun,
>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 10 Dec 2021 19:01:22 +0100

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

> One technical considerations is the following: if IGP evolved into this
> direction, then the following connections loop diagram is also possible:
> Then, will we introduce the “AS number” to avoid loop, and various “Path
> Attributes” to influence the path selection within the IGP?
>
> 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 <[email-masked]>
> *Date: *Wednesday, December 8, 2021 at 11:15 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> 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 documents itself, there are unsolved problems (for example in
> section 7) which can only be solved by “sending alarm and declare
> misconfiguration).
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <[email-masked]>
> *Date: *Tuesday, December 7, 2021 at 5:10 PM
> *To: *"Acee Lindem (acee)" <acee=[email-masked]>, Acee Lindem
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> 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.
>
> 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.
>
>
>
> 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) <acee=[email-masked]>
> *Sent:* Tuesday, December 7, 2021 10:31 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> Hi Les,
>
>
>
> *From: *Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)"
> <ginsberg=[email-masked]>
> *Date: *Tuesday, December 7, 2021 at 1:17 PM
> *To: *"Acee Lindem (acee)" <acee=[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
> 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 <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, November 22, 2021 11:47 AM
> *To:* [email-masked]
> *Subject:* [Lsr] WG Last Call fo "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05
>
>
>
> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05.
> Please post your support or objection to this list by 12:00 AM UTC on Dec 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
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 11 Dec 2021 15:48:23 +0800

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 <[email-masked]> 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 <[email-masked]> wrote:
>> Hi, Acee:
>>

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 11 Dec 2021 13:06:52 +0100

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.
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.
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. However, as the documentation you found says it is
easier to ensure that L1 metrics when deployed are shorter than L2 metrics
so the L1->L2 route always takes preference towards the egress and not rely
on the correct SPF preferece outside metric comparison. As footnote:
redistributing prefixes in ISIS is always delicate, nothing new here,
L1->L2->L1 was originally forbidden and only works with the RFC and lots of
tightly kept pref rules. With enough inventive re-distribution on a system
around the RFC and fiddiling via policy with redistributed route properties
you can loop up normal ISIS as well BTW.
c) ECMP, yes, as our doc says it's not looping but it can be changed when
using b.ii) unless whole network is forklifted to flood reflection and e.g.
omits ECMP computed over FR adjacencies which again, is an implementation
technique that is optional complexity since FR adjacencies are not
forwarding (one could make them taht and stuff would still work but then we
would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP
inside L1 and ultimately shove e'thing though FRs, most customers think
that doing L2 hot potato forwarding out the area is actually far preferred
IME).

And no, you will never 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 <[email-masked]>
wrote:

> 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?
>
>> 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
>> 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.
>>
>> *To: *"Acee Lindem (acee)" <acee=[email-masked]>, Acee
>> Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
>> 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
>>
>>
>>
>> *From: *Lsr <[email-masked]> on behalf of "Les Ginsberg
>> (ginsberg)" <ginsberg=[email-masked]>
>> 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.
>>
>> 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.
>>
>>
>>
>> , 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
>>
>>
>>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 11 Dec 2021 22:46:55 +0800

Hi, Tony:

The advantage of IGP is that it can cure itself when there is any topology change, no additional  operator intervention involved.
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?
And, if we lack one trust theory to avoid the loop, we will be stuck in the emerged loop situations.

Some additional replies inline.

Aijun Wang
China Telecom

> On Dec 11, 2021, at 20:08, Tony Przygienda <[email-masked]> wrote:
> 
> 
> 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?

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

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

> However, as the documentation you found says it is easier to ensure that L1 metrics when deployed are shorter than L2 metrics so the L1->L2 route always takes preference towards the egress and not rely on the correct SPF preferece outside metric comparison.

[WAJ] To achieve this, the design should be verified by manual carefully?

> As footnote: redistributing prefixes in ISIS is always delicate, nothing new here, L1->L2->L1 was originally forbidden and only works with the RFC and lots of tightly kept pref rules. With enough inventive re-distribution on a system around the RFC and fiddiling via policy with redistributed route properties you can loop up normal ISIS as well BTW. 

[WAJ] Can I say that your solution is based on the original forbidden design? To explore the forbidden, you introduce the additional SPF rules. When the topology or interconnection scenario become complex, will the SPF rules complex also?

> c) ECMP, yes, as our doc says it's not looping but it can be changed when using b.ii) unless whole network is forklifted to flood reflection and e.g. omits ECMP computed over FR adjacencies which again, is an implementation technique that is optional complexity since FR adjacencies are not forwarding (one could make them taht and stuff would still work but then we would have all kind of restrictions on tunnels like e.g. XoUDP to ECMP inside L1 and ultimately shove e'thing though FRs, most customers think that doing L2 hot potato forwarding out the area is actually far preferred IME).
> 
> And no, you will never 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 <[email-masked]> wrote:

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 11 Dec 2021 16:29:39 +0100

sorry, seems you didn't parse what I wrote in previous email and keep on
generating FUD. The solution is loop free if the draft is correctly
implemented in both tunnel and no-tunnel scenario. The rest is subtlety of
how you deploy it (and implementation choices) that I tried to explain. I
cannot put it more simply than that ...

-- tony

On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Tony:
>
> The advantage of IGP is that it can cure itself when there is any topology
> change, no additional  operator intervention involved.
> 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?
> [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?
>
> 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.
>
> However, as the documentation you found says it is easier to ensure that
> L1 metrics when deployed are shorter than L2 metrics so the L1->L2 route
> always takes preference towards the egress and not rely on the correct SPF
> preferece outside metric comparison.
>
>
> As footnote: redistributing prefixes in ISIS is always delicate, nothing
> new here, L1->L2->L1 was originally forbidden and only works with the RFC
> and lots of tightly kept pref rules. With enough inventive re-distribution
> on a system around the RFC and fiddiling via policy with redistributed
> route properties you can loop up normal ISIS as well BTW.
>
>
> [WAJ] Can I say that your solution is based on the original forbidden
> design? To explore the forbidden, you introduce the additional SPF rules.
> When the topology or interconnection scenario become complex, will the SPF
> rules complex also?
>
> hope that's enough details, none of this is BTW pure speculation but
> output of implemenation and extensive testing.
>
> --- tony
>
>> 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?
>>
>> 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
>>> 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.”
>>>
>>>
>>>
>>> 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

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 11 Dec 2021 19:09:25 +0100

inline. last email from my side in this thread.

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

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

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

> the loop is not transient. It seems when R1 is not act as FR client, the

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

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

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

> [WAJ] To achieve this, the design should be verified by manual carefully?

no, it just says you should keep L1s shorter than L2 in deployment
preferrably. Even if you don't the rules of section 5.2 will route
correctly but decision in SPF is more complicated as described.

> When the topology or interconnection scenario become complex, will the SPF

no. read RFC2966 and ensuing work. Most new features extend the protocol by
either new formats or procedures. Most need forklifting, some don't. SPF
rules don't change no matter what topology you build.

-- tony