[cmaster-next] link-params sub mode
Lou Berger
lberger at labn.net
Wed Nov 30 14:27:51 EST 2016
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:
> 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 <lberger at labn.net> wrote:
>> 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