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:46 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 A1C28120135; Thu, 2 May 2019 06:46:12 -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 WL48H89l7w2A; Thu, 2 May 2019 06:46:09 -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 4DD1F120020; Thu, 2 May 2019 06:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11837; q=dns/txt; s=iport; t=1556804769; x=1558014369; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/5q4OQcWbf8KwhMLP6YyY0ecOWcb8gIjOTtxwCvRoLc=; b=QdcjlnmP2TbphPD4VWu+R9gd8GNIIMlfuj7NZm4/Fjwit41vfNLQYPZf /F1j+y2+p0WoTf9XGA8rAdx2t8uAYUEK081klHW9gfUyb0XPLawNU5NkC ILwl3mbk+N55yMVgNe7wxZKSxZHR7qVoi7Yz1JMOiPJe41b+TxOU7zzHr M=;
X-IronPort-AV: E=Sophos;i="5.60,421,1549929600"; d="scan'208";a="11787600"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 May 2019 13:46:07 +0000
Received: from [10.147.24.48] ([10.147.24.48]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x42Dk63L004048; Thu, 2 May 2019 13:46:06 GMT
To: olivier.dugeon@orange.com, Robert Raszuk <robert@raszuk.net>
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> <9920a032-b2f1-e8f6-47e0-4b3902d9c95f@cisco.com> <CAOj+MMGW2a87fxoFsVBEP8sTVVni0rwPgB+H86R5oXdnZBQ3+g@mail.gmail.com> <10470_1556804111_5CCAF20F_10470_203_1_5732c6e7-0588-db2d-b489-fd897d08aafe@orange.com>
Cc: "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>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <285e5747-8498-7ea4-22b3-e5ab3215e22c@cisco.com>
Date: Thu, 02 May 2019 15:46: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: <10470_1556804111_5CCAF20F_10470_203_1_5732c6e7-0588-db2d-b489-fd897d08aafe@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-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Q9iUsQIL8s8qBPWgc1GC_nEoMFU>
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:46:13 -0000
Olivier, On 02/05/2019 15:35 , olivier.dugeon@orange.com wrote: > +1 > > I would take the opportunity to ask operators on the mailing to raise > their voice. Please, tell us if you are managed you networks with > incongruent TE topology, and thus, are concern by this draft. incongruent TE/IGP topology is not the only use case, please read my previous response. thanks, Peter > > You have already understand that it is not our case. > > Thanks > > Olivier > > > Le 15/04/2019 à 11:21, Robert Raszuk a écrit : >> Peter, >> >> IMO what Olivier has indicated is a practical and operational aspect. >> The theoretical aspects of protocol operation is what this document is >> extending. Those are two different things :) And this is not the >> first time where IETF is manufacturing specs without any serious input >> from folks who actually need to use it. The co-authors of this very >> draft indicates it quite clearly - all vendors ! >> >> It would be very operationally complex and completely bizarre to run N >> different TE applications concurrently in any production network. The >> fact that you could or can does not make it immediately a good idea. >> Perhaps great exercise for the lab though. >> >> Even with one such TE mechanism there is a lot of things to manage and >> that is why very few networks run full 100% TE. Further more as you >> know TE reservations are all in control plane so the moment you >> forward any significant amount of non TE traffic (unicast or >> multicast) your entire TE magic is over. >> >> Last I was hoping someone will answer how for a given link of RTT 20 >> ms - you could send different value per each application ? Or do you >> mean that on any given link mpls RTT != IPv4 RTT != IPv6 RTT ? >> >> Kind regards, >> R. >> >> On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak <ppsenak@cisco.com >> <mailto:ppsenak@cisco.com>> wrote: >> >> Hi Olivier, >> >> On 12/04/2019 16:26 , olivier.dugeon@orange.com >> <mailto:olivier.dugeon@orange.com> wrote: >> > 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 ? >> >> RFC3630 allows the traffic engineering topology to be incongruent >> with >> the regular routing topology. This means that the RSVP TE topology >> can >> only be a subset of the regular routing topology. If there is a >> need to >> advertise some link attribute for the purpose of the other >> application, >> the link would become part of the RSVP TE topology, something that >> may >> not be desired. >> >> >> >> >> 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. >> >> The goal is the allow the link to be used by multiple >> applications, but >> be advertised with application specific attributes. >> >> >> >> >> 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. >> >> there is no way to advertise the link for the purpose of the SR-TE, >> without it becoming the part of the RSVP-TE using existing >> advertisements. Similarly applicable in the context of any other >> application. >> >> >> >> >> 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. >> >> we are not trying to solve the implementation issue. We are >> solving the >> protocol issue. Both protocols have defined many link attributes >> for the >> purpose of the RSVP-TE. Some of these are usable outside of the >> RSVP TE >> and we are extending the protocols to support that. >> >> Please read the discussion on the mailing list that happened prior to >> the WG adoption of these drafts. >> >> >> >> >> 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. >> >> please see above. >> >> thanks, >> Peter >> >> >> >> >> >> 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. >> > >> >> _______________________________________________ >> 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. >
- [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