<html>
<head>
</head>
<body>
<div style="color: black;">
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black;">I'm suggesting that per
interface te enabling needs to be per protocol. For example, consider
the case where some links use is is te and others use OSPF te...</p>
<p style="margin: 0 0 1em 0; color: black;">Lou </p>
</div>
<div style="color: black;">
<p
style="color: black; font-size: 10pt; font-family: Arial, sans-serif; margin: 10pt 0;">On
December 1, 2016 4:42:08 AM <olivier.dugeon@orange.com> wrote:</p>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">
<p><font face="Ubuntu">Hi Lou, Donald,</font></p>
<p><font face="Ubuntu">Indeed, the original OSPF-TE code only add
extra link parameters management in the OSPFD daemon.</font></p>
<p><font face="Ubuntu">First, I started by upgrading this code. Then,
I ported the code to ISIS and failed into a big issue: how to
handle similar command in two different process when both IS-IS
and OSPF are running ? So, I decided to move all link parameters
management to ZEBRA and let others daemon collect information
through ZEBRA-API. <br>
</font></p>
<p><font face="Ubuntu">Now, to activate TE, you must first enable it
at the IGP level, with 'mpls-te on' command (both OSPF and
IS-IS) and then activate on a per interface basis the
advertisement of TE parameters with 'link-params enable' command
at ZEBRA interface level.</font></p>
<p><font face="Ubuntu">I hope this is convenient. If not, just let
me know how you would manage this and I'll modify the code
accordingly.</font></p>
<p><font face="Ubuntu">Regards</font></p>
<p><font face="Ubuntu">Olivier<br>
</font></p>
<br>
<div class="moz-cite-prefix">Le 30/11/2016 à 20:27, Lou Berger a
écrit :<br>
</div>
<blockquote cite="mid:08582ebb-ec0f-ade4-1789-7a41de3535d4@labn.net"
type="cite">
<pre wrap="">ahh, good. Then OSPF TE should really be enabled on a
per interface
basis and not implicitly based on if TE parameters are defined for an
interface...
On 11/30/2016 2:10 PM, Donald Sharp wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The data is stored in zebra and passed up to
interested protocols if I
read the code correctly.
donald
On Wed, Nov 30, 2016 at 1:56 PM, Lou Berger <a
class="moz-txt-link-rfc2396E"
href="mailto:lberger@labn.net"><lberger@labn.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jumping in in the middle here, sorry but having been
down this road a
couple of times before... IMO link parameters really need to go into
common objects shared by all protocols (OSPF-TE, ISIS-TE, RSVP-TE...) -
and should also allow dynamic updates/exchanges by and between the
protocols. In past implementations we've called this set of objects and
associated functions Link Management.
On 11/30/2016 1:41 PM, <a class="moz-txt-link-abbreviated"
href="mailto:olivier.dugeon@orange.com">olivier.dugeon@orange.com</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Donald,
Well, this part of the code has been fully re-write by Paul, and I'm
more or less confident with it.
First, Paul introduce a new sub-command with the link-params which has
broke the way vtysh handle this part. I patch vtysh to circumvent the
issue, but it breaks the possibility to list the command in
alphabetical order. So, don't hesitate to change this if you find a
better solution.
Then, I think you could remove the 'enable' statement, but I'm afraid
that it breaks the code. Let me explain. When parsing the
configuration file, the 'enable' statement serves to determine if
Traffic Engineering information are active or not for this interface.
If inactive, the OSPF or ISIS protocol will not generate LSA or LSP
for this interface with TE parameters. Do, if you remove the enable
statement, you must change the code to check if 'link-param' statement
is there or not. Or replace 'link-param' by 'link-param enable'
command, but I'm not sure that it is good.
Finally, concerning the bandwidth parameters, it is historical. The
first TE implementation in OSPF print all TE parameters once enable. I
agree that we could mask them, but, how to differentiate the default
parameter from the modified one ? Another solution, is to used a
reduce command that just allow the user to modify globally the
bandwidth like Juniper or Cisco offer. In fact, some bandwidth
parameters are directly computed based on what the interface could
physically do. Then, you could modify these values in order to reduce
the amount of bandwidth announced, and thus allocated for TE. However,
these values are then updated automatically by the router when a TE
tunnel is setup. As Quagga doesn't yet support RSVP-TE, there is no
process that modify the bandwidth value instead of command line. Some
other parameters are purely administrative like the TE metric. So,
only modify by command line. And finally, some parameters are issue
from measurement like the delay, jitter, loss ... But, for simplicity,
I start codding these extra TE parameters as pure administrative
values. I hope finding time to see how I could render these parameters
more dynamic.
In conclusion, all these command line are printed due to historic
implementation of TE done more than 10 years ago. New one I introduce
are only printed if configured. We could go for your proposal, keep in
mind that 1/ removing 'enable' statement imply code modification in TE
parameters treatment, 2/ it will be difficult to determine if
bandwidth is default value (as it is computed from the physical
characteristic of the interface) or modified one, 3/ that some
dynamicity must be introduce.
Regards
Olivier
Le 30/11/2016 à 14:09, Donald Sharp a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Olivier -
We've noticed that link-params creates allot of config lines when you
configure any part of it. Would you mind if I change the
behavior to this:
When link-params is configured it auto starts displaying
6000-02# conf t
dell-s6000-02(config)# int swp1
dell-s6000-02(config-if)# link-params
dell-s6000-02(config-link-params)# admin-grp 0x12345678
dell-s6000-02(config-link-params)# end
dell-s6000-02# show run
interface swp1
link-params
enable
metric 0 <----Remove the metric and bw lines
max-bw 1.25e+06
max-rsv-bw 1.25e+06
unrsv-bw 0 1.25e+06
unrsv-bw 1 1.25e+06
unrsv-bw 2 1.25e+06
unrsv-bw 3 1.25e+06
unrsv-bw 4 1.25e+06
unrsv-bw 5 1.25e+06
unrsv-bw 6 1.25e+06
unrsv-bw 7 1.25e+06
admin-grp 305419896
exit-link-params
!
I'd like to reduce this to:
interface swp1
link-params
enable
admin-grp 0x12345678 <----- Fix this to be what we entered
exit-link-params
!
Finally do we need to display the enable line as well?
donald
</pre>
</blockquote>
<pre
wrap="">_________________________________________________________________________________________________________________________
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.
_______________________________________________
cmaster-next mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:cmaster-next@lists.nox.tf">cmaster-next@lists.nox.tf</a>
<a class="moz-txt-link-freetext"
href="https://lists.nox.tf/listinfo/cmaster-next">https://lists.nox.tf/listinfo/cmaster-next</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></blockquote>
</div>
</div>
</body>
</html>