Subject: [Lsr] Flooding Path Direction

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 4 Apr 2019 03:19:47 +0000

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.

---

From: [email-masked]
Date: Wed, 3 Apr 2019 22:10:04 -0700

> path (2,1). If the path (1,2) should be bi-directional, then it can be encoded

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 4 Apr 2019 05:52:21 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 3, 2019 10:10 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flooding Path Direction

Hi Jakob,

Regards,
Tony

---

From: [email-masked]
Date: Wed, 3 Apr 2019 23:19:13 -0700

> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 4 Apr 2019 06:26:01 +0000

I mean flooding in one direction only, not unidirectional forwarding.

Regards,
Jakob.

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 3, 2019 11:19 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Flooding Path Direction

Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 4 Apr 2019 09:27:46 +0200

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:
> *From:* Tony Li <[email-masked]> *On Behalf Of [email-masked]
> *Sent:* Wednesday, April 3, 2019 11:19 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Flooding Path Direction
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 4 Apr 2019 08:55:57 +0000

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 <[email-masked]> 
Sent: Thursday, April 4, 2019 12:28 AM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Flooding Path Direction

Jakob,

thanks,
Peter

On 04/04/2019 08:26 , Jakob Heitz (jheitz) wrote:
> Well, right now, the protocol doesn't really support unidirectional
> links. At all.
>
>
>
> Tony
>
>
>
>
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 4 Apr 2019 12:19:07 +0200

Jakob,

> How is it impossible that A may flood to B, but B does not flood to A ?

every node in the area must be able to flood the data and they must 
reach all other nodes.

Adjacency bringup involves database exchange which is bidirectional, so 
is the flooding. Flooding in one direction often serves as an ACK from 
the other direction.

> How does it follow that if A floods to B, then B must also flood to A ?

does not have to be, but the LS protocols have been designed for 
bidirectional flooding. Making this unidirectional would require 
significant changes to the flooding procedures. Not something we want to 
go into.

> Suppose you had to build a flooding topology with the rule: 2 incoming and 2 outgoing floods.

why 2 incoming and 2 outgoing? We want each node to do minimal flooding, 
which is 2 connections to flooding topology, not 4.

regards,
Peter

> .

---

From: David Allan I <[email-masked]>
Date: Thu, 4 Apr 2019 16:39:20 +0000

Hi Gents:

The algorithm in draft-allan actually has the notion of upstream, downstream
and both upstream and downstream FT adjacencies. However as a generalized
form is still a WIP and has yet to demonstrate merit against any of the
other approaches on the table, I'd not be looking to suggest a specific
encoding. 

If at some point it is decided that different classes of FT adjacency are
required, simply using additional types that share the format of the
flooding path TLV would appear to be sufficient....(?)

Cheers
Dave

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Thursday, April 4, 2019 6:19 AM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Flooding Path Direction

Jakob,

> How is it impossible that A may flood to B, but B does not flood to A ?

every node in the area must be able to flood the data and they must reach
all other nodes.

Adjacency bringup involves database exchange which is bidirectional, so is
the flooding. Flooding in one direction often serves as an ACK from the
other direction.

does not have to be, but the LS protocols have been designed for
bidirectional flooding. Making this unidirectional would require significant
changes to the flooding procedures. Not something we want to go into.

regards,
Peter

> With bidirectional flooding, the incoming are the same as the 
> outgoing, so any incoming flood can only be propagated on one interface.
> given that there is a single flooding topology calculated for an area, 
> I don't see how this can be unidirectional, considering that flooding

---

From: [email-masked]
Date: Thu, 4 Apr 2019 10:04:26 -0700

Hi Dave,

> other approaches on the table, I'd not be looking to suggest a specific

Thanks.

> flooding path TLV would appear to be sufficient....(?)

Or perhaps having a separate TLV for a unidirectional path would suffice.

That would allow both paths to be encoded most optimally.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Apr 2019 17:43:52 +0000

But the point that Peter has made needs to be heeded.
Changing IGP flooding to be unidirectional is non-trivial and should not be done w/o justification.

One of the things the FT draft has been very careful about thus far is to not change the operation of the Update process on a given link.
We allow links to be excluded from the FT but we do not change flooding behavior on a link when it is part of the FT.
We have also gone so far as to indicate that even if a link is NOT part of the FT but we do receive an LSP on that link we acknowledge it in the standard fashion.

I think all of this simplifies the deployment of the feature and we should be careful before introducing additional changes in standard protocol behavior.

   Les

