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> Thu, 02 May 2019 13:44 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 7A9CD120377; Thu, 2 May 2019 06:44:25 -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 Tdhc7gPv8tQ5; Thu, 2 May 2019 06:44:22 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DF31203EE; Thu, 2 May 2019 06:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11901; q=dns/txt; s=iport; t=1556804661; x=1558014261; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2hW4HZpBFk2ehmnjtpel3q1rR955vhVA0WVu441B1ss=; b=Z/lg8ZJV66tqEyXeF9OLpbpvDwMJRHLkdNpmvUPrOOz0lD6gNKa1PCM6 9PybK4uDDlZKQa9E0/OmMBwrQ0M7cBRDIQJ8HXMcMdmicd0Lh4qwy6+1q vx/QkNR5yL88bPOefEOylMGfJivSYss3uSBtPEvrZct7ns93IjnRk6CQm A=;
X-IronPort-AV: E=Sophos;i="5.60,421,1549929600"; d="scan'208";a="11731604"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 May 2019 13:44:19 +0000
Received: from [10.147.24.48] ([10.147.24.48]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x42DiIoH019349; Thu, 2 May 2019 13:44:19 GMT
To: olivier.dugeon@orange.com, "Les Ginsberg (ginsberg)" <ginsberg@cisco.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> <4204f7b2-4a64-c6e2-61bd-3df0cf8ad3c6@cisco.com> <31686_1555079181_5CB0A00D_31686_334_1_e7bdddcf-7645-7783-24d2-23780bd1528e@orange.com> <BYAPR11MB36384F32575D5B5D6A84F09EC1290@BYAPR11MB3638.namprd11.prod.outlook.com> <26747_1556803995_5CCAF19B_26747_297_1_2c41a409-bf3f-b852-7386-4c0e9dfef9a2@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: <aabb92b9-545b-83a2-2999-aa33e94802d3@cisco.com>
Date: Thu, 02 May 2019 15:44:18 +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: <26747_1556803995_5CCAF19B_26747_297_1_2c41a409-bf3f-b852-7386-4c0e9dfef9a2@orange.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.147.24.48, [10.147.24.48]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9EDYepKjQQamT24r2Q6WEdfGs04>
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: Thu, 02 May 2019 13:44:31 -0000
Hi Olivier, On 02/05/2019 15:33 , olivier.dugeon@orange.com wrote: > Hi Les, > > > Le 13/04/2019 à 16:52, Les Ginsberg (ginsberg) a écrit : >> >> Olivier – >> >> >> >> As Jeff has indicated in his reply, the use cases and issues around >> these protocol extensions have been discussed extensively on the WG >> lists (including of course the now subsumed OSPS/IS-IS WG lists) and >> were the subject of many presentations at many IETFs. The history of >> these drafts dates back as far as July of 2015 when the initial >> version of the OSPF draft was published >> (https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/00/ >> ). You have been a participant in this conversation as a search >> through the mailing list archives will confirm. If you have forgotten >> aspects of this discussion I encourage you to review the proceedings >> of previous IETF meetings. There are many useful presentations available. >> >> >> >> I don’t think it serves this thread to attempt to rehash or summarize >> those extensive discussions. Neither does it help for you to respond >> as if none of these discussions took place and that there is no >> problem to be solved. If you are going to comment on the drafts I >> think you have a responsibility to familiarize yourself with the work >> that has gone on for the past few years. >> > > My intention was not to rehash the discussions. I just answer to the WG > last call. Looking to the draft, I consider that section 1 & 2 are not > sufficiently detail how this modifications are required. Or, if you > prefer, the justification, detailing precise case where it is not > possible to use actual TE link parameters. And, preferably, not just > speaking about "incongruent network topology", but given details. > > Then, as already mention,but not take into account, TE link attributes > are orthogonal to services and protocols. I don't agree with the above statement. Some link attributes may have app specific values and that is one of the use cases being addressed by this draft. > Duplicate them to just add > indication on who is using it, or who could used it, will brings into > complexity as we will need to maintain both system old and new, during a > long period. we want multiple different values of link attribute to be advertised. That is not a duplication. thanks, Peter > >> >> >> A bit more Inline. >> >> >> >> *From:*olivier.dugeon@orange.com <olivier.dugeon@orange.com> >> *Sent:* Friday, April 12, 2019 7:26 AM >> *To:* Peter Psenak (ppsenak) <ppsenak@cisco.com>; Acee Lindem (acee) >> <acee@cisco.com>; lsr@ietf.org >> *Cc:* draft-ietf-ospf-te-link-attr-reuse@ietf.org >> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Link Traffic >> Engineering (TE) Attribute Reuse" - >> draft-ietf-ospf-te-link-attr-reuse-07.txt >> >> >> >> Hello Peter, >> >> >> >> Le 12/04/2019 à 15:27, Peter Psenak a écrit : >> >> Hi Oliver, >> >> There are two major purposes served by the drafts: >> >> 1)Support of incongruent topologies for different applications >> >> Don't understand. What do you mean ? >> >> */[Les:] A simple example suffices. Consider the topology:/* >> >> */ /* >> >> */ B/* >> >> */ / \/* >> >> */ A ------C/* >> >> */ \ //* >> >> */ D/* >> >> */ /* >> >> Suppose I want to use links A-B, B-C for RSVP-TE and Links A-D, D-C >> for SRTE. >> >> And Link A-C I want to use for both applications. >> >> >> >> Absent the extensions in these drafts, there is no way with current >> protocol machinery to support this. Both applications will see all >> links as “enabled for TE”. >> >> And (to address one of your questions below) it isn’t just a matter of >> assigning separate affinities for each application. Simply advertising >> TE attributes (for example bandwidth) on a link signals to existing >> RSVP-TE applications that a link is enabled for TE use. >> >> >> >> Again, alternative solutions to this problem were discussed >> extensively on the list and in WG meetings – and the WG eventually >> adopted these drafts. >> > Do you really think that operators manage their networks like that? > especially at a large scale (I mean > 1000 routers & 10000 links). > Enabling TE on routers is already too complex to have fun specializing > some links for RSVP-TE and others for SR. In the same idea, for me, it's > like enabling DiffServ and flows prioritizing on a subset of interfaces > while leaving the other interfaces in Best-Effort mode. > > Olivier > >> >> >> Les >> >> >> >> >> 2)Advertisement of application specific values even on links that >> are in >> use by multiple applications >> >> Hum. Do you think it makes sense to announce different TE metric for >> the same link for different applications ? e.g. 10 ms delay for >> RSVP-TE, 20 ms for SR, 15 ms for LFA and 5 ms for Flex -Algo ? The >> link has a fix delay propagation whatever the application. >> >> If the goal is to dedicated link per application, Resource Class/Color >> attribute could be used. If you would advertised different metric per >> CoS, then you need to dedicated metric per CoS like the unreserved >> bandwidth. >> >> >> 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. >> >> Can you point me a concrete and detail example of the problem ? With a >> PCE, there is no problem to manage both RSVP-TE and SR-TE in the same >> network. And again, as already mention, if the problem come from >> bandwidth reservation, the draft will not solve the issue. >> >> >> 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. >> >> Again, I don't see the problem. Can you explain in detail ? I already >> implement SR in OSPF, starting playing with TE, and there is no >> problem to get TE information from OSPF to tune some Segment Path. If >> it is an implementation issue, it is not a new RFC that will solve the >> problem. >> >> >> It is simply not possible to address these issues with the existing >> single set of application independent advertisements. >> >> Why ? Again, explain in detail. I don't see a real use case that could >> not be address with standard TE attributes. >> >> >> 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 >> >> >> Regards >> >> Olivier >> >> >> >> On 11/04/2019 19:43 , olivier.dugeon@orange.com >> <mailto: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 <mailto: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. >> >> >> >> >> >> _________________________________________________________________________________________________________________________ >> >> 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. > > _________________________________________________________________________________________________________________________ > > 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. >
- [Lsr] Working Group Last Call for "OSPF Link Traf… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak
- Re: [Lsr] Working Group Last Call for "OSPF Link … Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … Jeff Tantsura
- Re: [Lsr] Working Group Last Call for "OSPF Link … Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak
- Re: [Lsr] Working Group Last Call for "OSPF Link … Robert Raszuk
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak
- Re: [Lsr] Working Group Last Call for "OSPF Link … Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak
- Re: [Lsr] Working Group Last Call for "OSPF Link … olivier.dugeon
- Re: [Lsr] Working Group Last Call for "OSPF Link … Peter Psenak