Re: [Lsr] Flooding Path Direction

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]> On Behalf Of David Allan I
> Sent: Thursday, April 04, 2019 1:14 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak
> (ppsenak) <[e-mail]>
> 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) <[e-mail]>
> Sent: Thursday, April 4, 2019 1:44 PM
> To: [e-mail]; David Allan I <[e-mail]>
> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak
> (ppsenak) <[e-mail]>
> 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 <[e-mail]> On Behalf Of [e-mail]
> > Sent: Thursday, April 04, 2019 10:04 AM
> > To: David Allan I <[e-mail]>
> > Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter
> > Psenak
> > (ppsenak) <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr