Re: [Lsr] Flooding Path Direction

[Jakob Heitz (jheitz)]

How is it impossible that A may flood to B, but B does not flood to A ?
How does it follow that if A floods to B, then B must also flood to A ?

Uni-directional flooding allows a more efficient flooding topology to be built.
Suppose you had to build a flooding topology with the rule: 2 incoming and 2 
outgoing floods.
With bidirectional flooding, the incoming are the same as the outgoing,
so any incoming flood can only be propagated on one interface.
With uni-directional, any incoming can go out two interfaces.
To achieve 2 out with bidirectional, you need 3 in, 3 out, because the ins and 
outs are the same.

Regards,
Jakob.

-Original Message-
From: Peter Psenak  
Sent: Thursday, April 4, 2019 12:28 AM
To: Jakob Heitz (jheitz) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flooding Path Direction

Jakob,

given that there is a single flooding topology calculated for an area, I 
don't see how this can be unidirectional, considering that flooding 
topology is used to flood in any direction.

thanks,
Peter


On 04/04/2019 08:26 , Jakob Heitz (jheitz) wrote:
> I mean flooding in one direction only, not unidirectional forwarding.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Tony Li  *On Behalf Of *tony...@tony.li
> *Sent:* Wednesday, April 3, 2019 11:19 PM
> *To:* Jakob Heitz (jheitz) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Flooding Path Direction
>
>
>
>
>
> I think this is too restrictive.
>
> We should not exclude algorithms that can build a flooding topology
> with unidirectional links.
>
>
>
>
>
> Well, right now, the protocol doesn't really support unidirectional
> links. At all.
>
>
>
> Tony
>
>
>
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding Path Direction

[Jakob Heitz (jheitz)]

I think this is too restrictive.
We should not exclude algorithms that can build a flooding topology with 
unidirectional links.

Regards,
Jakob.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, April 3, 2019 10:10 PM
To: Jakob Heitz (jheitz) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flooding Path Direction


The direction of the Flooding Path in draft-ietf-lsr-dynamic-flooding-00
is not clear.

I think it should be uni-directional, such that path (1,2) is different to
path (2,1). If the path (1,2) should be bi-directional, then it can be encoded
as (1,2,1).


Hi Jakob,

The intent was that flooding be bi-directional on all links and thus (1,2) is 
sufficient to describe that link.

The reason for encoding things as paths is for the encoding efficiency.  
(1,2,3) is more efficient than (1,2) and (2,3).

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Flooding Path Direction

[Jakob Heitz (jheitz)]

The direction of the Flooding Path in draft-ietf-lsr-dynamic-flooding-00
is not clear.

I think it should be uni-directional, such that path (1,2) is different to
path (2,1). If the path (1,2) should be bi-directional, then it can be encoded
as (1,2,1).

Regards,
Jakob.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr