thanks for the reply - see in line
> On May 28, 2020, at 10:09 AM, Peter Psenak > <ppsenak=40cisco....@dmarc.ietf.org> wrote: > > Hi Scott, > > please see inline (##PP): > > On 27/05/2020 17:17, Scott Bradner via Datatracker wrote: >> Reviewer: Scott Bradner >> Review result: Not Ready >> This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse >> (draft-ietf-ospf-te-link-attr-reuse) >> This ID describes application-specific attribute advertisements for use in >> OSPF. >> I found this ID hard to read and recommend that it be reviewed for >> readability. >> I have a basic question about this proposal – the ID describes specific >> advertisements to be used when particular applications want to make use of >> specific link attributes and says that other applications should not make of >> the information in the advertisement without saying why such use would be a >> problem. I can imagine some reasons but it seems to me that it would be good >> if this document just explained the problem it is trying to solve. > > ##PP > > There are two problems mentioned in the Introduction section: > > 1) Ambiguity in terms of which of the advertisements are to be used by > RSVP-TE and which ones should not be. When RSVP was the only application > using these attributes, advertisement of these attributes meant that RSVP was > enabled on the link. Such link was considered as a part of the RSVP-TE > topology. With other applications using and advertising these link > attributes, this logic can not be used anymore, which created the mentioned > ambiguity. > > 2) Lack of support for application specific values for the link attribute. > > I thought this was clear, but if it is not, please suggest what else needs to > be said. yes - I saw that but I missed seeing why these are a problem - what harm can come form specifically the first one? I fully expect there are real problems but I think it would be useful to say what they are <snip> > >> Page 7 – a “User Defined Application Identifier” is introduced but never >> described – what uses it and what is it used for > ##PP > we provide a way for the user to advertise link attributes for the purpose of > something that is not defined as standardized application. What such > application might be is not subject to the specification. can that just be said? > >> Section 11 – I found this discussion of the relationship between the >> existence >> of a particular advertisement and the possible existence of an application to >> use that advertisement to be quite confusing – if the existence of a >> particular >> advertisement does not indicate that any application is listening why not >> just >> say that? > > ##PP > there are applications where the application enablement on the link is > relevant - e.g. RSVP-TE - one need to make sure that RSVP is enabled on the > link before sending a RSVP signaling message over it. > > There are applications, where the enablement of the application on the link > is irrelevant and has nothing to do with the fact that some link attributes > are advertised for the purpose of such application - e.g. LFA. > > We have provided full flexibility to support both. I think it would help to say that in the ID <snip> > >> Section 12.3.3 – I could not tell if this section is saying that the >> application specific attribute advertisements could not be used if there is >> even a single legacy router present of if the presence of such a router means >> that the application specific attribute advertisements can be used but the >> old >> advertisements must also be used > > ##PP > a) as long as there is a single legacy router present, all routers MUST > continue to advertise link attributes using legacy advertisements to allow > the legacy router to function properly. > > b) new advertisements can be used in parallel and they can be used by the > routers that do understand them. > > The text in 12.3.3 says: > > "Send application specific advertisements while continuing to > advertise using legacy (all advertisements are then duplicated)." I found it confusing - can you say what you said here? > > >> Section 14 – it might help to say how new Sub-TLV types can be added to the >> registry > > ##PP > we are not defining a nynew registry, we only use existing ones. These > registries have their own registration procedures. I did not see a clear statement that said that was what you are doing or a clear pointer to where someone should go if they wanted to add a new value Scott > > thanks, > Peter > > > > > > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
