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