[cmaster-next] link-params sub mode

Wed Nov 30 14:10:10 EST 2016

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
>