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