Re: [Lsr] Flooding Path Direction

[Peter Psenak <[e-mail]>]

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 <[e-mail]>; [e-mail]
> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>
> 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 <[e-mail]>
>> Sent: Thursday, April 04, 2019 1:53 PM
>> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
>> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak
>> (ppsenak) <[e-mail]>
>> 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) <[e-mail]>
>> Sent: Thursday, April 4, 2019 4:49 PM
>> To: David Allan I <[e-mail]>; [e-mail]
>> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak
>> (ppsenak) <[e-mail]>
>> 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 <[e-mail]> On Behalf Of David Allan I
>>> Sent: Thursday, April 04, 2019 1:14 PM
>>> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
>>> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter
>>> Psenak
>>> (ppsenak) <[e-mail]>
>>> 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) <[e-mail]>
>>> Sent: Thursday, April 4, 2019 1:44 PM
>>> To: [e-mail]; David Allan I <[e-mail]>
>>> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter
>>> Psenak
>>> (ppsenak) <[e-mail]>
>>> 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 <[e-mail]> On Behalf Of [e-mail]
>>>> Sent: Thursday, April 04, 2019 10:04 AM
>>>> To: David Allan I <[e-mail]>
>>>> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter
>>>> Psenak
>>>> (ppsenak) <[e-mail]>
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lsr
> .
>