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
