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

[Tony Przygienda <[e-mail]>]

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 <[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.
> 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>> 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) <acee=
>>> [e-mail]> 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 <[e-mail]>
>>> *Date: *Wednesday, December 8, 2021 at 11:15 AM
>>> *To: *Acee Lindem <[e-mail]>
>>> *Cc: *"Les Ginsberg (ginsberg)" <[e-mail]>, "[e-mail]" <
>>> [e-mail]>
>>> *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) <acee=
>>> [e-mail]> wrote:
>>>
>>> Hi Les,
>>>
>>>
>>>
>>> *From: *"Les Ginsberg (ginsberg)" <[e-mail]>
>>> *Date: *Tuesday, December 7, 2021 at 5:10 PM
>>> *To: *"Acee Lindem (acee)" <acee=[e-mail]>, Acee
>>> Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
>>> *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=[e-mail]>
>>> *Sent:* Tuesday, December 7, 2021 10:31 AM
>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Acee Lindem (acee) <
>>> [e-mail]>; [e-mail]
>>> *Subject:* Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
>>> -draft-ietf-lsr-isis-flood-reflection-05
>>>
>>>
>>>
>>> Hi Les,
>>>
>>>
>>>
>>> *From: *Lsr <[e-mail]> on behalf of "Les Ginsberg
>>> (ginsberg)" <ginsberg=[e-mail]>
>>> *Date: *Tuesday, December 7, 2021 at 1:17 PM
>>> *To: *"Acee Lindem (acee)" <acee=[e-mail]>, "
>>> [e-mail]" <[e-mail]>
>>> *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 <[e-mail]> *On Behalf Of *Acee Lindem (acee)
>>> *Sent:* Monday, November 22, 2021 11:47 AM
>>> *To:* [e-mail]
>>> *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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>