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
