Re: [Lsr] Using L1 for Transit Traffic in IS-IS

[Tony Przygienda <[e-mail]>]

it's a circular argument to an extent (though I'm sympathetic with the
thought). Unless a draft is an experimental RFC there is no real stable
point to implement & deploy so it's hard these days to get 2
implementations unless one sponsors an open source one (and nature of ISIS
is that there is barely any open source given that it runs normally @ scale
& feature count that open source is simply not efficient enough though I
admit it maybe just my lens to an extent).

So having nothing experimental and nevertheless deployed generates then
de-facto proprietary stuff since deployed solutions become pretty immovable
targets as we all know.

So, take your pick but it's hard to have it both ways these days IMO ...

-- tony

On Sat, Dec 11, 2021 at 4:14 PM Robert Raszuk <[e-mail]> wrote:

>
> Well WFIW IDR solved this dilemma by mandating at least two documented
> implementations before proceeding with any proposal to IESG (irrespective
> of the RFC document type).
>
> After all nothing stops anyone from implementing an idea described in the
> WG document using if needed early code point allocations.
>
> On the other hand having RFC experimental status of any proposal ensures
> it has been reviewed by a number of people and that at least no major
> issues have been found during the review.
>
> Of course IGP is not BGP though both use multiple vendors network
> elements, but I guess that would narrow the gates of single vendors pushing
> their own proprietary solutions via IETF.
>
> Kind regards,
> Robert
>
> On Sat, Dec 11, 2021 at 7:56 AM Gyan Mishra <[e-mail]> wrote:
>
>>
>> Hi Les
>>
>> My thoughts are that as both of these drafts are experimental, if both
>> get published we can let the industry decide which is to be the preferred
>> solution which can then progress as standards track to address
>> interoperability issues with a single solution implemented by vendors.
>>
>> I think by picking one now over the other we are not letting the cards
>> fall on the table and prematurely making a decision and not letting things
>> naturally play out.
>>
>> I agree the implementation of each is non trivial however the router
>> configuration could boil down to a simple knob similar to fast flooding.
>> As an example there maybe use cases that for a DC CLOS topology where area
>> proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
>> however in a core or aggregation domain maybe flood reflection maybe
>> preferred from a topological perspective  during the study phase.
>>
>> I don’t have a crystal ball but it’s possible just as winning the lottery
>> is possible that both drafts garnish industry support and from a sales and
>> marketing perspective vendors can still have their cake and eat it too by
>> solving a major backbone scalability issue win win for all and so
>> developing both solutions that become standards track and implemented by
>> all vendors.  No interoperability issues.
>>
>> I am in agreement on implementation that in the end having a single
>> solution is most desirable to avoid interoperability.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
>> [e-mail]> wrote:
>>
>>> Gyan –
>>>
>>>
>>>
>>> I am interested in your perspective – but could you provide more details?
>>>
>>> What deployment scenarios do you have in mind where one solution is
>>> advantageous over the other? And why are both scenarios likely to be seen
>>> in the real world?
>>>
>>>
>>>
>>> I think you can appreciate that implementation of either solution is
>>> non-trivial – as is insuring interoperability – as is the actual deployment.
>>>
>>> What justifies doubling that effort?
>>>
>>>
>>>
>>> Thanx.
>>>
>>>
>>>
>>>     Les
>>>
>>>
>>>
>>> *From:* Gyan Mishra <[e-mail]>
>>> *Sent:* Friday, December 10, 2021 5:46 PM
>>> *To:* Muthu Arul Mozhi Perumal <[e-mail]>
>>> *Cc:* Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg) <
>>> [e-mail]>; Tony Li <[e-mail]>; Tony Przygienda <
>>> [e-mail]>; [e-mail]
>>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> All
>>>
>>>
>>>
>>> As Acee mentioned per the subject of this thread “Using L1 for transit
>>> traffic in IS-IS” is supported today and is deployed by operators with
>>> large backbones as well today, and both solutions,  area proxy and flood
>>> reflection now allows the L1 transit solution  to scale.
>>>
>>>
>>>
>>> Speaking from an operators perspective we are in favor of multiple
>>> solutions as their maybe use cases where one applies better then the other
>>> and vice versa.  Flexibility is a good thing.
>>>
>>>
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal <
>>> [e-mail]> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> It is possible to designate experimental RFCs as historic if there is no
>>> evidence of widespread use over a period of time, as is currently being
>>> done for HTTP-related experimental RFCs:
>>>
>>>
>>> https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/
>>>
>>>
>>>
>>> Hence, I think having multiple experimental publications for a problem
>>> is ok..
>>>
>>>
>>>
>>> Regards,
>>>
>>> Muthu
>>>
>>>
>>>
>>> On Fri, Dec 10, 2021 at 6:08 AM Les Ginsberg (ginsberg) <ginsberg=
>>> [e-mail]> wrote:
>>>
>>> Acee –
>>>
>>>
>>>
>>> Thanx for responding while you are on vacation.
>>>
>>>
>>>
>>> While it is true I am not enthusiastic about any of the solutions, my
>>> point of emphasis is that it’s a failure of WG process to simply move
>>> forward with all solutions – which it seems to me is what is about to
>>> happen.
>>>
>>>
>>>
>>> Note that this is completely consistent with what I said back when WG
>>> adoption for the drafts was being discussed (thanx to Tony P for pointing
>>> me back to that time (June 21, 2020)):
>>>
>>>
>>>
>>> *<snip>*
>>>
>>> *I support the WG adoption of
>>> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>>> <https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/> .*
>>>
>>>
>>>
>>> *(I also support WG adoption of
>>> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
>>> <https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection> )*
>>>
>>>
>>>
>>> *I believe the problem space addressed by these two drafts warrants
>>> attention.*
>>>
>>> *…*
>>>
>>> *The easy road for the WG to take would be to simply allow both drafts
>>> to proceed to Experimental RFCs, but I hope we are able to do more than
>>> this. Multiple solutions place undesirable burdens on vendors and providers
>>> alike.*
>>>
>>>
>>>
>>> *To the extent they feel comfortable, I encourage folks who wish to
>>> deploy such solutions to share their requirements and discuss how each of
>>> the solutions*
>>>
>>> *address their requirements/fall short of addressing their requirements.
>>> I think this would help the WG discover better ways forward.*
>>>
>>>
>>>
>>> *<end snip>*
>>>
>>>
>>>
>>> Don’t think we have made progress in that regard…
>>>
>>>
>>>
>>>    Les
>>>
>>>
>>>
>>>
>>>
>>> *From:* Acee Lindem (acee) <[e-mail]>
>>> *Sent:* Thursday, December 9, 2021 1:59 PM
>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Tony Przygienda <
>>> [e-mail]>
>>> *Cc:* Tony Li <[e-mail]>; [e-mail]
>>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> Hi Les,
>>>
>>>
>>>
>>> I know you don’t feel that the IGP should solve this problem but there
>>> was lots of interest in the three solutions to reduce the overhead when
>>> using IS-IS L1 as transit for IS- IS L2. Let’s not rehash that.
>>>
>>>
>>>
>>> What do feel needs to be done? Note that I’m on vacation and unlikely to
>>> engage again until next week…
>>>
>>>
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>> *From: *"Les Ginsberg (ginsberg)" <[e-mail]>
>>> *Date: *Thursday, December 9, 2021 at 2:05 PM
>>> *To: *Tony Przygienda <[e-mail]>
>>> *Cc: *Tony Li <[e-mail]>, "[e-mail]" <[e-mail]>, Acee
>>> Lindem <[e-mail]>
>>> *Subject: *RE: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> Let me try to clarify my position…
>>>
>>>
>>>
>>> Two disjoint sets of authors looked at the same problem space and
>>> independently came up with two different (and incompatible) protocol
>>> extensions to provide a solution.
>>>
>>>
>>>
>>> (Aside: I believe fully that both sets of authors have done their best
>>> to define what they think is a good solution. If anything I have said
>>> suggests otherwise,  that was not my intent and I apologize to both sets of
>>> authors for any misunderstanding.)
>>>
>>>
>>>
>>> Both solutions have been published as WG documents and assigned protocol
>>> codepoints.
>>>
>>> We are now being asked to publish both drafts as RFCs (I am assuming
>>> based on Tony Li’s response that the LC request for Area Proxy is soon to
>>> happen.)
>>>
>>>
>>>
>>> I don’t believe the WG has reached consensus that the IGPs should be
>>> extended to address the problem.
>>>
>>> I don’t believe the WG has reached consensus as to which solution is
>>> “better”.
>>>
>>> I don’t believe the WG has even discussed whether a single solution or
>>> multiple solutions are required.
>>>
>>> If multiple solutions are required, there has been no discussion as to
>>> when each of the solutions should be used. Are there some deployment
>>> scenarios where flood-reflection is a better fit and some where area proxy
>>> is a better fit?
>>>
>>> Is there a need for additional solutions i.e., deployments where neither
>>> of the current candidates are suitable?
>>>
>>>
>>>
>>> It seems to me that by entertaining a LC request at this point we are
>>> simply functioning as a pass through to allow multiple individual solutions
>>> to be published as RFCs. And while there are currently two solutions to the
>>> same problem space asking to progress, I think we can expect others and we
>>> have no basis on which to reject other proposals.
>>>
>>>
>>>
>>> This is very different from how any other work brought before the
>>> LSR/OSPF/IS-IS WGs has been done in the 20+ years during which I have been
>>> an active participant.
>>>
>>> In all other cases, the WG has strived to come up with a single
>>> interoperable solution.
>>>
>>> Sometimes only one solution is proposed and it is refined based on
>>> discussion and then progressed.
>>>
>>> Sometimes multiple solutions are proposed and there is discussion of
>>> both which results in choosing one over the other or some sort of merge of
>>> the solutions.
>>>
>>> But I do not recall a case where the WG simply allowed multiple
>>> non-interoperable solutions to the same problem to be published as RFCs
>>> largely w/o comment.
>>>
>>>
>>>
>>> I do not think this is an appropriate use of the Standards process and I
>>> do not think this serves the industry.
>>>
>>> This does not mean that either solution is w/o merit – but I do think
>>> the requests for Last Call are premature.
>>>
>>> But, this is just my opinion.
>>>
>>> If the WG (members, chairs, and ADs) think otherwise then the WG should
>>> act appropriately.
>>>
>>>
>>>
>>> Thanx for listening.
>>>
>>>
>>>
>>>    Les
>>>
>>>
>>>
>>>
>>>
>>> *From:* Tony Przygienda <[e-mail]>
>>> *Sent:* Wednesday, December 8, 2021 5:27 AM
>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>
>>> *Cc:* Tony Li <[e-mail]>; [e-mail]; Acee Lindem (acee) <
>>> [e-mail]>
>>> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>>>
>>>
>>>
>>> Les, all sounds to me unfortunately like a gripe (and a late one @ that
>>> now that things were worked on in WG for years & are ready to RFC being
>>> customer deployed, @ least flood reflection is).
>>>
>>>
>>>
>>> Plus,  unless you have a dramatically better idea than the drafts
>>> extended I fail to understand what your point is except as Tony1 says "we
>>> should not scale IGP higher?" (AFAIS hierarchy is not an answer here unless
>>> you ask customers for a flag day with lots new static configuration
>>> everywhere and possibly restructuring of their network to a hard-coded
>>> "hierarchy" and albeit such effort may work in some totalitarian countries
>>> on in pretty small networks, the majority of large ISIS customers will end
>>> such discussions in timeframe of single minutes clock count ;-)
>>>
>>>
>>>
>>> -- tony
>>>
>>>
>>>
>>> On Wed, Dec 8, 2021 at 4:23 AM Les Ginsberg (ginsberg) <ginsberg=
>>> [e-mail]> wrote:
>>>
>>> (Subject was:  RE: [Lsr] WG Last Call for "IS-IS Flood Reflection"
>>> -draft-ietf-lsr-isis-flood-reflection-05)
>>>
>>>
>>>
>>> (Changing the subject as Acee has suggested that discussion of the
>>> problem space is inappropriate for the WG LC thread)
>>>
>>>
>>>
>>> Tony (and everyone) –
>>>
>>>
>>>
>>> This isn’t the first contentious issue the WG has considered. By way of
>>> comparison (hopefully a useful one), a number of folks (including you and
>>> I) are participating in another contentious issue – fast-flooding.
>>>
>>> But for fast-flooding there is broad WG consensus that fast-flooding is
>>> something that IS-IS should do. The contentious part is regarding what is
>>> the best way to do it. And we are proceeding in a manner where different
>>> algorithms are being tested while still in the WG document stage. And there
>>> is hope (still TBD) that multiple algorithms may be able to interoperate.
>>>
>>>
>>>
>>> Here, I am not convinced that there is broad WG consensus that this is a
>>> problem that the IGPs should solve. (If I am wrong on that I presume the WG
>>> members will let me know.)
>>>
>>> And, we have multiple proposals, none of which have any hope of
>>> interoperating with each other.
>>>
>>> And we have had very little discussion about the problem space. (not
>>> your fault – certainly you have been willing as have the authors of the
>>> competing draft)
>>>
>>>
>>>
>>> So, at best, I think WG LC is premature. I would like to see more
>>> discussion as to whether this is a problem that IGPs should solve as well
>>> as a general look at how this might be done with and/or without the IGPs.
>>>
>>> And since all of the proposed solutions have been allocated code points,
>>> they can continue to gain implementation/deployment experience in the
>>> meantime. Therefore, I do not see that we need to make this choice now.
>>>
>>>
>>>
>>> I realize that you are not the one asking for WG LC and I don’t know
>>> when you plan to do so and I am not trying to influence you in that regard.
>>>
>>> But for me, WG LC is at best premature.
>>>
>>>
>>>
>>> As regards you trying to solve a real world customer ask, I was aware of
>>> that. And I believe the authors of flood-reflection can make the same claim.
>>>
>>>
>>>
>>> Thanx for listening,
>>>
>>>
>>>
>>>     Les
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Tony Li <[e-mail]> *On Behalf Of *Tony Li
>>> *Sent:* Tuesday, December 7, 2021 2:53 PM
>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>
>>> *Cc:* Acee Lindem (acee) <[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
>>>
>>>
>>>
>>>
>>>
>>> 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
>>> [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
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>