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

["Acee Lindem (acee)" <[e-mail]>]

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 [e-mail]"
<[e-mail] on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf