Hi Olivier,
On 12/04/2019 16:26 , olivier.dug...@orange.com 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 , olivier.dug...@orange.com 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
Lsr@ietf.org
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
