Hi Chirs,
gadag_root.localroot will remain as None at the end of algorithm and
gadag_root.block_id will be 0 (rest of the nodes in the block will be 1 higher
than gadag_root.block_id)
Below psudocode will return false while comparing a node in a block and
gadag_root.
Please correct me if I am wrong.
In_Common_Block(x, y)
if ( (x.block_id is y.block_id)
or (x is y.localroot) or (y is x.localroot) )
return true
return false
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
From: Chris Bowers [mailto:[email protected]]
Sent: 22 June 2015 03:08
To: Anil Kumar S N (VRP Network BL); Gábor Sándor Enyedi;
[email protected]; Alia Atlas; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
Anil,
Thanks. With respect to comment 1, I think your description is the expected
behavior for block-ids. The localroot for a given block will not have the same
block-id as the rest of the nodes in the block. This is taken into account in
In_Common_Block() which not only compares block-ids, but also checks if either
node is the localroot for the other node. It was not initially obvious to me
why it was done this way, but if you think about a topology where a given node
is the localroot for two different blocks, it makes sense that the localroot
can't share the same block-id with both blocks. Therefore, the simplest thing
is to have the localroot not share the block-id with either of the blocks.
I incorporated comment 2 in the github commit at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/b5d1fe5354d44e9416f27b0fac1f99a66e54a79c
Chris
From: Anil Kumar S N (VRP Network BL) [mailto:[email protected]]
Sent: Sunday, June 21, 2015 8:07 AM
To: Chris Bowers; Gábor Sándor Enyedi;
[email protected]<mailto:[email protected]>; Alia Atlas;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
HI Authors,
Comment 1:
In below topology if [R] is the local root of the topology, Block id of R is 0
and Block ID of all other nodes in the topology as per psudo-code, I feel it
should be 0/1 for all.
When Assign_Block_ID is invoked, root gets the blockid 0, then since first DFS
child local root is GADAG root block id is incremented to 1 and assigned, for
all other DFS child block-id
Is assigned without incrementing it gets the value 1.
[E]----|
(5,0) |
| |
| |
[R] [D]---[C]
(0,0) (4,0) (3,0)
| |
| |
[A]---------[B]
(1,0) (2,0)
global_var: max_block_id
Assign_Block_ID(x, cur_block_id)
x.block_id = cur_block_id
foreach DFS child c of x
if (c.local_root is x)
max_block_id += 1
Assign_Block_ID(c, max_block_id)
else
Assign_Block_ID(c, cur_block_id)
max_block_id = 0
Assign_Block_ID(gadag_root, max_block_id)
Comment 2: "This is necessary for the DFS in
Lowpoint_Visit above, where the selection order of the interfaces to
explore results in different trees."
This sentence can be changed,
"This is necessary for the DFS in Lowpoint_Visit as per section 4.3. , where
the
selection order of the interfaces to explore results in different trees."
5.1. Interface Ordering
To ensure consistency in computation, all routers MUST order
interfaces identically down to the set of links with the same metric
to the same neighboring node. This is necessary for the DFS in
Lowpoint_Visit above, where the selection order of the interfaces to
explore results in different trees. Consistent interface ordering is
also necessary for computing the GADAG, where the selection order of
the interfaces to use to form ears can result in different GADAGs.
It is also necessary for the topological sort described in
Section 5.8, where different topological sort orderings can result in
undirected links being added to the GADAG in different directions.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
