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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 Nov 2017 17:16:58 +0000

Olivier -

https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-03 was published a short while ago and it addresses the issues you raised. (OSPF draft will be updated soon in an consistent manner.)
Specifically,

"Maximum link bandwidth is an application independent attribute of the
   link.  When advertised using the Application Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised."

"Unreserved bandwidth is an attribute specific to RSVP."

As regards MaximumReservableBandwidth, we appreciate that managing bandwidth per application may be challenging. However we feel there are legitimate use cases for doing that and do not want to preclude that. The fact that it is possible to advertise this attribute with different values/application does NOT mean that a deployment MUST do so. You can associate the same value with all applications enabled in your network if you wish.

Thanx for calling our attention to these points. Please let us know of any additional concerns .

    Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, October 26, 2017 6:55 PM
> To: [email-masked]; Acee Lindem (acee) <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-
> 01.txt and draft-ietf-isis-te-app-01.txt
> 
> Olivier -
> 
> Thanx for the discussion.
> 
> The authors of draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-
> app-01.txt are in discussions and we will resolve the discrepancies between
> the two drafts as regards the set of link attributes which are supported.
> As regards issues associated with MaximumBandwidth,
> MaximumReservableBandwidth and UnreservedBandwidth parameters this
> is also under discussion and we will have more to say about that soon.
> 
> Appreciate your patience...
> 
>     Les
> 
> > -----Original Message-----
> > From: Isis-wg [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Wednesday, October 25, 2017 9:53 AM
> > To: Acee Lindem (acee) <[email-masked]>; [email-masked];
> > [email-masked]
> > Subject: Re: [Isis-wg] [OSPF] Comments on
> > draft-ietf-ospf-te-link-attr-reuse-
> > 01.txt and draft-ietf-isis-te-app-01.txt
> >
> > 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, "[email-masked]"
> > > <[email-masked]> 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
> > [email-masked]"
> > >>> <[email-masked] on behalf of [email-masked]>
> > 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
> > >>>> [email-masked]
> > >>>> 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.
> >
> > _______________________________________________
> > Isis-wg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/isis-wg
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Wed, 29 Nov 2017 19:28:19 +0100

Hello Les,

Thanks to take into account our use cases.

I carefully read the new version of the draft. If now it is clear that Maximum and Unreserved Bandwidth Link parameters are announced as unique value (which solve partially the issue I raised), it is unclear for mein which Sub-TLVs group there are announced: standard TE TLVs or the new proposed TLV's ? If there are not announced in the same TLVs set, these will drastically increase the complexity for a router that runs both SR-TE and RSVP-TE. If there are announced in the same TLVs set, I don't understand the objective of the draft.

But, looking again carefully to the draft, now, I don't understand why these two specifics Bandwidth Link parameters have a special treatment while other Bandwidth parameters not. I means, all extended bandwidth metrics must be also uniquely announce to avoid any mis-interpretation during bandwidth reservation. In particular for these extended metrics which come from measurement, why duplicate them, one per application ? Same for the Maximum Reservable Bandwidth.

Finally, I still do not understand why these new parameters are announced per Application. All these parameters are belonging to the Link Attributes, not to a particular application. Looking to the argument of the draft, I agree that TE link parameters where design specifically for RSVP-TE and enhance time after time which, at the end, give a non-optimal, perhaps not coherent global picture, especially for OSPF. So, if the goal is to re-order and clean Link Attributes, I think that the way to go is not correctly expose in the draft. I would prefer a new encoding schema within the new OSPF Opaque LSA Extended Link Attributes and a clear migration scenario to help operators move from the old encoding schema to the new one. For ISIS, it is safer as Link Attributes are convey into a more coherent TLVs and don't need to be change.

Regards

Olivier

>>>>>>> have been modified, changed or falsified.

_________________________________________________________________________________________________________________________

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Nov 2017 22:24:15 +0000

Olivier –

I think we are going in a circle a bit i.e., you seem to be asking the same questions that I have already tried to answer – so not sure how successful my second attempt will be – but I will give it a try.

As an aside, I think it would probably be helpful to provide some examples of how to use the extensions defined in the draft. Section 7 of the draft discusses this – but it may well be helpful to provide some more detailed examples.  We will work on adding that to the next revision.

As background context, the draft supports sharing a single set of link attribute advertisements among many applications and it supports having multiple sets of link attribute advertisements for a given link, each set associated with one or more applications. Which mode you use depends on the use cases you have in your network. Please keep in mind that this is a choice – not a mandate to move to multiple set of link attribute advertisements.

As regards different attribute values for different applications on a given link, we do understand that this increases complexity. If you do not have a use case for doing this in your network then you should advertise one and only one value for a given attribute on a link. However, there are networks where the operator wants to manage bandwidth on a per application basis. We did not invent this use case – it has been requested. In such a case the requirement is to be able to advertise per application values. Clearly, when doing so, the management task becomes more complex. But this is a choice the operator makes based on the use case.

As regards the two “special parameters”, we have tried to be explicit in the draft as to the reasons for special treatment.

Section 4.2.1: “Maximum link bandwidth is an application independent attribute of the  link.”
This attribute simply advertises the physical capacity of the link – which does not change based on the number/type of applications which may be using that link. We have therefore specified that only one value may be advertised/link. As an aid to transition cases, the same value MAY be advertised in multiple sub-TLVs for a given link, but the values MUST be identical.

Section 4.2.2: “Unreserved bandwidth is an attribute specific to RSVP.”
It is therefore illegal to advertise that parameter associated with an application other than RSVP-TE.
This can be accomplished by using a legacy advertisement or by using the new sub-TLV. In the latter case only the RSVP-TE bit can be set.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 29, 2017 10:28 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt

Hello Les,

I carefully read the new version of the draft. If now it is clear that Maximum and Unreserved Bandwidth Link parameters are announced as unique value (which solve partially the issue I raised), it is unclear for me in which Sub-TLVs group there are announced: standard TE TLVs or the new proposed TLV's ? If there are not announced in the same TLVs set, these will drastically increase the complexity for a router that runs both SR-TE and RSVP-TE. If there are announced in the same TLVs set, I don't understand the objective of the draft.

Regards

Olivier

Olivier -

Specifically,

    Les

-----Original Message-----

(ginsberg)

To: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]><mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Olivier -

    Les

-----Original Message-----

[email-masked]<mailto:[email-masked]>

To: Acee Lindem (acee) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]>

Acee,

Hi Olivier,

On 10/25/17, 5:37 AM, "[email-masked]"<mailto:[email-masked]>

<[email-masked]><mailto:[email-masked]> wrote:

Hi Acee,

used

behaviour between IS-

IS and OSPF ?

?

Chicago.

Regards

Olivier

**

Thanks,

Acee

Regards

Olivier

Hi Olivier,

Thanks,

Acee

[email-masked]<mailto:[email-masked]>"

<[email-masked] on behalf of [email-masked]><mailto:[email-masked]@orange.com>

wrote:

Dear authors,

unnecessary.

overbooking

problem:

to all others.

Best Regards

Olivier

_________

_____

__

falsifie.

Merci.

Thank you.

OSPF mailing list

[email-masked]<mailto:[email-masked]>

___________

Thank you.

_____

Thank you.

Isis-wg mailing list

[email-masked]<mailto:[email-masked]>

Isis-wg mailing list

[email-masked]<mailto:[email-masked]>

Thank you.