Scott,
please see inline (##PP3)
On 01/06/2020 12:46, Scott O. Bradner wrote:
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?
##PP3
ok
<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
##PP3
ok, I will modify the text
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
##PP3
Would the below be sufficient?
14. IANA Considerations
This specifications updates two existing registries:
- OSPFv2 Extended Link TLV Sub-TLVs Registry
- OSPFv3 Extended LSA Sub-TLV Registry
New values are allocated using the IETF Review procedure as described
in [RFC5226].
thanks,
Peter
Scott
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
