Hi Chris
That looks good.
Stewart
On 23/12/2015 17:59, Chris Bowers wrote:
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
