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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Apr 2019 16:11:25 +0000

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 27th, 2019.

Thanks,
Acee

---

From: <[email-masked]>
Date: Thu, 11 Apr 2019 19:43:35 +0200

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
> [email-masked]
> 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.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 12 Apr 2019 15:27:06 +0200

Hi Oliver,

There are two major purposes served by the drafts:

1)Support of incongruent topologies for different applications

2)Advertisement of application specific values even on links that are in
use by multiple applications

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.

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.

It is simply not possible to address these issues with the existing
single set of application independent advertisements.

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

On 11/04/2019 19:43 , [email-masked] wrote:
> 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
>
>
>> 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
>>
>>
>>
>>
>>
>>
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 12 Apr 2019 13:31:59 +0000

+1 to what Peter has stated.

Olivier -

We are aware that link attribute management/application has challenges - which is why we are careful to allow sharing of attributes when appropriate.
But to state that there is no problem and that things can be addressed with existing IGP functionality if one is "careful" contradicts our existing deployment experience - as Peter has clearly stated.

   Les

> -----Original Message-----
> From: Peter Psenak <[email-masked]>
> Sent: Friday, April 12, 2019 6:27 AM
> To: [email-masked]; Acee Lindem (acee) <[email-masked]>;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering
> (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt
> 
> Hi Oliver,
> 
> __________________________________________________________
> __________________________________________________________
> _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 12 Apr 2019 16:26:22 +0200

Hello Peter,

> 1)Support of incongruent topologies for different applications
Don't understand. What do you mean ?
> 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.
> SRTE in networks where there is partial deployment of SR in the presence
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.
> RSVP-TE) are also present. Early implementers of Flex-Algo can attest to
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.
> 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.

Regards

Olivier

---

From: <[email-masked]>
Date: Fri, 12 Apr 2019 16:27:57 +0200

Hi Les,

> But to state that there is no problem and that things can be addressed with existing IGP functionality if one is "careful" contradicts our existing deployment experience - as Peter has clearly stat…
Unfortunately, it is not clear for me which problem your encountered. Can you explain in detail ?

Regards

Olivier

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 12 Apr 2019 16:50:05 +0200

Olivier,

+1 Peter.
There’s has been significant amount of discussions on the topic some time ago, mostly with Chris Bowers. Please take a look, should provide more context.

Regards,
Jeff

> On Apr 12, 2019, at 15:27, Peter Psenak <[email-masked]> wrote:
> 
> Hi Oliver,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 13 Apr 2019 14:52:22 +0000

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.

A bit more Inline.

From: [email-masked] <[email-masked]>
Sent: Friday, April 12, 2019 7:26 AM
To: Peter Psenak (ppsenak) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Cc: [email-masked]
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,

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

   Les

thanks,
Peter

Regards

Olivier

On 11/04/2019 19:43 , [email-masked]<mailto:[email-masked]> wrote:

Hi,

Regards

Olivier

 LSR Working Group,

Thanks,
Acee

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 15 Apr 2019 10:49:14 +0200

Hi Olivier,

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

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

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

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

> 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

>>> 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,
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law;
>>> If you have received this email in error, please notify the sender
>>> and delete this message and its attachments.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Apr 2019 11:21:48 +0200

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 <[email-masked]> wrote:

> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler

---

From: Peter Psenak <[email-masked]>
Date: Mon, 15 Apr 2019 13:05:32 +0200

Robert,

On 15/04/2019 11:21 , Robert Raszuk wrote:
> Peter,
>
> IMO what Olivier has indicated is a practical and operational aspect.
> The theoretical aspects of protocol operation is what this document is
> 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 !

let me assure you that this work has been triggered by the real problems 
we have experienced in the field. Being it a "theoretical aspects of 
protocol operation" we would not have spent our effort on it.

> different TE applications concurrently in any production network. The

it is a reality already. RSVP TE and SR TE are being deployed in 
parallel as networks are migrating towards SR.

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

your view is (RSVP) TE focused. There are other apps that have nothing 
to do with TE and they need to use link attributes - LFA, flex-ago, etc. 
And bandwidth is not the only link attribute.

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

could very well be the case. Depends on what you measure.

thanks,
Peter

>
> Kind regards,
> R.
>
> On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Olivier,
>
>     On 12/04/2019 16:26 , [email-masked]
>     <mailto:[email-masked]> wrote:
>     > Hello Peter,
>     >
>     >
>     >> On 11/04/2019 19:43 , [email-masked]
>     <mailto:[email-masked]> wrote:
>     >>> Hi,
>     >>>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >>> As emails may be altered, Orange is not liable for messages that
>     have
>     >>> been modified, changed or falsified.
>     >>> Thank you.
>     >>>
>     >>
>     >>
>     >
>     >
>     > As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>     > Thank you.
>     >
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Apr 2019 16:03:47 +0000

Speaking as WG member... 

Right, there was a protracted WG discussion. IIRC, Olivier was opposed based on some code he had written for quagga using OSPF TE LSAs for purposes other than traditional RSVP TE. At the end of this discussion, we reached WG consensus with the understanding that some code would need to change. 

Thanks,
Acee

On 4/12/19, 10:50 AM, "Jeff Tantsura" <[email-masked]> wrote:

    Olivier,
    
    +1 Peter.
    
    Regards,
    Jeff