Hi Jeff,
On 24/08/18 00:59 , Jeff Tantsura wrote:
Peter,
As previously stated - I'm against gating, it should be developed in parallel
and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about
generic DC Routing
Speaking as WG member:
I agree on this and don't believe we need a separate document or a protracted
discussion.
Additionally, I don't think we should worry about anything going on in other
WGs.
Thanks,
Acee
P.S. I'll provide more input to the discussion as well. As luck would have it,
I
So, going Old Skool here:
Since everyone agrees that this is a reasonable direction, how about we have a
real discussion on the list?
Requirement number 1 is straightforward: a significant reduction in flooding
overhead.
The basis for this requirement is the understanding that in a dense
Hi Qin,
On 8/23/18, 11:03 PM, "Qin Wu" wrote:
Hi, Folks:
draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as
draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
Hi Tony,
On 24/08/18 17:03 , tony...@tony.li wrote:
So, going Old Skool here:
Since everyone agrees that this is a reasonable direction, how about we have a
real discussion on the list?
Requirement number 1 is straightforward: a significant reduction in flooding
overhead.
The basis for
> a) we are talking any kind of topology for the solution, i.e. generic graph?
Well, the problem with a topology restriction is that mistakes happen. If we
have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and
someone mistakenly inserts a leaf to leaf link, what
Hey Tony,
as to miscabling: yepp, the protocol has either to prevent adjacencies
coming up or one has to deal with generic topologies. If you don't want to
design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT
did) you have to deal with generic graph as you say. I think that
Tonys / Everyone,
> moreover, I observe that IME ISIS is much more robust under such
optimizations since the CSNPs catch (@ a somehow ugly delay cost)
> any corner cases whereas OSPF after IDBE will happily stay out of sync
forever if flooding skips something (that may actually become a
> reason
OK, good, real work. So from some scar tissue here's one question
a) we are talking any kind of topology for the solution, i.e. generic
graph?
and then suggestion for IME realistic, operational MUST requirements
b) req a): the solution should support distributed and centralized
algorithm to
I think distributed is more practical too.
For computing routes, we have been using distributed SPF on every node for many
years.
In fact, we may not need to run the exact algorithm on every node. As long as
the algorithms running on different nodes generate the same result, that would
work.
Hi Tal,
Many thanks for your comments.
Updated draft has been published for your review.
Cheers,
Jeff
From: Tal Mizrahi
Date: Monday, August 20, 2018 at 23:45
To: , ,
,
Cc: , "Yemin (Amy)"
Subject: RtgDir review: draft-ietf-ospf-segment-routing-msd
Resent-From:
Resent-To: Jeff
11 matches
Mail list logo
