Stewart, I added the following text to the algorithm draft to address this point.
Chris https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/4ae44182092f13b769834e73150837824c5b0047 It is expected that an operator will designate a set of routers as good choices for selection as GADAG root by setting the GADAG Root Selection Priority for that set of routers to lower (more preferred) numerical values. If the router currently selected as GADAG root becomes unreachable in the IGP topology, then a new GADAG root will be selected. Changing the GADAG root can change the overall structure of the GADAG as well the paths of the red and blue MRT trees built using that GADAG. In order to minimize change in the associated red and blue MRT forwarding entries that can result from changing the GADAG root, it is RECOMMENDED that operators prioritize for selection as GADAG root those routers that are expected to consistently remain part of the IGP topology. -----Original Message----- From: Stewart Bryant [mailto:[email protected]] Sent: Wednesday, December 23, 2015 6:33 AM To: Chris Bowers <[email protected]>; [email protected]; [email protected]; Alvaro Retana <[email protected]> Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture On 21/12/2015 14:47, Chris Bowers wrote: > Steward, > > I don't agree with the initial statement that the technique forms two trees > rooted at a single node. The designation of the GADAG root plays an > important role in computing the red and blue MRT trees. However, red and > blue MRT trees are computed using forward SPFs rooted at each source, which > follow the directed links on the GADAG and do not propagate past the GADAG > root. The net result of these computations can be viewed as producing red > and blue MRT trees rooted at each destination. In any case, these trees are > not rooted at the GADAG root. Ah, OK. However the GADAG root can move, does that not have an impact on the repair topology? It sounds from the above as if it might since you say you say that the root sets a propagation limit. - Stewart > > Anil pointed out that the pseudo-code in draft-ietf-rtgwg-mrt-frr-algorithm > didn't always make a clear distinction between the root of the forward SPF > computation and the GADAG root, so we tried to clarify that in this set of > changes. > > https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/a > da619050ec9d773b7919a1c622f068d5a5a5e88 > > Are there places in the architecture document where similar clarifications > should be made? > > Chris > > -----Original Message----- > From: rtgwg [mailto:[email protected]] On Behalf Of Stewart > Bryant > Sent: Friday, December 04, 2015 9:55 AM > To: [email protected]; [email protected]; Alvaro > Retana <[email protected]> > Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture > > Another couple of comments on this draft. > > The technique you use of selecting a single node and forming two trees rooted > at that node should really be noted up front in the summary. > > A consequence of this is that when you add a node or when the root node fails > the trees and hence the FRR paths may change. To some extent this happens in > LFA and RLFA, although the changes will tend to be confined to a local > region, whereas with MTR I think that the node may move to a completely > different region. If that is the case then that has an impact on the FRR > traffic management. By way of comparison, NV is the least impacted by this > approach and the SR approach is impacted as much as LFA, but has the option > of correcting this will a little effort. > > I think that there really needs to be some text on the matter in the > architecture spec. > > - Stewart > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
