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

<olivier.dugeon@orange.com> Thu, 02 May 2019 13:33 UTC

Return-Path: <olivier.dugeon@orange.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 EBF90120020; Thu, 2 May 2019 06:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level:
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 BWLlcGPr8FEY; Thu, 2 May 2019 06:33:17 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135E4120135; Thu, 2 May 2019 06:33:17 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 44vx6M1DCxz5wR7; Thu, 2 May 2019 15:33:15 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 44vx6M0FwLzyQB; Thu, 2 May 2019 15:33:15 +0200 (CEST)
Received: from OPEXCLILMA2.corporate.adroot.infra.ftgroup (10.114.31.69) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup (10.114.13.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 2 May 2019 15:33:14 +0200
Received: from [10.193.71.29] (10.168.234.4) by OPEXCLILMA2.corporate.adroot.infra.ftgroup (10.114.31.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 2 May 2019 15:33:14 +0200
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "draft-ietf-ospf-te-link-attr-reuse@ietf.org" <draft-ietf-ospf-te-link-attr-reuse@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>
From: olivier.dugeon@orange.com
Organization: Orange Labs
Message-ID: <26747_1556803995_5CCAF19B_26747_297_1_2c41a409-bf3f-b852-7386-4c0e9dfef9a2@orange.com>
Date: Thu, 02 May 2019 15:33:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <BYAPR11MB36384F32575D5B5D6A84F09EC1290@BYAPR11MB3638.namprd11.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B985A859A6DEE4DEF2389BBB"
Content-Language: en-GB
X-Originating-IP: [10.168.234.4]
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/phzLuVoYgtcNM_O8tEfJ8V-Raew>
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:33:20 -0000

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

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