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 protected]> wrote: > Hi Olivier, > > On 12/04/2019 16:26 , [email protected] 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 , [email protected] 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 protected] > >>>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
