Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Peter Psenak <ppsenak@cisco.com> Fri, 12 April 2019 13:27 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 DAB081204C3; Fri, 12 Apr 2019 06:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8TWTmjd7NruX; Fri, 12 Apr 2019 06:27:10 -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 898351201DA; Fri, 12 Apr 2019 06:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3185; q=dns/txt; s=iport; t=1555075629; x=1556285229; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5ARUj/eVzEVAX/o4nLzxviiRKtYeDeh+YUbR0+HjU2c=; b=Lial6YZ6CGXtpFP2cA2BfJTnGk6RarpvTKgzKbgYIYL0BBMsv3UuNKlN 4eDgplevBPQI94egEpQKTawr5hDUEXWbzu/HnP+3gNE349ohxZfVP3tqq 0cV3yN46O774QaI8sfK1s6XSK+pEdY3nq1qdPGmv+q3DupSq5gKCXwWVV Q=;
X-IronPort-AV: E=Sophos;i="5.60,341,1549929600"; d="scan'208";a="11291654"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 13:27:07 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x3CDR6Me023803; Fri, 12 Apr 2019 13:27:07 GMT
To: olivier.dugeon@orange.com, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
References: <94A0009A-16FC-40C9-B50A-8C2301CB90B5@cisco.com> <16572_1555004614_5CAF7CC6_16572_4_1_a60c9181-582e-39f8-97df-b41517e210b9@orange.com>
Cc: "draft-ietf-ospf-te-link-attr-reuse@ietf.org" <draft-ietf-ospf-te-link-attr-reuse@ietf.org>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <4204f7b2-4a64-c6e2-61bd-3df0cf8ad3c6@cisco.com>
Date: Fri, 12 Apr 2019 15:27:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <16572_1555004614_5CAF7CC6_16572_4_1_a60c9181-582e-39f8-97df-b41517e210b9@orange.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_lJQ6WIZ-RTH9C1C-u_sHFfHF08>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt
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: Fri, 12 Apr 2019 13:27:12 -0000

Hi Oliver,

There are two major purposes served by the drafts:

1)Support of incongruent topologies for different applications

2)Advertisement of application specific values even on links that are in
use by multiple applications

These issues are clearly articulated in the Introductions of both
drafts. LSR WG acknowledged them a while back and decided to address
them.

Issue #1 has already had a significant impact on early deployments of
SRTE in networks where there is partial deployment of SR in the presence
of RSVP-TE.

Issue #2 will be seen in deployments where Flex-Algo and SRTE (or
RSVP-TE) are also present. Early implementers of Flex-Algo can attest to
this.

It is simply not possible to address these issues with the existing
single set of application independent advertisements.

The solutions we provide in both drafts allow to share the link
attributes between application as well as keep them separate if that is
what is required.

thanks,
Peter

On 11/04/2019 19:43 , olivier.dugeon@orange.com wrote:
> Hi,
>
> I'm not in favour of this draft.
>
> As already mention, I don't see the interest to duplicate TE attributes
> in new Extended Link Opaque LSA. For me, it is only a matter of
> implementation to look at various place in the OSPF TE Database to take
> Traffic Engineering information.
>
> From an operator perspective, it is already hard to manage TE attribute
> and I'm pretty sure that we could not ask network management team to
> maintain 2 systems for certainly a long period of time as many TE
> attributes remains in the standard Opaque LSA Traffic Engineering.
>
> Regards
>
> Olivier
>
>
> Le 11/04/2019 à 18:11, Acee Lindem (acee) a écrit :
>>
>>  LSR Working Group,
>>
>>
>>
>> This begins a two week  WG last call for the subject document. Please
>> enter your support or objection to the document before 12:00 AM (EDT)
>> on Friday, April 27^th , 2019.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>