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

From: <[email-masked]>
Date: Thu, 2 May 2019 15:33:16 +0200

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:[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,
>
>  
>
> 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 , [email-masked] <mailto:[email-masked]> 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
>             [email-masked] <mailto:[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.
>
>      
>
>  
>
> _________________________________________________________________________________________________________________________
>  
> 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.

---

From: <[email-masked]>
Date: Thu, 2 May 2019 15:35:11 +0200

+1

I would take the opportunity to ask operators on the mailing to raise their voice. Please, tell us if you are managed you networks with incongruent TE topology, and thus, are concern by this draft.

You have already understand that it is not our case.

Thanks

Olivier

Le 15/04/2019 à 11:21, Robert Raszuk a écrit :
> 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] <mailto:[email-masked]>> wrote:
>
>     Hi Olivier,
>
>     On 12/04/2019 16:26 , [email-masked] <mailto:[email-masked]> wrote:
>     > Hello Peter,
>     >
>     >
>     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
>
>
>     >>
>     >>> 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,
>     >>> 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: Peter Psenak <[email-masked]>
Date: Thu, 2 May 2019 15:44:18 +0200

Hi Olivier,

On 02/05/2019 15:33 , [email-masked] wrote:
>> 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.

I don't agree with the above statement. Some link attributes may have 
app specific values and that is one of the use cases being addressed  by 
this draft.

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

we want multiple different values of link attribute to be advertised. 
That is not a duplication.

thanks,
Peter

>> *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,
>>
>>
>>
>> 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
>>
>>
>>
>>
>> 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.
>>
>> 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.
>>
>>
>>     On 11/04/2019 19:43 , [email-masked]
>>     <mailto:[email-masked]> wrote:
>>
>>         Hi,
>>
>>         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,
>>         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: Thu, 2 May 2019 15:46:06 +0200

Olivier,

On 02/05/2019 15:35 , [email-masked] wrote:
> +1
>
> I would take the opportunity to ask operators on the mailing to raise
> their voice. Please, tell us if you are managed you networks with
> incongruent TE topology, and thus, are concern by this draft.

incongruent TE/IGP topology is not the only use case, please read my 
previous response.

thanks,
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 12/04/2019 16:26 , [email-masked]
>>     problem
>>     > As emails may be altered, Orange is not liable for messages that
>>     have been modified, changed or falsified.
>>     > Thank you.
>>     >
>>

---

From: <[email-masked]>
Date: Thu, 2 May 2019 16:01:52 +0200

Hello Peter,

Le 15/04/2019 à 13:05, Peter Psenak a écrit :
> Robert,
>
> On 15/04/2019 11:21 , Robert Raszuk wrote:
>> Peter,
>>
>> 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 !
>
> 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.
Can you detail it in the draft ? The first two sections miss of a good justification i.e. problem statement section with details about the real problem.
> it is a reality already. RSVP TE and SR TE are being deployed in parallel as networks are migrating towards SR.
Yes of course. But, do you really think that TE is not activated on all links ? especially on large scale network ? And for SR-TE, PCE (or equivalent) is mandatory, especially if you would reserve some bandwidth. So, PCE need the whole network topology and TE information on the whole topology, not on a subset. Once done, the PCE, through the request, perfectly know if the path computation concern RSVP-TE, SR-TE or whatever else.

Concerning the migration from RSVP-TE to SR-TE, we are pretty sure that this will take time, (count in years not in months) and perhaps that both will coexist for ever. So, in this case, we'll be oblige to maintain the 2 systems waiting of Link Attributes advertisement, during the transition and migration of the network which take again a long period at large scale. We don't upgrade more than 1000 routers in one night.
>> 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.
Please, re-read RFC3630. In was never writen that RFC3630 is limited to RSVP-TE. RSVP-TE is only mention in the bibliography. Section 1 of RFC3630 says:

  "The information made available by these extensions can be used to
   build an extended link state database just as router LSAs are used to
   build a "regular" link state database; the difference is that the
   extended link state database (referred to below as the traffic
   engineering database) has additional link attributes.  Uses of the
   traffic engineering database include:

      o  monitoring the extended link attributes;
      o  local constraint-based source routing; and
      o  global traffic engineering.

   For example, an OSPF-speaking device can participate in an OSPF area,
   build a traffic engineering database, and thereby report on the
   reservation state of links in that area."

In which way it is not compatible with Flex-Algo, LFA, SR-TE ... ?

Starting with RFC 3630, many other RFC have defined link attributes, disregarding if their are named TE or not. The main problem is not the RFCs, but the lack of implementation and support for some of them e.g. Extended Metrics (RFC7471, RFC7810). I think, it will be safe if we could start by deploying such RFC in our networks and see what's happen, what we could collect and do with these new metrics. Then, we could determine if there is some missing piece in the tools-box. But, as of today, we can't because some RFCs are not yet implemented. And again, I don't see anything that avoid the usage of actual Link Attributes for other protocol as RSVP-TE.
>
>>
>> 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.
Hum; link delay rely to some physicals (length of link, propagation speed, ...) and not what kind of protocol it is convey on the link. If you measure different link delay in function of the protocol, is that you measure also the time for packet processing. But, in this case, it is no more the link delay. It is something else.

Regards

Olivier
>>     > 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 ?
>>
>>     >>
>>     >> 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.
>>
>>     please see above.
>>
>>     thanks,
>>     Peter
>>
>>
>>     >>
>>     >> 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 , [email-masked]
>>     >>> 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] <mailto:[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.
>>     >>>
>>     >>
>>     >>
>>     >
>>     >
>>     >
>>     > Ce message et ses pieces jointes peuvent contenir des informations
>>     > pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>     > a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>     > Orange decline toute responsabilite si ce message a ete altere,
>>     deforme ou falsifie. Merci.
>>     >
>>     > This message and its attachments may contain confidential or
>>     > they should not be distributed, used or copied without authorisation.
>>     > If you have received this email in error, please notify the sender
>>     > As emails may be altered, Orange is not liable for messages that
>>     > Thank you.
>>     >

---

From: Peter Psenak <[email-masked]>
Date: Thu, 2 May 2019 16:57:22 +0200

Hi Olivier,

On 02/05/2019 16:01 , [email-masked] wrote:
>> 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.
> Can you detail it in the draft ? The first two sections miss of a good
> justification i.e. problem statement section with details about the real
> problem.
>>
>>
>> it is a reality already. RSVP TE and SR TE are being deployed in
>> parallel as networks are migrating towards SR.
> Yes of course. But, do you really think that TE is not activated on all
> links ?

in some cases it is not. We have a real life example of RSVP and SRTE 
being deployed on the disjoint set of links/nodes inside the single IGP 
area.

> especially on large scale network ? And for SR-TE, PCE (or
> equivalent) is mandatory, especially if you would reserve some
> bandwidth. So, PCE need the whole network topology and TE information on
> the whole topology, not on a subset. Once done, the PCE, through the
> request, perfectly know if the path computation concern RSVP-TE, SR-TE
> or whatever else.

the problem is that with the existing advertisements, RSVP would believe 
that all the links that are advertised are also RSVP enabled. I feel 
like I keep repeating this over and over. Please try to read through the 
discussion that preceded the WG adoption.

>
> Concerning the migration from RSVP-TE to SR-TE, we are pretty sure that
> this will take time, (count in years not in months) and perhaps that
> both will coexist for ever.

wrong assumption.

> So, in this case, we'll be oblige to
> maintain the 2 systems waiting of Link Attributes advertisement, during
> the transition and migration of the network which take again a long
> period at large scale. We don't upgrade more than 1000 routers in one night.
>>
>> 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.
> Please, re-read RFC3630. In was never writen that RFC3630 is limited to
> RSVP-TE. RSVP-TE is only mention in the bibliography. Section 1 of
> RFC3630 says:
>

above is not correct. Please note the below quote from RFC3630:

   "The extensions provide a way of describing the traffic engineering
    topology (including bandwidth and administrative constraints) and
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,"

> In which way it is not compatible with Flex-Algo, LFA, SR-TE ... ?

1. RFC RFC3630 based TE topology may only describe subset of the IGP 
topology
2. Any link which is part of the RFC3630 based TE topology is assumed to 
be RSVP enabled by RSVP
3. I want to advertise different link attribute values in the context of 
the Flex-algo for some of the link attributes.

>
> Starting with RFC 3630, many other RFC have defined link attributes,
> disregarding if their are named TE or not. The main problem is not the
> RFCs, but the lack of implementation and support for some of them e.g.
> Extended Metrics (RFC7471, RFC7810). I think, it will be safe if we
> could start by deploying such RFC in our networks and see what's happen,
> what we could collect and do with these new metrics. Then, we could
> determine if there is some missing piece in the tools-box. But, as of
> today, we can't because some RFCs are not yet implemented. And again, I
> don't see anything that avoid the usage of actual Link Attributes for
> other protocol as RSVP-TE.

well, most people in the WG do acknowledge the problems that we are 
addressing in the draft.

> Hum; link delay rely to some physicals (length of link, propagation
> speed, ...) and not what kind of protocol it is convey on the link. If
> you measure different link delay in function of the protocol, is that
> you measure also the time for packet processing. But, in this case, it
> is no more the link delay. It is something else.

you call it something else, I call it app specific delay.

thanks,
Peter

>>> informations
>>> vous
>>> sender
>>>     >>> been modified, changed or falsified.
>>>     >>> Thank you.
>>>     >>>
>>>     >>
>>>     >>
>>>     >
>>>     >
>>>