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

Peter Psenak <ppsenak@cisco.com> Mon, 01 June 2020 09:54 UTC

Return-Path: <ppsenak@cisco.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 033AC3A0ED0; Mon, 1 Jun 2020 02:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 g2Koy51-5FKM; Mon, 1 Jun 2020 02:54:20 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EB93A0ECE; Mon, 1 Jun 2020 02:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6148; q=dns/txt; s=iport; t=1591005260; x=1592214860; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lE3Q73NqmuRZDopdKWqUvkYePwNE2BnvSl0cDauBH84=; b=fFw786uKO/eBKZ2I7CgvGU17Tgkbj3Wy/OgKuhPEywkRzY2QIb0h/f0i ClbQ0SJTPdgvgSTHoM4LAd45AkHp1gupwQYCKOq5UhlOkakx3wAozEc8c FiwMj23Dhuxonv/Q7OaypRBt3w50LvdwLZQYyNjv+9yuXriTshYgpwNYV 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AAAZz9Re/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgTkBAQEBAQELAYFygSVQBAEgEiy?= =?us-ascii?q?EJYkBh2Ulm3YLAQEBDhgLDAQBAYREAoIlJTcGDgIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FWQyFcgEBAQECAQEBIQ8BBTYEBxALGAICJgICJzAGAQwGAgEBFYMNAYJcIA+?= =?us-ascii?q?sdnaBMoVRgzuBOgaBDioBjGCBQT+BEAEnDIIvLj6CZwEBAoR3gmAEs0+CYYJ?= =?us-ascii?q?6lW4HHoJmiQeEaCeNHJBfniKBaSOBVjMaCBsVO4JpUBkNkEwXFYhOhUQ/AzA?= =?us-ascii?q?CNQIGAQcBAQMJjW8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,460,1583193600"; d="scan'208";a="26627331"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 09:54:15 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 0519sE5e027779; Mon, 1 Jun 2020 09:54:14 GMT
To: "Scott O. Bradner" <sob@sobco.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
Cc: ops-dir@ietf.org, draft-ietf-ospf-te-link-attr-reuse.all@ietf.org, last-call@ietf.org, lsr@ietf.org
References: <159059262542.19823.6779966735787003447@ietfa.amsl.com> <ccd640cd-22f0-3909-2fc0-b83dd35d13b5@cisco.com> <2B71E88E-3B42-4490-8EF5-6477F9C87DD9@sobco.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <baa6b173-9ef5-4e3f-1209-476db590417a@cisco.com>
Date: Mon, 1 Jun 2020 11:54:14 +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: <2B71E88E-3B42-4490-8EF5-6477F9C87DD9@sobco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/kkgDt-xxVzXT0AHK5kdX-RTL7Cs>
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 09:54:22 -0000

Scott,

please see inline (##PP2)

On 30/05/2020 20:38, Scott O. Bradner wrote:
> thanks for the reply - see in line
> 
> 
>> On May 28, 2020, at 10:09 AM, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> wrote:
>>
>> Hi Scott,
>>
>> please see inline (##PP):
>>
>> On 27/05/2020 17:17, Scott Bradner via Datatracker wrote:
>>> Reviewer: Scott Bradner
>>> Review result: Not Ready
>>> This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse
>>> (draft-ietf-ospf-te-link-attr-reuse)
>>> This ID describes application-specific attribute advertisements for use in OSPF.
>>> I found this ID hard to read and recommend that it be reviewed for readability.
>>> I have a basic question about this proposal – the ID describes specific
>>> advertisements to be used when particular applications want to make use of
>>> specific link attributes and says that other applications should not make of
>>> the information in the advertisement without saying why such use would be a
>>> problem.  I can imagine some reasons but it seems to me that it would be good
>>> if this document just explained the problem it is trying to solve.
>>
>> ##PP
>>
>> There are two problems mentioned in the Introduction section:
>>
>> 1) Ambiguity in terms of which of the advertisements are to be used by RSVP-TE and which ones should not be. When RSVP was the only application using these attributes, advertisement of these attributes meant that RSVP was enabled on the link. Such link was considered as a part of the RSVP-TE topology. With other applications using and advertising these link attributes, this logic can not be used anymore, which created the mentioned ambiguity.
>>
>> 2) Lack of support for application specific values for the link attribute.
>>
>> I thought this was clear, but if it is not, please suggest what else needs to be said.
> 
> yes - I saw that but I missed seeing why these are a  problem - what harm can come form specifically the first one?
> I fully expect there are real problems but I think it would be useful to say what they are

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


> 
> <snip>
> 
>>
>>> Page 7 – a “User Defined Application Identifier” is introduced but never
>>> described – what uses it and what is it used for
>> ##PP
>> we provide a way for the user to advertise link attributes for the purpose of something that is not defined as standardized application. What such application might be is not subject to the specification.
> 
> can that just be said?

##PP2
sure

> 
>>
>>> Section 11 – I found this discussion of the relationship between the existence
>>> of a particular advertisement and the possible existence of an application to
>>> use that advertisement to be quite confusing – if the existence of a particular
>>> advertisement does not indicate that any application is listening why not just
>>> say that?
>>
>> ##PP
>> there are applications where the application enablement on the link is relevant - e.g. RSVP-TE - one need to make sure that RSVP is enabled on the link before sending a RSVP signaling message over it.
>>
>> There are applications, where the enablement of the application on the link is irrelevant and has nothing to do with the fact that some link attributes are advertised for the purpose of such application - e.g. LFA.
>>
>> We have provided full flexibility to support both.
> 
> I think it would help to say that in the ID


##PP2
sure

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

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

thanks,
Peter



> 
> Scott
> 
>>
>> thanks,
>> Peter
>>
>>
>>
>>
>>
>>
>> -- 
>> last-call mailing list
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
> 
> 
>