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 <[email protected]>
Sent: Friday, December 10, 2021 5:46 PM
To: Muthu Arul Mozhi Perumal <[email protected]>
Cc: Acee Lindem (acee) <[email protected]>; Les Ginsberg (ginsberg)
<[email protected]>; Tony Li <[email protected]>; Tony Przygienda
<[email protected]>; [email protected]
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
<[email protected]<mailto:[email protected]>> 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)
<[email protected]<mailto:[email protected]>> 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/ .
(I also support WG adoption of
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) <[email protected]<mailto:[email protected]>>
Sent: Thursday, December 9, 2021 1:59 PM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
Tony Przygienda <[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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)" <[email protected]<mailto:[email protected]>>
Date: Thursday, December 9, 2021 at 2:05 PM
To: Tony Przygienda <[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Acee
Lindem <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Sent: Wednesday, December 8, 2021 5:27 AM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf
Of Tony Li
Sent: Tuesday, December 7, 2021 2:53 PM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; Acee Lindem
(acee) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
--
[Image removed by sender.]<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [email protected]<mailto:[email protected]>
M 301 502-1347
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
