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

"Scott O. Bradner" <sob@sobco.com> Mon, 01 June 2020 10:46 UTC

Return-Path: <sob@sobco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D403A0F2E; Mon, 1 Jun 2020 03:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGDZLXwdONxd; Mon, 1 Jun 2020 03:46:50 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 8773B3A0F2C; Mon, 1 Jun 2020 03:46:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 79651377D3C4; Mon, 1 Jun 2020 06:46:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnCulCJhIqgQ; Mon, 1 Jun 2020 06:46:42 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 9435C377D3B2; Mon, 1 Jun 2020 06:46:41 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <baa6b173-9ef5-4e3f-1209-476db590417a@cisco.com>
Date: Mon, 1 Jun 2020 06:46:41 -0400
Cc: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, ops-dir@ietf.org, draft-ietf-ospf-te-link-attr-reuse.all@ietf.org, last-call@ietf.org, lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <45A0E77D-3106-4E6A-B4BD-C62F8A5189E2@sobco.com>
References: <159059262542.19823.6779966735787003447@ietfa.amsl.com> <ccd640cd-22f0-3909-2fc0-b83dd35d13b5@cisco.com> <2B71E88E-3B42-4490-8EF5-6477F9C87DD9@sobco.com> <baa6b173-9ef5-4e3f-1209-476db590417a@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/lwl3wSg572Hpq-Dm5uOitErmofg>
Subject: Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2020 10:46:52 -0000

inline

> On Jun 1, 2020, at 5:54 AM, Peter Psenak <ppsenak@cisco.com> 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