Re: [Lsr] Flooding Path Direction

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

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