Re: [Lsr] Flooding Path Direction

["Acee Lindem (acee)" <[e-mail]>]

On 4/5/19, 9:29 AM, "Lsr on behalf of David Allan I" <[e-mail] on behalf of [e-mail]> wrote:

    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.

Right - these transients are just accepted and flooded on the FT (or union of prior/new FTs) as specified in the WG dynamic flooding draft. 

Thanks,
Acee

    
    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