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) <[email protected]> Sent: Thursday, April 4, 2019 4:49 PM To: David Allan I <[email protected]>; [email protected] Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak (ppsenak) <[email protected]> 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 <[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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
