inline > On Jun 1, 2020, at 5:54 AM, Peter Psenak <ppsenak@xxxxxxxxx> wrote: > <snip> > > ##PP2 > > It's the ambiguity that causes the problem. Here's a real life example which triggered some of this work: > > A network has RSVP-TE enabled on one subset of links, and SRTE on some other subset. On a link where RSVP TE is not enabled I want to advertise a link attribute for the purpose of some other app - let's say SRTE. As soon as the router that is a RSVP-TE head-end sees the link attribute being advertised for a link, it assumes RSVP is enabled on a link, even though in reality RSVP TE is not enabled on the link. If such head-end router tries to setup the RSVP TE path via link where RSVP-TE is not enabled it will fail. > > I thought it was clear from the existing text, but if you believe it needs to be improved, please feel free to suggest the improved text. why not add what you just sent to me? <snip? > >> <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? > > ##PP2 > send both new and old advertisement as soon as there is least one legacy router that does not understand the new advertisement. that would be a good addition > >>> >>> >>>> 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 > > ##PP2 > sorry, I must be missing something. > We are adding new code points to the existing registries. Why do we need to specify how to add a new value to these registries here? I do not think that is what I suggested - I did not find it clear that you were adding points to an existing registry so I think that should be made clearer including a pointer to the instructions for adding values to that existing registry Scott -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
