Re: [Lsr] Flooding Path Direction

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

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 <[e-mail]>
> Sent: Thursday, April 04, 2019 1:53 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:
> 
> 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) <[e-mail]>
> Sent: Thursday, April 4, 2019 4:49 PM
> To: David Allan I <[e-mail]>; [e-mail]
> Cc: [e-mail]; Jakob Heitz (jheitz) <[e-mail]>; Peter Psenak
> (ppsenak) <[e-mail]>
> 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 <[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