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

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 12 April 2019 14:50 UTC

Return-Path: <jefftant.ietf@gmail.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 483271206F6; Fri, 12 Apr 2019 07:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sf-1z0EGCBYi; Fri, 12 Apr 2019 07:50:08 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5889012012A; Fri, 12 Apr 2019 07:50:08 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id z11so11665091wmi.0; Fri, 12 Apr 2019 07:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jcBSO4fbklRo63eF2nUuhY9Bgh0jKy23d2dddCTWfPk=; b=D/L5hpaSPRhSiXw6labrfNDnbbiAegcP3UPfFnQjzhXhZU45NwBzYT/p1RWnQ75DL5 VcRWDlQ30nUcTFezCYX/+vDAtHj4JpAS4LKwbb1chXn3+tiN8prVAn0CgKA2TpfZWV/Z xanhhmhqHuMLKYiZrSIhzQzebyRMMTwbUeV6HBI05Wa5olBPtmCVVNosI+gt79+f5byO etcqDrghyaymcAdiWeEbPrg0tQ1vM5m6I0lXn4LcDQdMcezRLnVwQbwVXsgdzLVjmxMj Jp8y595tH8grHZN5IZKBBD7JHCsWB7l7iQacL5MV/GN+7YLroD6Hce6CdPDmIJAD2Jv/ VFfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jcBSO4fbklRo63eF2nUuhY9Bgh0jKy23d2dddCTWfPk=; b=hZeXMibJxILaWfwzuMVD88SZPeSQasuQ5Vp8Gv0Xx8lCPnzkKMUOdFiGIZJQ287ENW Vsq6R+xrgNZ5RAdNwsFgAJAe5eawAfVLYEvPJixeCbYy8lxMvxJ5XDDcymad8ZU0hRR0 8k8kE50fdqNhJrh/DPtEJ4vLvjwLM5XGoBJjSrLiSKGH6XeRW6RY0+9KXD0WrkS42iLz bxTnP8M/jJxDWgdMJavCOkZowOAUkdjtQ7p7xWQW2zC3bRgKNpYB4qtbwdIV/L8E7lr/ 5kaLoNafN1FKrI8V/Yg39M8Ur1wVY5f4uyHb+uzXEva5PWg4Yx9CoBrj4jIeakyHA1mU I9ZQ==
X-Gm-Message-State: APjAAAUTFA7IZ0x0VjeaQ+joR0FWGFIv9dqcCX/jp+6dTy5bBFgvR6ov IUn5uNVak1TMtzWNin8cF7jH5c1W
X-Google-Smtp-Source: APXvYqzrC9LBwCpfuN/mnfnStM63YCO0Adg3KjOcxqj5pa3peVPkRo7Pt1JfbtJO8usDbF1vY2QlgQ==
X-Received: by 2002:a1c:a64d:: with SMTP id p74mr12068018wme.89.1555080606708; Fri, 12 Apr 2019 07:50:06 -0700 (PDT)
Received: from [10.170.5.193] ([81.92.17.218]) by smtp.gmail.com with ESMTPSA id a9sm43152731wrt.29.2019.04.12.07.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 07:50:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <4204f7b2-4a64-c6e2-61bd-3df0cf8ad3c6@cisco.com>
Date: Fri, 12 Apr 2019 16:50:05 +0200
Cc: olivier.dugeon@orange.com, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-ospf-te-link-attr-reuse@ietf.org" <draft-ietf-ospf-te-link-attr-reuse@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD6D2FC3-A8F3-4073-836A-E11869ECFF54@gmail.com>
References: <94A0009A-16FC-40C9-B50A-8C2301CB90B5@cisco.com> <16572_1555004614_5CAF7CC6_16572_4_1_a60c9181-582e-39f8-97df-b41517e210b9@orange.com> <4204f7b2-4a64-c6e2-61bd-3df0cf8ad3c6@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/gTz2uf1wIyqehQVcxAbRETHjT7o>
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 14:50:13 -0000

Olivier,

+1 Peter.
There’s has been significant amount of discussions on the topic some time ago, mostly with Chris Bowers. Please take a look, should provide more context.

Regards,
Jeff

> On Apr 12, 2019, at 15:27, Peter Psenak <ppsenak@cisco.com> wrote:
> 
> 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.
>> 
>