[cmaster-next] link-params sub mode
Lou Berger
lberger at labn.net
Thu Dec 1 08:30:05 EST 2016
Hi Olivier,
On December 1, 2016 8:02:48 AM <olivier.dugeon at orange.com> wrote:
> Hi Lou,
>
> OK. I understand. You are more in mind the way Junper router are working
> compared to how Cisco router are configured.
>
Lcps actually. I think the yang models being developed in the ietf work
this way too, but has been a bit since I checked.
> Well, I'll try to elaborate a solution and made some proposition.
>
Thank you!
Lou
> Regards
>
> Olivier
>
>
> Le 01/12/2016 à 12:03, Lou Berger a écrit :
>>
>> 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...
>>
>> Lou
>>
>> On December 1, 2016 4:42:08 AM <olivier.dugeon at orange.com> wrote:
>>
>>> Hi Lou, Donald,
>>>
>>> Indeed, the original OSPF-TE code only add extra link parameters management
>>> in the OSPFD daemon.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> I hope this is convenient. If not, just let me know how you would manage
>>> this and I'll modify the code accordingly.
>>>
>>> Regards
>>>
>>> Olivier
>>>
>>>
>>> Le 30/11/2016 à 20:27, Lou Berger a écrit :
>>>> 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
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> 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.
>
>
> _________________________________________________________________________________________________________________________
>
> 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/20161201/e9d154d0/attachment.html>
More information about the dev
mailing list