Re: [Lsr] Flooding Path Direction

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:
> 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 <david.i.allan@ericsson.com>; tony.li@tony.li
>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter
>> Psenak (ppsenak) <ppsenak@cisco.com>
>> 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 <david.i.allan@ericsson.com>
>>> Sent: Thursday, April 04, 2019 1:53 PM
>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; tony.li@tony.li
>>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter Psenak
>>> (ppsenak) <ppsenak@cisco.com>
>>> 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) <ginsberg@cisco.com>
>>> Sent: Thursday, April 4, 2019 4:49 PM
>>> To: David Allan I <david.i.allan@ericsson.com>; tony.li@tony.li
>>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter Psenak
>>> (ppsenak) <ppsenak@cisco.com>
>>> 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 <lsr-bounces@ietf.org> On Behalf Of David Allan I
>>>> Sent: Thursday, April 04, 2019 1:14 PM
>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; tony.li@tony.li
>>>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter
>>>> Psenak
>>>> (ppsenak) <ppsenak@cisco.com>
>>>> 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) <ginsberg@cisco.com>
>>>> Sent: Thursday, April 4, 2019 1:44 PM
>>>> To: tony.li@tony.li; David Allan I <david.i.allan@ericsson.com>
>>>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter
>>>> Psenak
>>>> (ppsenak) <ppsenak@cisco.com>
>>>> 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 <lsr-bounces@ietf.org> On Behalf Of tony.li@tony.li
>>>>> Sent: Thursday, April 04, 2019 10:04 AM
>>>>> To: David Allan I <david.i.allan@ericsson.com>
>>>>> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter
>>>>> Psenak
>>>>> (ppsenak) <ppsenak@cisco.com>
>>>>> 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
>>>>> Lsr@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lsr
>> .
>>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> .
>