> From: Lsr <[email-masked]> On Behalf Of [email-masked]
> Sent: Thursday, April 04, 2019 10:04 AM
> To: David Allan I <[email-masked]>
> Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak
> (ppsenak) <[email-masked]>

---

From: David Allan I <[email-masked]>
Date: Thu, 4 Apr 2019 20:14:27 +0000

HI Les:

Actually it should not be that bad. Once you are restricting the set of
interfaces you would send an LSP on, you've already crossed the Rubicon.

At least that is the view from here...

Dave

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Thursday, April 4, 2019 1:44 PM
To: [email-masked]; David Allan I <[email-masked]>
Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak
(ppsenak) <[email-masked]>
Subject: RE: [Lsr] Flooding Path Direction

But the point that Peter has made needs to be heeded.
Changing IGP flooding to be unidirectional is non-trivial and should not be
done w/o justification.

One of the things the FT draft has been very careful about thus far is to
not change the operation of the Update process on a given link.
We allow links to be excluded from the FT but we do not change flooding
behavior on a link when it is part of the FT.
We have also gone so far as to indicate that even if a link is NOT part of
the FT but we do receive an LSP on that link we acknowledge it in the
standard fashion.

I think all of this simplifies the deployment of the feature and we should
be careful before introducing additional changes in standard protocol
behavior.

   Les

> > form is still a WIP and has yet to demonstrate merit against any of 
> > the other approaches on the table, I'd not be looking to suggest a 
> > specific encoding.
> 
> 
> Thanks.
> 
> 
> > If at some point it is decided that different classes of FT 
> > adjacency are required, simply using additional types that share the 
> > format of the flooding path TLV would appear to be sufficient....(?)
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Apr 2019 20:49:05 +0000

Dave -

Blocking flooding on a subset of the interfaces is easy to do.

Changing flooding to operate on a specific interface in a unidirectional manner is a much bigger ask.

   Les

> From: Lsr <[email-masked]> On Behalf Of David Allan I
> Sent: Thursday, April 04, 2019 1:14 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]

---

From: David Allan I <[email-masked]>
Date: Thu, 4 Apr 2019 20:52:56 +0000

HI Les:

Then I assume there is a subtlety around this I am missing,  I assumed this
was purely a sender selectable behavior (e.g. if new send on this set
excluding that of arrival), and had no other ramifications. The non-overlap
of specific sets at either end of an adjacency determined the directionality
of the FT usage of a given link.

Dave

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Thursday, April 4, 2019 4:49 PM
To: David Allan I <[email-masked]>; [email-masked]
Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak

Dave -

Changing flooding to operate on a specific interface in a unidirectional
manner is a much bigger ask.

   Les

> Actually it should not be that bad. Once you are restricting the set 
> of interfaces you would send an LSP on, you've already crossed the
Rubicon.
> One of the things the FT draft has been very careful about thus far is 
> to not change the operation of the Update process on a given link.
> We allow links to be excluded from the FT but we do not change 
> flooding behavior on a link when it is part of the FT.
> We have also gone so far as to indicate that even if a link is NOT 
> part of the FT but we do receive an LSP on that link we acknowledge it 
> in the standard fashion.
> 
> I think all of this simplifies the deployment of the feature and we 
> should be careful before introducing additional changes in standard 
> protocol behavior.
> 
>    Les
> 
> 
> > > form is still a WIP and has yet to demonstrate merit against any 
> > > of the other approaches on the table, I'd not be looking to 
> > > suggest a specific encoding.
> >
> >
> > Thanks.
> >
> >
> > > adjacency are required, simply using additional types that share 
> > > the format of the flooding path TLV would appear to be 
> > > sufficient....(?)
> >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Apr 2019 22:43:35 +0000

Dave -

IGP flooding on a link is by specification bidirectional.
It is OK if A arbitrarily decides not to initiate flooding an LSP to neighbor B, but the meaning of unidirectional flooding implies that A is allowed to reject incoming LSPs if they are received from B. This would require implementation changes which I think are undesirable.

It isn't clear that there is a requirement to do so - and after private conversation with Jakob - it seems that is not what he intended. But it is that concept which Peter and I (at least) are finding undesirable.

HTH

   Les

> From: David Allan I <[email-masked]>
> Sent: Thursday, April 04, 2019 1:53 PM

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 4 Apr 2019 16:05:13 -0700

+1 Les

Cheers,
Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 4 Apr 2019 23:56:02 +0000

