On 05/04/2019 01:56 , Jakob Heitz (jheitz) wrote:
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.
You should process a flood received on any interface. Well, as long
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
Regards,
Jakob.
-----Original Message-----
From: Les Ginsberg (ginsberg)
Sent: Thursday, April 4, 2019 3:44 PM
To: David Allan I <[email protected]>; [email protected]
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak (ppsenak)
<[email protected]>
Subject: RE: [Lsr] Flooding Path Direction
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
-----Original Message-----
From: David Allan I <[email protected]>
Sent: Thursday, April 04, 2019 1:53 PM
To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak
(ppsenak) <[email protected]>
Subject: RE: [Lsr] Flooding Path Direction
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 protected]>
Sent: Thursday, April 4, 2019 4:49 PM
To: David Allan I <[email protected]>; [email protected]
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak
(ppsenak) <[email protected]>
Subject: RE: [Lsr] Flooding Path Direction
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
-----Original Message-----
From: Lsr <[email protected]> On Behalf Of David Allan I
Sent: Thursday, April 04, 2019 1:14 PM
To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
Psenak
(ppsenak) <[email protected]>
Subject: Re: [Lsr] Flooding Path Direction
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 protected]>
Sent: Thursday, April 4, 2019 1:44 PM
To: [email protected]; David Allan I <[email protected]>
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
Psenak
(ppsenak) <[email protected]>
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
-----Original Message-----
From: Lsr <[email protected]> On Behalf Of [email protected]
Sent: Thursday, April 04, 2019 10:04 AM
To: David Allan I <[email protected]>
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
Psenak
(ppsenak) <[email protected]>
Subject: Re: [Lsr] Flooding Path Direction
Hi Dave,
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.
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....(?)
Or perhaps having a separate TLV for a unidirectional path would
suffice.
That would allow both paths to be encoded most optimally.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
