Re: [Rift] cc: from private thread, flooding rules ...

[Tony Przygienda <[e-mail]>]

On Tue, Apr 30, 2019 at 2:02 AM <[e-mail]> wrote:

>
> Tony,
>
> Thanks for your reply.
>

Xu, my pleasure ;-)


>
> 1. It's not a standard Fat Tree,  NODE3 has only one north neighbor NODE1,
> and NODE4 has a north neighbor NODE2. So when link between NODE1 and NODE3
> be down, HAL of NODE3 changes from 10 to 9.
>

ok, what's the link nod3-node4 and node1-node2? horizontal links? if node3
is down, it cannot have a HAL so I try to still interpret it. Basically, if
you are thinking about Node1 _OR_ Node2 going away then the other node will
always seed. let's assume node1 died, then you'll see

Node2
|
Node4
|
Node3

hierarchy being built which is intended. if e.g. node3 goes down, your
network is partitioned. there will be two networks

node1-node2
 |
node4

rest will not be able to obtain a seed (basically without a ToF node you
can't build up a fabric using ZTP since you simply don't know what is up
and what is down)


>
> NODE1-----NODE2
>
> |                 |
>
> |                 |
>
> NODE3-----NODE4
>
> |
>
> |
>
> NODE5 ......
>
> |
>
> |
>
> NODE6 ......
>
>
> ZTP is very good for network initialization. If ZTP is working all the
> way, it may be used limited for security reason. Any new higher level node
> connect in network or last hightest level neighbor get down may cause
> network rebuild. It will easy to be attacked, so I think it's better to
> work in a node start stage.
>

I think the security section explains very well the trade-off between
security needs and ZTP possible ... This is nothing special for RIFT, it's
universal.


>
> 2. Aboute mobility attributes, the leaf is dispatch address route with 32
> mask and connect route with shorter mask, wether is it support mobility
> prefix can be controlled.
>

I can't parse that really. Does RIFT support overlapping prefixes? Yes,
sure. if the /32 moves then it will be a more specific match. The problem
is obviously here if traffic forwarded out a PoD hits a match southbound on
aggregate while the more specific moved into another PoD. Then it will
greedily blackhole. Again, nothing specific for RIFT really, aggregates
blackhnole if they attract traffic they cannot route. Multiple solutions
exist. Such prefixes could be leaked south e.g. but question is really, WHY
would you need aggregates since RIFT automatically aggregates/de-aggregates
for you in sufficient fashion. An example would be good.


>
> 3. >  Yes, it would be possible to configure PoDs by KV but I don't see
> that  as being much different from configuring it on the device itself. The
> KV  would need to be directed so the node knows it is being targeted. Level
>  you cannot get from KV ;-) since you can't form 3-way until you have
>  level (observe that LIEs carry the level offers and with that levels are
>  negotiated to form 3-way). And you can't flood KV until you have an
>  established topology.
>
>
> If we support get configuration by KV tie, the network can be easy control
> by ToF node manual or automatic. ToF(s) can learn network topology by N-TIE
> and send node level and pods by KV tie to them after ZTP stage to confirm
> the network stable. Or the network can be centrol controlled by TOF, The
> controler don't need rember the ip addr of every node.
>

Well, you CAN'T send level from ToF since you won't have 3-way adjacencies
and with that flooding ;-) You need ZTP working first which will establish
level and then you _could_ send PoD to specific nodes via KV, that's true
but it's really _per_ node while KV is pruned flooding so it's bit tricky
since you need to flood to the "level of the PoD" and then prune. But
again, picutre/example would be good.


>
> 4. About the KV struct,  I am not fit the thrift very well, and I'll learn
> about it:-)
>
sure, thrift is widely deployed, stable, elegant, powerfull and easy so
it's worth learning ;-)  It vacuums the floors as well but that's a hidden
feature :-P


>
>
> 5. I have checked Bruno's python code, there is no this problem
>
> process_rx_tie_packet_info
>
>             elif comparison > 0:
>
>                 # We have a newer version of the TIE, send it
>
>                 start_sending_tie_header = db_tie_packet.header
>
>
thanks for that. Like I said, good amount of people were in the weekly
meetings & we chewed the flooding rules over and over again ;-) while they
have been implemented to make sure we don't miss stuff. So we probably
talked through that in detail, agreed and then it was me who miswrote then
in the throes of editorship'ing ;-) on one of the iterations since both
implementations did the correct thing while the spec was wrong as you
pointed out. Again, great catch ;-)

--- tony