[cmaster-next] link-params sub mode

[olivier.dugeon at orange.com]

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 :
> 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


_________________________________________________________________________________________________________________________

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20161130/415ac250/attachment.html>