[Lsr] IETF 104 LSR Meeting Minutes
Hi All, I’ve posted the meeting minutes from the IETF LSR meetings in Prague: https://datatracker.ietf.org/doc/minutes-104-lsr/ Please let me know if you have any question or there is anything that needs to be corrected. Thanks, Yingzhen ___ rtgwg mailing list rt...@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
On 2019-04-02 12:08, tom petch wrote: - Original Message - From: "Mikael Abrahamsson" Sent: Sunday, March 31, 2019 8:07 AM On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: Additionally, I agree with Yingzhen's comment that it is not clear that we want a separate YANG module for every OSPF/IS-IS feature. As an operator, I expect to manage my routers using YANG modules. Thus, every feature that is introduced that would provide requirement for management and/or provide operational data needs to have an YANG module come with it, otherwise this new feature isn't useful. I don't want YANG to be second class citizen compared to CLI the way SNMP has been. I also want to avoid having vendor-specific YANG modules if possible. Thus it makes sense to require YANG module with every new work. If this is in the same document or an accompanying document is not of importance to me, as long as it gets the YANG module shows up in roughly the same timeframe as the feature. Mikael Do you have any concern about the number of modules involved i.e. in the practical management on Internet routers, does it matter whether the management comes in the form of 100 or 1000 or ... modules? I don't have any real concerns about that. From a technical perspective I have a hard time seeing this being an issue. From a softer point of view, it might be difficult for a human to overlook many models but similarly it is difficult to overlook very large models (and in particular ones with many features). Thus far I think the models that have been published and the ones that are being worked on, usually have a rather reasonable scope, quite often they encompass a piece of technology. Since we do have a great number of different technologies it does mean quite a few models but it isn't conceptually harder for a human to overlook since the technologies are already there. I have a nagging concern, based on experience with older technologies, that difficulties can arise, and that they are not linear with the number of modules. Is management with YANG more difficult if you have 1000 arbitrary prefixes (or module names or module revision dates) floating around or do the tools hide such details and present a coherent picture to an operator? We have devices today that have in excess of 300 models and I don't really think it affects the way they are being managed versus a device that has one model. Working with multiple revisions could perhaps be challenging. Most of the time I find that we look at a given device type and the models it supports, which will be one given revision of a model and thus we can ignore all else at that point in time. Likewise, does it matter how many features there are, with a Cartesian explosion leading to a five or six digit number of combinations? I don't think the combination means much at all. We try not to deal with features in that way but rather individually which then avoids the combinatorial effect. If anything, my concern would be, not as an operator that would operate a network but rather as a YANG model writer that writing a huge model with a very large number of features probably means I'll never finish writing the model and it will likely become unwieldy. Better to split it up into multiple models using augmentations. Kind regards, Kristian. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flooding Path Direction
On 4/5/19, 9:29 AM, "Lsr on behalf of David Allan I" 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 On Behalf Of Les Ginsberg (ginsberg) Sent: Thursday, April 4, 2019 6:44 PM To: David Allan I ; tony...@tony.li Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter Psenak (ppsenak) 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 > Sent: Thursday, April 04, 2019 1:53 PM > To: Les Ginsberg (ginsberg) ; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > Psenak > (ppsenak) > 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) > Sent: Thursday, April 4, 2019 4:49 PM > To: David Allan I ; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > Psenak > (ppsenak) > 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 On Behalf Of David Allan I > > Sent: Thursday, April 04, 2019 1:14 PM > > To: Les Ginsberg (ginsberg) ; tony...@tony.li > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > Psenak > > (ppsenak) > > 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) > > Sent: Thursday, April 4, 2019 1:44 PM > > To: tony...@tony.li; David Allan I > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > Psenak > > (ppsenak) > > 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 On Behalf Of tony...@tony.li > > > Sent: Thursday, April 04, 2019 10:04 AM > > > To: David Allan I > > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > > Psenak > > > (ppsenak) > > > 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 > > >
Re: [Lsr] Flooding Path Direction
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 On Behalf Of Les Ginsberg (ginsberg) Sent: Thursday, April 4, 2019 6:44 PM To: David Allan I ; tony...@tony.li Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter Psenak (ppsenak) 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 > Sent: Thursday, April 04, 2019 1:53 PM > To: Les Ginsberg (ginsberg) ; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > Psenak > (ppsenak) > 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) > Sent: Thursday, April 4, 2019 4:49 PM > To: David Allan I ; tony...@tony.li > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > Psenak > (ppsenak) > 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 On Behalf Of David Allan I > > Sent: Thursday, April 04, 2019 1:14 PM > > To: Les Ginsberg (ginsberg) ; tony...@tony.li > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > Psenak > > (ppsenak) > > 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) > > Sent: Thursday, April 4, 2019 1:44 PM > > To: tony...@tony.li; David Allan I > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > Psenak > > (ppsenak) > > 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 On Behalf Of tony...@tony.li > > > Sent: Thursday, April 04, 2019 10:04 AM > > > To: David Allan I > > > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter > > > Psenak > > > (ppsenak) > > > 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 > > > Lsr@ietf.org > > >
