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

[Muthu Arul Mozhi Perumal <[e-mail]>]

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
>