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.al...@ericsson.com> > Sent: Thursday, April 04, 2019 1:53 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jhe...@cisco.com>; Peter Psenak > (ppsenak) <ppse...@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) <ginsb...@cisco.com> > Sent: Thursday, April 4, 2019 4:49 PM > To: David Allan I <david.i.al...@ericsson.com>; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jhe...@cisco.com>; Peter Psenak > (ppsenak) <ppse...@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-boun...@ietf.org> On Behalf Of David Allan I > > Sent: Thursday, April 04, 2019 1:14 PM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; tony...@tony.li > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jhe...@cisco.com>; Peter > > Psenak > > (ppsenak) <ppse...@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) <ginsb...@cisco.com> > > Sent: Thursday, April 4, 2019 1:44 PM > > To: tony...@tony.li; David Allan I <david.i.al...@ericsson.com> > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jhe...@cisco.com>; Peter > > Psenak > > (ppsenak) <ppse...@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-boun...@ietf.org> On Behalf Of tony...@tony.li > > > Sent: Thursday, April 04, 2019 10:04 AM > > > To: David Allan I <david.i.al...@ericsson.com> > > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jhe...@cisco.com>; Peter > > > Psenak > > > (ppsenak) <ppse...@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