Yes. What I meant was that the FT specifies which interfaces to send a flood on.
You should process a flood received on any interface. Well, as long
as it comes from an interface that is part of the domain.

Regards,
Jakob.

-----Original Message-----
From: Les Ginsberg (ginsberg) 
Sent: Thursday, April 4, 2019 3:44 PM
To: David Allan I <[email-masked]>; [email-masked]
Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: RE: [Lsr] Flooding Path Direction

Dave -

HTH

   Les

---

From: Peter Psenak <[email-masked]>
Date: Fri, 5 Apr 2019 09:28:55 +0200

> Yes. What I meant was that the FT specifies which interfaces to send a flood on.

that is exactly what the FT does at the end.

> as it comes from an interface that is part of the domain.

yes, that is what the FT draft says.

So maybe there is an misunderstanding of what you meant by unidirectional.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 5 Apr 2019 09:59:56 +0200

Jakob,

FT as the draft defines it assumes that if the link is part of the FT, 
it is used by both ends to flood. So on a link A-B, if the link is part 
of the FT it is used by both A and B to flood.

If you want to flood only A->B and not B->A, existing draft allows that, 
as it says that any LSP received on a link that is not part of the FT is 
flooded on all links on the FT. In a centralized mode, the encoding of 
the FT would have to be extended to support unidirectional flooding. For 
distributed mode, no changes are required IMHO.

thanks,
Peter

On 05/04/2019 09:28 , Peter Psenak wrote:
>> It is OK if A arbitrarily decides not to initiate flooding an LSP to
>> neighbor B, but the meaning of unidirectional flooding implies that A
>> is allowed to reject incoming LSPs if they are received from B. This
>> would require implementation changes which I think are undesirable.
>>
>> It isn't clear that there is a requirement to do so - and after
>> private conversation with Jakob - it seems that is not what he
>> intended. But it is that concept which Peter and I (at least) are
>> finding undesirable.
>>
>> HTH
>>
>>    Les
>>

---

From: David Allan I <[email-masked]>
Date: Fri, 5 Apr 2019 13:28:56 +0000

HI les

I also find it undesirable to enforce unidirectionality. Receiving an LSP on
an unexpected interface should be treated as an artifact of a loss of
synchronization IMO.

Thanks
Dave

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, April 4, 2019 6:44 PM
To: David Allan I <[email-masked]>; [email-masked]
Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak

Dave -

IGP flooding on a link is by specification bidirectional.
It is OK if A arbitrarily decides not to initiate flooding an LSP to
neighbor B, but the meaning of unidirectional flooding implies that A is
allowed to reject incoming LSPs if they are received from B. This would
require implementation changes which I think are undesirable.

It isn't clear that there is a requirement to do so - and after private
conversation with Jakob - it seems that is not what he intended. But it is
that concept which Peter and I (at least) are finding undesirable.

HTH

   Les

> Then I assume there is a subtlety around this I am missing,  I assumed 
> this was purely a sender selectable behavior (e.g. if new send on this 
> set excluding that of arrival), and had no other ramifications. The 
> non-overlap of specific sets at either end of an adjacency determined 
> the directionality of the FT usage of a given link.
> 
> Dave
> 
> Changing flooding to operate on a specific interface in a 
> unidirectional manner is a much bigger ask.
> 
>    Les
> 
> > One of the things the FT draft has been very careful about thus far 
> > is to not change the operation of the Update process on a given link.
> > part of the FT but we do receive an LSP on that link we acknowledge 
> > it in the standard fashion.
> >
> > > > The algorithm in draft-allan actually has the notion of 
> > > > upstream,
> > > downstream

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Apr 2019 13:45:15 +0000

On 4/5/19, 9:29 AM, "Lsr on behalf of David Allan I" <[email-masked] on behalf of [email-masked]> wrote:

    HI les

Right - these transients are just accepted and flooded on the FT (or union of prior/new FTs) as specified in the WG dynamic flooding draft. 

Thanks,
Acee

    Thanks
    Dave
    
    -----Original Message-----
    From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
    Sent: Thursday, April 4, 2019 6:44 PM
    To: David Allan I <[email-masked]>; [email-masked]
    Cc: [email-masked]; Jakob Heitz (jheitz) <[email-masked]>; Peter Psenak
    (ppsenak) <[email-masked]>
    Subject: Re: [Lsr] Flooding Path Direction
    
    Dave -

    
    HTH
    
       Les