Les,
Lots of thanks, makes sense to me.
Thumb typed by Sasha Vainshtein
From: Les Ginsberg (ginsberg)
Sent: Tuesday, March 5, 2019 10:48:43 PM
To: Alexander Vainshtein
Cc: lsr@ietf.org; spr...@ietf.org;
draft-ietf-isis-segment-routing-extensions@ietf.org;
Hi Tony,
> From: Tony Li [mailto:tony1ath...@gmail.com]
> Sent: Wednesday, February 27, 2019 2:07 AM
> To: Huaimo Chen
> Cc: Peter Psenak ; Christian Hopps ;
> lsr@ietf.org;
> lsr- cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 +
>
> we want to limit the flooding to minimum, which is 2.
>
Is that really a common agreement in the WG ? I have a feeling think this
is too restrictive for no valid technical reason.
r.
___
Lsr mailing list
Lsr@ietf.org
Robert,
On 05/03/2019 22:06 , Robert Raszuk wrote:
Peter,
you only have two paths to reach any node.
Who says that you must be limited to two paths only ?
Why not create a flooding graph such that flooding will happen over 4
paths as opposed to flooding over 16 or 32 today without
Hi Tony,
On 05/03/2019 21:47 , tony...@tony.li wrote:
LS topologies can have a very large number of adjacencies as well,
typically with multiple spines, so for a new spine, all of the of the
links may be unnecessary.
ok, we talked bout the balance before - adding one link at a time to
the
Peter,
> you only have two paths to reach any node.
Who says that you must be limited to two paths only ?
Why not create a flooding graph such that flooding will happen over 4 paths
as opposed to flooding over 16 or 32 today without optimization.
And if you are worried that you loose *wisely
Got it,
thx
-Original Message-
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, March 5, 2019 3:59 PM
To: David Allan I
Cc: Peter Psenak ; lsr@ietf.org
Subject: Re: [Lsr] Open issues with Dynamic Flooding
Hi Dave,
> My understanding of this whole endeavor is that:
>
> -
Hi Dave,
> My understanding of this whole endeavor is that:
>
> - excessive flooding slows convergence
> - so we are seeking to define a reduced flooding topology
> - a failure that does not impact an FT adjacency is propagated throughout the
> topology and the effects of excessive flooding
OK gents, sadly I’m losing the plot here..
My understanding of this whole endeavor is that:
- excessive flooding slows convergence
- so we are seeking to define a reduced flooding topology
- a failure that does not impact an FT adjacency is propagated throughout the
topology and the effects
Sasha -
Although you raise a valid issue, I am not feeling any urgency here i.e.,
although the local protected use case is valid I don't see it as operationally
critical.
However, that's just my opinion.
If you want to pursue this I think you could raise the issue in either LSR or
SPRING (or
>> LS topologies can have a very large number of adjacencies as well,
>> typically with multiple spines, so for a new spine, all of the of the
>> links may be unnecessary.
>
> ok, we talked bout the balance before - adding one link at a time to the FT
> may result in slow recovery, while adding
Hi Tony,
On 05/03/2019 17:47 , tony...@tony.li wrote:
Hi Peter,
Adding all links on a single node to the flooding topology is not
going to cause issues to flooding IMHO.
Could you (or John) please explain your rationale behind that? It
seems counter-intuitive.
it's limited to the links
Robert,
On 05/03/2019 20:12 , Robert Raszuk wrote:
Slow convergence is obviously not a good thing
Could you please kindly elaborate why ?
With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
convergence* is
Tony-P,
I am not talking about LAGs but pure vanilla L3 ECMP paths in any DC.
Any node will be receiving at least two copies of flooded topology
(regardless in which direction you look up or down) so when one of the
links is broken which is used for actual flooding or peer sending link
state
On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk wrote:
>
> > Slow convergence is obviously not a good thing
>
> Could you please kindly elaborate why ?
>
> With tons of ECMP in DCs or with number of mechanism for very fast data
> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
> Slow convergence is obviously not a good thing
Could you please kindly elaborate why ?
With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
is no longer a necessity. Yet many folks still talk about
Les,
Lots of thanks for a prompt response.
I fully understand that the current SR extension drafts are too far advanced
for any significant changes.
I also understand that Algo-specific Adj-SIDs require an update to RFC 8402
because today it does not recognize any such entities.
Therefore the
in practical terms +1 to Peter's take here ... Unless we're talking tons of
failures simultaneously (which AFAI talked to folks are not that common but
can sometimes happen in DCs BTW due to weird things) smaller scale failures
with few links would cause potentially diffused "chaining" of
Sasha -
draft-ietf-isis-segment-routing-extensions is currently in AD review - and the
companion OSPF document has already been approved and is waiting for a
dependent draft to progress before publication as an RFC.
It is too late to make significant changes.
Further, while I agree with both
Hi Sasha,
On 05/03/2019 17:28 , Alexander Vainshtein wrote:
Peter,
Lots of thanks for a prompt and very encouraging response.
Do you think that the new Algo specific Adj-SID sub-TLV could be added to the
current IS-IS segment Routing Extensions draft, or should be handled in a small
Peter,
Lots of thanks for a prompt and very encouraging response.
Do you think that the new Algo specific Adj-SID sub-TLV could be added to the
current IS-IS segment Routing Extensions draft, or should be handled in a small
dedicated document?
Regards, and lots of thanks in advance,
Sasha
Hi Tony,
On 05/03/2019 17:16 , tony...@tony.li wrote:
Peter,
(a) Temporarily add all of the links that would appear to remedy the
partition. This has the advantage that it is very likely to heal the partition
and will do so in the minimal amount of convergence time.
I prefer (a)
Peter,
>>(a) Temporarily add all of the links that would appear to remedy the
>> partition. This has the advantage that it is very likely to heal the
>> partition and will do so in the minimal amount of convergence time.
>
> I prefer (a) because of the faster convergence.
> Adding all
I agree w/ Peter.
Yours Irrespectively,
John
> -Original Message-
> From: Lsr On Behalf Of Peter Psenak
> Sent: Tuesday, March 5, 2019 2:38 AM
> To: tony...@tony.li; lsr@ietf.org
> Subject: Re: [Lsr] Open issues with Dynamic Flooding
>
> Hi Tony,
>
> On 04/03/2019 18:54 ,
Hi Sasha,
On 02/03/2019 18:57 , Alexander Vainshtein wrote:
Peter,
Lots of thanks for a prompt and hivhly informative response.
It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local.
The relevant use case could be a protected local Adj-SID that is used in
a SR-TE LSP that
Xiaohu,
On 05/03/2019 09:48 , 徐小虎(义先) wrote:
Given that all links between routers are p2p these days, I would vote
for simplicity and make the LAN always part of the FT.
Even all links between routers are P2P these days, the network
management LAN if available could be leveraged to
> Given that all links between routers are p2p these days, I would vote
> for simplicity and make the LAN always part of the FT.
Even all links between routers are P2P these days, the network management LAN
if available could be leveraged to realize an efficient link-state
synchronization
27 matches
Mail list logo
