Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Peter Psenak <[e-mail]>]

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 <[e-mail]> 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
>