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

[Peter Psenak <[e-mail]>]

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


> It would be very operationally complex and completely bizarre to run N
> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Olivier,
>
>     On 12/04/2019 16:26 , [e-mail]
>     <mailto:[e-mail]> wrote:
>     > 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 ?
>
>     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.
>
>     >>
>     >> 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.
>
>     The goal is the allow the link to be used by multiple applications, but
>     be advertised with application specific attributes.
>
>     >>
>     >> 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.
>
>     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.
>
>     >>
>     >> 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.
>
>     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.
>
>     >>
>     >> 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 , [e-mail]
>     <mailto:[e-mail]> 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
>     >>>> [e-mail] <mailto:[e-mail]>
>     >>>> 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.
>     >
>
>     _______________________________________________
>     Lsr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/lsr
>