Hi Olivier,
On 02/05/2019 16:01 , [email protected] wrote:
Hello Peter,
Le 15/04/2019 à 13:05, Peter Psenak a écrit :
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.
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 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.
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.
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.
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:
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,"
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 ... ?
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.
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.
you call it something else, I call it app specific delay.
thanks,
Peter
Regards
Olivier
thanks,
Peter
Kind regards,
R.
On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Hi Olivier,
On 12/04/2019 16:26 , [email protected]
<mailto:[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]
<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.
>
_______________________________________________
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
