[cmaster-next] link-params sub mode
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
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.
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@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@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next
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@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@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@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next
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@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@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@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next
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@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@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@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.
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@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@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@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@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.
Hi Lou, OK. I understand. You are more in mind the way Junper router are working compared to how Cisco router are configured. Well, I'll try to elaborate a solution and made some proposition. 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@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@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@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@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.
Hi Olivier, On December 1, 2016 8:02:48 AM <olivier.dugeon@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@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@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@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@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.
participants (3)
-
Donald Sharp -
Lou Berger -
olivier.dugeon＠orange.com