<html>
<head>
<meta http-equiv="Content-Type" content="text/html"/>
</head>
<body>
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black;">Hi Olivier, </p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"><br></p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">On
December 1, 2016 8:02:48 AM <olivier.dugeon@orange.com> wrote:</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">>
Hi Lou,<br>
><br>
> OK. I understand. You are more in mind the way Junper router are
working compared to how Cisco router are configured.<br>
></p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">Lcps actually. I think the yang
models being developed in the ietf work this way too, but has been a bit
since I checked.</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"><br>
> Well, I'll try to elaborate a solution and made some proposition.<br>
></p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">Thank you!<br>
Lou<br>
</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"><br>
> Regards<br>
><br>
> Olivier<br>
><br>
><br>
> Le 01/12/2016 à 12:03, Lou Berger a écrit :<br>
>><br>
>> 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...<br>
>><br>
>> Lou<br>
>><br>
>> On December 1, 2016 4:42:08 AM <olivier.dugeon@orange.com>
wrote:<br>
>><br>
>>> Hi Lou, Donald,<br>
>>><br>
>>> Indeed, the original OSPF-TE code only add extra link
parameters management in the OSPFD daemon.<br>
>>><br>
>>> 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>
>>><br>
>>> 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.<br>
>>><br>
>>> I hope this is convenient. If not, just let me know how you
would manage this and I'll modify the code accordingly.<br>
>>><br>
>>> Regards<br>
>>><br>
>>> Olivier<br>
>>><br>
>>><br>
>>> Le 30/11/2016 à 20:27, Lou Berger a écrit :<br>
>>>> ahh, good. Then OSPF TE should really be enabled on
a<br>
>>>> per interface<br>
>>>> basis and not implicitly based on if TE parameters are
defined for an<br>
>>>> interface...<br>
>>>><br>
>>>><br>
>>>> On 11/30/2016 2:10 PM, Donald Sharp wrote:<br>
>>>>> The data is stored in zebra and passed up to<br>
>>>>> interested protocols if I<br>
>>>>> read the code correctly.<br>
>>>>><br>
>>>>> donald<br>
>>>>><br>
>>>>> On Wed, Nov 30, 2016 at 1:56 PM, Lou Berger
<lberger@labn.net> wrote:<br>
>>>>>> Jumping in in the middle here, sorry but having
been<br>
>>>>>> down this road a<br>
>>>>>> couple of times before... IMO link
parameters really need to go into<br>
>>>>>> common objects shared by all protocols (OSPF-TE,
ISIS-TE, RSVP-TE...) -<br>
>>>>>> and should also allow dynamic updates/exchanges by
and between the<br>
>>>>>> protocols. In past implementations we've
called this set of objects and<br>
>>>>>> associated functions Link Management.<br>
>>>>>><br>
>>>>>><br>
>>>>>> On 11/30/2016 1:41 PM, olivier.dugeon@orange.com
wrote:<br>
>>>>>>> Hello Donald,<br>
>>>>>>><br>
>>>>>>> Well, this part of the code has been fully
re-write by Paul, and I'm<br>
>>>>>>> more or less confident with it.<br>
>>>>>>><br>
>>>>>>> First, Paul introduce a new sub-command with
the link-params which has<br>
>>>>>>> broke the way vtysh handle this part. I patch
vtysh to circumvent the<br>
>>>>>>> issue, but it breaks the possibility to list
the command in<br>
>>>>>>> alphabetical order. So, don't hesitate to
change this if you find a<br>
>>>>>>> better solution.<br>
>>>>>>><br>
>>>>>>> Then, I think you could remove the 'enable'
statement, but I'm afraid<br>
>>>>>>> that it breaks the code. Let me explain. When
parsing the<br>
>>>>>>> configuration file, the 'enable' statement
serves to determine if<br>
>>>>>>> Traffic Engineering information are active or
not for this interface.<br>
>>>>>>> If inactive, the OSPF or ISIS protocol will
not generate LSA or LSP<br>
>>>>>>> for this interface with TE parameters. Do, if
you remove the enable<br>
>>>>>>> statement, you must change the code to check
if 'link-param' statement<br>
>>>>>>> is there or not. Or replace 'link-param' by
'link-param enable'<br>
>>>>>>> command, but I'm not sure that it is good.<br>
>>>>>>><br>
>>>>>>> Finally, concerning the bandwidth parameters,
it is historical. The<br>
>>>>>>> first TE implementation in OSPF print all TE
parameters once enable. I<br>
>>>>>>> agree that we could mask them, but, how to
differentiate the default<br>
>>>>>>> parameter from the modified one ? Another
solution, is to used a<br>
>>>>>>> reduce command that just allow the user to
modify globally the<br>
>>>>>>> bandwidth like Juniper or Cisco offer. In
fact, some bandwidth<br>
>>>>>>> parameters are directly computed based on what
the interface could<br>
>>>>>>> physically do. Then, you could modify these
values in order to reduce<br>
>>>>>>> the amount of bandwidth announced, and thus
allocated for TE. However,<br>
>>>>>>> these values are then updated automatically by
the router when a TE<br>
>>>>>>> tunnel is setup. As Quagga doesn't yet support
RSVP-TE, there is no<br>
>>>>>>> process that modify the bandwidth value
instead of command line. Some<br>
>>>>>>> other parameters are purely administrative
like the TE metric. So,<br>
>>>>>>> only modify by command line. And finally, some
parameters are issue<br>
>>>>>>> from measurement like the delay, jitter, loss
... But, for simplicity,<br>
>>>>>>> I start codding these extra TE parameters as
pure administrative<br>
>>>>>>> values. I hope finding time to see how I could
render these parameters<br>
>>>>>>> more dynamic.<br>
>>>>>>><br>
>>>>>>> In conclusion, all these command line are
printed due to historic<br>
>>>>>>> implementation of TE done more than 10 years
ago. New one I introduce<br>
>>>>>>> are only printed if configured. We could go
for your proposal, keep in<br>
>>>>>>> mind that 1/ removing 'enable' statement imply
code modification in TE<br>
>>>>>>> parameters treatment, 2/ it will be difficult
to determine if<br>
>>>>>>> bandwidth is default value (as it is computed
from the physical<br>
>>>>>>> characteristic of the interface) or modified
one, 3/ that some<br>
>>>>>>> dynamicity must be introduce.<br>
>>>>>>><br>
>>>>>>> Regards<br>
>>>>>>><br>
>>>>>>> Olivier<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Le 30/11/2016 à 14:09, Donald Sharp a écrit :<br>
>>>>>>>> Olivier -<br>
>>>>>>>><br>
>>>>>>>> We've noticed that link-params creates
allot of config lines when you<br>
>>>>>>>> configure any part of it. Would you
mind if I change the<br>
>>>>>>>> behavior to this:<br>
>>>>>>>><br>
>>>>>>>> When link-params
is configured it auto starts displaying<br>
>>>>>>>> 6000-02# conf t<br>
>>>>>>>>
dell-s6000-02(config)# int swp1<br>
>>>>>>>>
dell-s6000-02(config-if)# link-params<br>
>>>>>>>>
dell-s6000-02(config-link-params)# admin-grp 0x12345678<br>
>>>>>>>>
dell-s6000-02(config-link-params)# end<br>
>>>>>>>> dell-s6000-02#
show run<br>
>>>>>>>><br>
>>>>>>>> interface swp1<br>
>>>>>>>> link-params<br>
>>>>>>>> enable<br>
>>>>>>>> metric
0
<----Remove the metric and bw lines<br>
>>>>>>>> max-bw
1.25e+06<br>
>>>>>>>>
max-rsv-bw 1.25e+06<br>
>>>>>>>>
unrsv-bw 0 1.25e+06<br>
>>>>>>>>
unrsv-bw 1 1.25e+06<br>
>>>>>>>>
unrsv-bw 2 1.25e+06<br>
>>>>>>>>
unrsv-bw 3 1.25e+06<br>
>>>>>>>>
unrsv-bw 4 1.25e+06<br>
>>>>>>>>
unrsv-bw 5 1.25e+06<br>
>>>>>>>>
unrsv-bw 6 1.25e+06<br>
>>>>>>>>
unrsv-bw 7 1.25e+06<br>
>>>>>>>>
admin-grp 305419896<br>
>>>>>>>>
exit-link-params<br>
>>>>>>>> !<br>
>>>>>>>><br>
>>>>>>>> I'd like to reduce
this to:<br>
>>>>>>>><br>
>>>>>>>> interface swp1<br>
>>>>>>>> link-params<br>
>>>>>>>> enable<br>
>>>>>>>>
admin-grp 0x12345678 <----- Fix this to be what we
entered<br>
>>>>>>>>
exit-link-params<br>
>>>>>>>> !<br>
>>>>>>>><br>
>>>>>>>> Finally do we need
to display the enable line as well?<br>
>>>>>>>><br>
>>>>>>>> donald<br>
>>>>>>>
_________________________________________________________________________________________________________________________<br>
>>>>>>><br>
>>>>>>> Ce message et ses pieces jointes peuvent
contenir des informations<br>
>>>>>>> confidentielles ou privilegiees et ne doivent
donc<br>
>>>>>>> pas etre diffuses, exploites ou copies sans
autorisation. Si vous avez recu<br>
>>>>>>> ce message par erreur, veuillez le signaler<br>
>>>>>>> a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages<br>
>>>>>>> electroniques etant susceptibles d'alteration,<br>
>>>>>>> Orange decline toute responsabilite si ce
message a ete altere, deforme ou<br>
>>>>>>> falsifie. Merci.<br>
>>>>>>><br>
>>>>>>> This message and its attachments may contain
confidential or privileged<br>
>>>>>>> information that may be protected by law;<br>
>>>>>>> they should not be distributed, used or copied
without authorisation.<br>
>>>>>>> If you have received this email in error,
please notify the sender and<br>
>>>>>>> delete this message and its attachments.<br>
>>>>>>> As emails may be altered, Orange is not liable
for messages that have been<br>
>>>>>>> modified, changed or falsified.<br>
>>>>>>> Thank you.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>
_______________________________________________<br>
>>>>>>> cmaster-next mailing list<br>
>>>>>>> cmaster-next@lists.nox.tf<br>
>>>>>>> <a
href="https://lists.nox.tf/listinfo/cmaster-next">https://lists.nox.tf/listinfo/cmaster-next</a><br>
>>><br>
>>>
_________________________________________________________________________________________________________________________<br>
>>><br>
>>> Ce message et ses pieces jointes peuvent contenir des
informations<br>
>>> confidentielles ou privilegiees et ne doivent donc<br>
>>> pas etre diffuses, exploites ou copies sans autorisation. Si
vous avez recu<br>
>>> ce message par erreur, veuillez le signaler<br>
>>> a l'expediteur et le detruire ainsi que les pieces jointes.
Les messages<br>
>>> electroniques etant susceptibles d'alteration,<br>
>>> Orange decline toute responsabilite si ce message a ete
altere, deforme ou<br>
>>> falsifie. Merci.<br>
>>><br>
>>> This message and its attachments may contain confidential or
privileged<br>
>>> information that may be protected by law;<br>
>>> they should not be distributed, used or copied without
authorisation.<br>
>>> If you have received this email in error, please notify the
sender and<br>
>>> delete this message and its attachments.<br>
>>> As emails may be altered, Orange is not liable for messages
that have been<br>
>>> modified, changed or falsified.<br>
>>> Thank you.<br>
><br>
><br>
>
_________________________________________________________________________________________________________________________<br>
><br>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc<br>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler<br>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,<br>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.<br>
><br>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;<br>
> they should not be distributed, used or copied without authorisation.<br>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.<br>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.<br>
> Thank you.<br>
><br>
</p>
</div>
</body>
</html>