operational points to understand what support is in network duly noted and yes, yang is probably best angle for now to include the capability per tlv
however, some observations below ... On Tue, Nov 28, 2023 at 2:18 PM <bruno.decra...@orange.com> wrote: > Hi, > > > > This draft proposes advertisements which are out of spec from the point of > existing RFCs and implementations. > > Enabling one router to send such advertisement while not all routers are > upgraded to support this extension will harm the network, potentially very > significantly and likely by surprise. > > That point is not acceptable to me as some networks are critical (e.g., > carry emergency calls from both mobile and wireline access). So I believe > we need solutions to avoid this. > > > > A first easy solution, from the standpoint of this WG and vendors (rather > than operators), is to “delegate” this work to operators. This requires > operators to have the ability to control such advertisement. > > In my opinion, at minimum we need the following change: > > OLD: It is RECOMMENDED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable generation of > MP-TLVs. > > NEW: It is REQUIRED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable generation of > MP-TLVs. > overspecification of implementation AFAIS and since people will happily ship stuff without this that will work (i.e. advertise and accept by default always) I doubt there is much we will be able to do to enforce that. A protocol spec governs interoperability on the wire (and sometimes computation since it's distributed) and starting to describe knobs required is that if even belongs into an applicability statement. already the 'RECOMMENDED' is really applicability AFAIS. > > > I would also call for the following text > > NEW: By default, the sending of MP-TLV for the TLVs extended by this > document SHOULD be disabled. > This will not happen since a benign upgrade of software in today's network along those lines will immediately break stuff since e.g. adjacency will all of a sudden not be advertised as is already done today. Or in other words this tries to declare all the de-facto planet-wide deployed major large scale implementations non-compliant. Our job is first, like doctors, not to harm and this will harm and second, we have to drag existing stuff along without flag days and reality will not bend to some unrealistic text in an ASCII document. And no, trying to "change configuration during update" in a benign way can 1) cause massive problems in real deployments IME and is to be avoided and 2) if we add to config "enable" during upgrade we basically defeat the purpose of this sentence having added tons complexity and achieving nothing of note. As sidenote: we have a somewhat similar case where we were forced to change BGP default (BGP no policy not accepting) the repercussions were very serious though far less than breaking IGP in a network (since the impact was local for a node) and the pressure the operators were under (classical misconfig/overrun of router with clean config) was also far more serious than this case here. > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
