On 4/5/19, 9:29 AM, "Lsr on behalf of David Allan I" <[email protected] on
behalf of [email protected]> 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, April 4, 2019 6:44 PM
To: David Allan I <[email protected]>; [email protected]
Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter Psenak
(ppsenak) <[email protected]>
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 <[email protected]>
> Sent: Thursday, April 04, 2019 1:53 PM
> To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
> Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
> Psenak
> (ppsenak) <[email protected]>
> 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) <[email protected]>
> Sent: Thursday, April 4, 2019 4:49 PM
> To: David Allan I <[email protected]>; [email protected]
> Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
> Psenak
> (ppsenak) <[email protected]>
> 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 <[email protected]> On Behalf Of David Allan I
> > Sent: Thursday, April 04, 2019 1:14 PM
> > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]
> > Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
> > Psenak
> > (ppsenak) <[email protected]>
> > 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) <[email protected]>
> > Sent: Thursday, April 4, 2019 1:44 PM
> > To: [email protected]; David Allan I <[email protected]>
> > Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
> > Psenak
> > (ppsenak) <[email protected]>
> > 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 <[email protected]> On Behalf Of [email protected]
> > > Sent: Thursday, April 04, 2019 10:04 AM
> > > To: David Allan I <[email protected]>
> > > Cc: [email protected]; Jakob Heitz (jheitz) <[email protected]>; Peter
> > > Psenak
> > > (ppsenak) <[email protected]>
> > > 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
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
