Re: [Isis-wg] [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt

<olivier.dugeon@orange.com> Wed, 25 October 2017 16:53 UTC

Return-Path: <olivier.dugeon@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BE1394F1; Wed, 25 Oct 2017 09:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 BljZOa3SP19c; Wed, 25 Oct 2017 09:53:11 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15633138BE7; Wed, 25 Oct 2017 09:53:11 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id B9AC41205FC; Wed, 25 Oct 2017 18:53:09 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 9B4B340069; Wed, 25 Oct 2017 18:53:09 +0200 (CEST)
Received: from [10.193.71.231] (10.168.234.4) by OPEXCLILM6F.corporate.adroot.infra.ftgroup (10.114.31.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 18:53:09 +0200
To: "Acee Lindem (acee)" <acee@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
References: <10170_1508166197_59E4CA35_10170_182_6_e39cb950-80c3-bc84-dd0b-21a67e45dc0a@orange.com> <D61542A0.D1E05%acee@cisco.com> <650_1508924255_59F05B5F_650_30_1_ca19b84b-f7da-0bca-b0de-5d5f4d6e81e0@orange.com> <D615EFC7.D20AD%acee@cisco.com>
From: <olivier.dugeon@orange.com>
Organization: Orange Labs
Message-ID: <12783_1508950389_59F0C175_12783_211_1_0f38311d-73ba-a67f-91e6-81faa3885897@orange.com>
Date: Wed, 25 Oct 2017 18:53:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <D615EFC7.D20AD%acee@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-GB
X-Originating-IP: [10.168.234.4]
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/RlQpGRmC4lm1-hxCJ0KbEbyGM88>
Subject: Re: [Isis-wg] [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 16:53:13 -0000

Acee,

First apologize for my typo error on IS-IS mailing list. I hope every body got the thread from the beginning (thanks to the OSPF & IS-IS mailing list inter redistribution).

Then, my answers in line.

Le 25/10/2017 à 13:45, Acee Lindem (acee) a écrit :
> Hi Olivier, 
>
> On 10/25/17, 5:37 AM, "olivier.dugeon@orange.com"
> <olivier.dugeon@orange.com> wrote:
>
>> Hi Acee,
>>
>> I agree, but I'm not referring to Unidirectional residual, available and
>> utilized bandwidth as per RFC 7471.
>>
>> My comment concerns the MaximumBandwidth, MaximumReservableBandwidth and
>> UnreservedBandwidth parameters defined in RFC 3630that are used by the
>> CSPF to compute the path. These one are not aggregate if I correctly
>> understand the proposed draft. I also don't understand why these standard
>> TE parameters are duplicate in the ISIS draft and not mention in the OSPF
>> draft. Do we go to a different behaviour between IS-IS and OSPF ?
> If read beyond the draft title, you’ll see that these reservation
> parameters are not included in draft-ietf-ospf-te-link-attr-reuse.
I read carefully the draft and it is exactly what it makes confuse me when I read carefully draft-ietf-isis-te-app-01.txt which explicitly reuse these reservation parameters and suggest to duplicate them per application. The latter is my concerns as it will potentially break the possibility to perform efficient bandwidth reservation with both RSVP-TE and SR-TE in a same network. For me, this will be certainly the main use case during the transition period when an operator will go to SR-TE from RSVP-TE. Both protocol must be manage simultaneously during a large period of time. If standard reservation parameters are duplicated, it will be a nightmare to manage efficiently bandwidth reservation without wasting bandwidth.

So, I would understand if
1) both draft will be align ?
2) in which direction i.e. with or without reservation information and
3) if reservation parameters are included, how my use case could be solved ?
>
>> Now, if the proposed drafts aims to used onlythese new Performance
>> Metrics without duplicate them per application, my question becomes: Why
>> a new drafts ? Why not simply implement RFC 7471 and RFC 7810 ? Up to
>> now, I know only one partial implementation of these 2 RFCs (in
>> FR-Routing Open Source project).
> With respect to OSPF, this topic was already discussed at great length on
> the OSPF list and during the IETF meetings in both Seoul and Chicago.
> Please see the OSPF list archive.
Apologize. I'm jumping on the bandwagon now.

Regards

