Re: [Lsr] Flooding Path Direction

[David Allan I <[e-mail]>]

HI les

I also find it undesirable to enforce unidirectionality. Receiving an LSP on
an unexpected interface should be treated as an artifact of a loss of
synchronization IMO.

Thanks
Dave

-----Original Message-----
From: Lsr <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, April 4, 2019 6:44 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 -

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

_______________________________________________
Lsr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr