[cmaster-next] link-params sub mode

Lou Berger lberger at labn.net
Wed Nov 30 13:56:56 EST 2016


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, olivier.dugeon at orange.com wrote:
>
> 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.
>
>
> _______________________________________________
> cmaster-next mailing list
> cmaster-next at lists.nox.tf
> https://lists.nox.tf/listinfo/cmaster-next





More information about the dev mailing list