Olivier
**
>
> Thanks,
> Acee 
>> Regards
>>
>> Olivier
>>
>>
>> Le 25/10/2017 à 01:25, Acee Lindem (acee) a écrit :
>>> Hi Olivier, 
>>>
>>> If you read the definitions of Unidirectional residual, available, and
>>> utilized bandwidth in RFC 7471 you will note that these are all
>>> aggregate
>>> rather than application specific values. In other words, they will not
>>> vary per application.
>>>
>>> Thanks,
>>> Acee 
>>>
>>> On 10/16/17, 11:03 AM, "OSPF on behalf of olivier.dugeon@orange.com"
>>> <ospf-bounces@ietf.org on behalf of olivier.dugeon@orange.com> wrote:
>>>
>>>> Dear authors,
>>>>
>>>> Please find below a comment on both
>>>> draft-ietf-ospf-te-link-attr-reuse-01.txt and
>>>> draft-ietf-isis-te-app-01.txt.
>>>>
>>>> I consider the use case of bandwidth reservation. I know this is not
>>>> the
>>>> most common use case, but the one I known well. The context is that of
>>>> an
>>>> operator who would setup some RSVP-TE tunnels and simultaneously SR-TE
>>>> paths with bandwidth reservation. In this particular case, it is not
>>>> possible to manage both reservation with the drafts as they are.
>>>>
>>>> Indeed, in OSPF draft, it is not proposed to advertised the usual
>>>> bandwidth parameters as defined in RFC3630 and in ISIS, it is proposed
>>>> to
>>>> duplicate these parameters per application. The main problem arises
>>>> from
>>>> the fact that each application, in this case SR-TE and RSVP-TE,
>>>> independently compute a path and therefore reserve bandwidth on their
>>>> respective set of parameters. However, this will lead at a some point
>>>> to
>>>> bandwidth overbooking, which exactly what an operator wants to avoid by
>>>> performing bandwidth reservation. Even if a PCE can be used to handle
>>>> both the RSVP-TE tunnels and SR-TE paths, the same problem arises
>>>> because
>>>> each path computation is performed on a different set of bandwidth
>>>> parameters i.e. one TED per application whereas these information
>>>> relate
>>>> to the same links. Of course a central entity like a PCE might try to
>>>> reconcile the information into a single TED, but this will greatly
>>>> increase the complexity of the PCE with a risk that the TE information
>>>> will
>>>> never be up to date, so at the end unnecessary.
>>>>
>>>> So, for me there are only 2 possibles solutions to avoid this
>>>> overbooking
>>>> problem:
>>>>
>>>> 1/ Split and partition network resources to avoid conflicts. But, this
>>>> leads into a poor network usage. Indeed, if an application like RSVP-TE
>>>> uses less bandwidth than its budget, why the SR-TE application could
>>>> not
>>>> reuse them if it has reached its threshold ? The under utilization of
>>>> network resources will increase proportionally with the number of
>>>> applications. Imagine if we want to use this principle for network
>>>> Slicing. I understand the advantage for vendors, but I'm on the
>>>> operator
>>>> side ;-)
>>>>
>>>> 2/ Each time an application reserved some bandwidth, the routers
>>>> concerned by this new path must update the bandwidth parameters of the
>>>> concerned link not only to the given application, but also to all
>>>> others.
>>>> For example, when RSVP-TE setup a tunnel, Unreserved Bandwidth
>>>> parameters
>>>> must be updated in the standard RFC3630 set, but also in SR-TE
>>>> parameters
>>>> set. But, in this case, why duplicate TE parameters if at the end all
>>>> set
>>>> carry the same values, apart wasting CPU and bandwidth ?
>>>>
>>>> In summary, duplicate TE information is only relevant for the added
>>>> metrics i.e. delay, loss, jitter ... but unusable for concave metrics
>>>> i.e. bandwidth.
>>>>
>>>> Can you explain me how you intend to solve this issue as both possible
>>>> solutions are not suitable for an operator.
>>>>
>>>> Best Regards
>>>>
>>>> Olivier
>>>>
>>>>
>>>> ________________________________________________________________________
>>>> __
>>>> _______________________________________________
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>> __________________________________________________________________________
>> _______________________________________________
>>
>> 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.