Hi Olivier,
On 02/05/2019 15:33 , [email protected] wrote:
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.
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
A bit more Inline.
*From:*[email protected] <[email protected]>
*Sent:* Friday, April 12, 2019 7:26 AM
*To:* Peter Psenak (ppsenak) <[email protected]>; Acee Lindem (acee)
<[email protected]>; [email protected]
*Cc:* [email protected]
*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 protected]
<mailto:[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] <mailto:[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.
_________________________________________________________________________________________________________________________
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
