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 11:07 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 038203A0F4D; Mon, 1 Jun 2020 04:07:49 -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 boPmF2oyctXz; Mon, 1 Jun 2020 04:07:47 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838543A0F4A; Mon, 1 Jun 2020 04:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0AOAACB4NRe/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE4AwEBAQELAYFygXkBIBIshCWJAYgLmXq?= =?us-ascii?q?BfAsBAQEOLwQBAYREAoImJTYHDgIDAQELAQEFAQEBAgEGBG2FZYVzAQUjDwE?= =?us-ascii?q?FQRALGAICJgICVwYNBgIBARWDDYJ9rHx2gTKFUYM7gUCBDioBjGCBQT+BEAE?= =?us-ascii?q?ngjsuPodigmAEs0+CYYJ6lW4HHoJmiQeEaI1DrwGBWgoogVYzGggbFYMkUBk?= =?us-ascii?q?NkEwXFY4SPwMwNwIGAQcBAQMJjW8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,460,1583193600"; d="scan'208";a="26690709"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 11:07:42 +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 051B7fPQ011923; Mon, 1 Jun 2020 11:07:42 GMT
To: "Scott O. Bradner" <sob@sobco.com>
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
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> <45A0E77D-3106-4E6A-B4BD-C62F8A5189E2@sobco.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <b7e780e9-157b-0acc-a14c-6ad352ae095e@cisco.com>
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: <45A0E77D-3106-4E6A-B4BD-C62F8A5189E2@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/qmxyg0mv8XztkJqXhGqdp0dAdOA>
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 11:07:49 -0000

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

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