On 12/18/2014 04:15 PM, Vipin Kumar wrote:
Hi Feng,
On 12/17/14, 11:09 PM, "Feng Lu"<[email protected]> wrote:
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
:)
Yes, I see. I really understanding why you choose the current
approach, because that was ever one of the approaches of 6WIND
VRF patch. :)
I did not say which is better. I just want more voice so that
the maintainers can have more references before making the
decision.
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.
I'm not sure how users will treat the keyword "ospf" without an
instance ID present.
And from my own point of view, "debug ospf" for all instances
introduces more possibility of mis-configuration.
6WIND choose to let "ospf" equivalent to "ospf vrf 0". If users
choose to operate on all instance, they must explicitly use
"ospf vrf all" to avoid the mis-configuration.
Well, I know different people always stand on different point
of view. So what I want is NOT to defeat somebody, but to let
my voice be heart by more people to get more understanding
before they make decisions. Peace only, no war. :)
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
Seems not good :(
How about moving instance ID after the [distance/metric] field?
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 100.9.0.0/24 [110/10] [i:1] 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>* 101.9.0.0/24 [110/20] [i:1] via 100.9.0.1, eth2, 00:00:22 <==
as 6WIND VRF patch does:
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 100.9.0.0/24 [110/10] [vrf 1] 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>* 101.9.0.0/24 [110/20] [vrf 1] via 100.9.0.1, eth2, 00:00:22
Waiting for opinion from others.
Thanks and best regards,
Feng Lu
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
