Hi Feng,
On 12/17/14, 11:09 PM, "Feng Lu" <[email protected]> wrote:
>Hi Vipin,
>
>Sorry for mis-reading the code.
No worries at all. In fact, I truly appreciate you going through the code
and giving useful feedback.
>
>I have started "router ospf" and "router ospf X" manually without
>init.d/quagga script, and let them co-work correctly.
Great.
>
>Would you please think of supporting the instance ID 0 in MI mode
>again?
Do you see no value in a keyword less option of show/debug commands
working for all the ospf daemons? The example I gave in my previous email
:)
>
>It would not be a big issue if no. But that will bring the users
>a little trouble in switching from single-instance mode to multi-
>instance mode if they are using vtysh.
>
>One must be facing choices:
>
>a) Either he must update his configuration files and all relative
>management tools to add an instance ID now to change the original
>"ospf" to "ospf 1" - this takes instant extra effort which he
>may not want;
>b) Or he must give up using vtysh, and develop a tool by himself.
>
> From my point of view, it's important to keep the backward
>compatibility in the way of configuration.
I don¹t deny that the backward compatibility is good in general. And must
in some cases. That¹s why the patch has the single daemon mode working as
before.
For the MI mode bring-up, I am not sure if a user willing to move to the
multi-instance deployment, would mind some changes.
And one more (possibly lame;) point from me here..
When we see ..
router ospf
router ospf 1
router ospf 2
router ospf 10
..
It does give a sense as if router ospf¹ is some global daemon of some
sort covering for all others. Which it wont be.
Primarily, to me it goes to the fact that in MI mode, when commands don¹t
have <instance-id> specification, it covers all the instances (in general)
is a good simplification at the cost of making users do a bit in first
time transition.
Not sure if I am the only one thinking in this direction.
>
>BTW: please don't forget to give an offset to the port for MI mode.
Yeah thanks for that. I will ack your code-review comments in the other
email soon.
>
>And is there a better way to show instance ID? (I have no yet,
>sorry ;))
>
>ubuntu# show ip route
>Codes: K - kernel route, C - connected, S - static, R - RIP,
>O - OSPF, I - IS-IS, B - BGP, A - Babel, T - Table,
> > - selected route, * - FIB route
>
>K>* 0.0.0.0/0 via 10.0.2.2, eth0
>C>* 10.0.2.0/24 is directly connected, eth0
>C>* 10.1.0.1/32 is directly connected, loopback
>O 100.2.0.0/24 [110/10] is directly connected, eth1, 00:10:38
>C>* 100.2.0.0/24 is directly connected, eth1
>O[1] 100.9.0.0/24 [110/10] is directly connected, eth2, 00:05:42
>C>* 100.9.0.0/24 is directly connected, eth2
>O>* 101.2.0.0/24 [110/20] via 100.2.0.1, eth1, 00:08:36
>O[1]>* 101.9.0.0/24 [110/20] via 100.9.0.1, eth2, 00:00:22
Given its a short form command, couldn¹t think of finding any more concise
way.
Maybe format it better? And keep space for instance-id whether its there
or not.
K >* 0.0.0.0/0 via 10.0.2.2, eth0
C >* 10.0.2.0/24 is directly connected, eth0
C >* 10.1.0.1/32 is directly connected, loopback
O 100.2.0.0/24 [110/10] is directly connected, eth1, 00:10:38
C >* 100.2.0.0/24 is directly connected, eth1
O[ 1] 100.9.0.0/24 [110/10] is directly connected, eth2, 00:05:42
C >* 100.9.0.0/24 is directly connected, eth2
O >* 101.2.0.0/24 [110/20] via 100.2.0.1, eth1, 00:08:36
O[ 1]>* 101.9.0.0/24 [110/20] via 100.9.0.1, eth2, 00:00:22
Or O-1 ?
Or group them properly by protocol and instance-id ? Might mean quite some
work to achieve this one though :(
K>* 0.0.0.0/0 via 10.0.2.2, eth0
C>* 10.0.2.0/24 is directly connected, eth0
C>* 10.1.0.1/32 is directly connected, loopback
C>* 100.2.0.0/24 is directly connected, eth1
C>* 100.9.0.0/24 is directly connected, eth2
O 100.2.0.0/24 [110/10] is directly connected, eth1, 00:10:38
O>* 101.2.0.0/24 [110/20] via 100.2.0.1, eth1, 00:08:36
O [1]
100.9.0.0/24 [110/10] is directly connected, eth2, 00:05:42
>* 101.9.0.0/24 [110/20] via 100.9.0.1, eth2, 00:00:22
Thanks,
Vipin
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
