RE: WGLC for draft-rtgwg-mrt-frr-architecture

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:stewart.bryant@gmail.com] 
Sent: Wednesday, December 23, 2015 6:33 AM
To: Chris Bowers <cbowers@juniper.net>; draft-rtgwg-mrt-frr-architecture@tools.ietf.org; rtgwg@ietf.org; Alvaro Retana <aretana@cisco.com>
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:rtgwg-bounces@ietf.org] On Behalf Of Stewart 
> Bryant
> Sent: Friday, December 04, 2015 9:55 AM
> To: draft-rtgwg-mrt-frr-architecture@ietf.org; rtgwg@ietf.org; Alvaro 
> Retana <aretana@cisco.com>
> 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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg