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

[Tony Przygienda <[e-mail]>]

inline. last email from my side in this thread.


On Sat, Dec 11, 2021 at 3:47 PM Aijun Wang <[e-mail]>
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 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?
>

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.


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

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


>
>