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

Peter Psenak <> Mon, 01 June 2020 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 038203A0F4D; Mon, 1 Jun 2020 04:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id boPmF2oyctXz; Mon, 1 Jun 2020 04:07:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 838543A0F4A; Mon, 1 Jun 2020 04:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3493; q=dns/txt; s=iport; t=1591009667; x=1592219267; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PHQZfOaMT/bNW+jmMACynLWTCohJkf/uGK4gOWzbDms=; b=KYDEJw01uaMr/8/h1QevQHw5wo85dk2h9smtk26bRvQ9qbLus4p38nrR WqwEmz29tdNL10NEJ7TydLxbD2I1a+Ux/6Ecb1kJ7LDpiDxvZlTlCuzSD mZh/P2DWbVKXzT3Nk+Bpd1FhD9lqa24CDyOw6T5F7V1QpQ1gBt0ilP4Kh 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,460,1583193600"; d="scan'208";a="26690709"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 11:07:42 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id 051B7fPQ011923; Mon, 1 Jun 2020 11:07:42 GMT
To: "Scott O. Bradner" <>
Cc: Peter Psenak <>,,,,
References: <> <> <> <> <>
From: Peter Psenak <>
Message-ID: <>
Date: Mon, 1 Jun 2020 13:07:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jun 2020 11:07:49 -0000


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 <> 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

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

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].

> Scott