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 <[email protected]> On Behalf Of David Allan I > Sent: Thursday, April 04, 2019 1:14 PM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak > (ppsenak) <[email protected]> > 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) <[email protected]> > Sent: Thursday, April 4, 2019 1:44 PM > To: [email protected]; David Allan I <[email protected]> > Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak > (ppsenak) <[email protected]> > 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 <[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
