I have read through this draft and have a number of comments.
First, to simplify the signaling needed and reduce on-the-fly checking and
computation of an MRT island,
it would be preferable to have "well-known profiles" represented by
particular flags. A profile that would be
useful is something like:
Blue MRT MT-ID: X
Red MRT MT-ID: Y
Supported Algorithm: lowpoint inheritance
GADAG selection: highest router ID
encapsulation: IP in LDP
fast-reroute supported for: IPv4, IPv6, and LDP
That would be a good profile for unicast - and minimize the options and
determination for an MRT island.
We'll need something similar for multicast fast-reroute and multicast
live-live.
Having a detailed sub-TLV that gives the detailed options may be useful in
the future, if there is disagreement
on what are appropriate profiles. I can see having a bit indicating that
the details supported are given in the
sub-TLV for the future.
The Algorithm ID should be a value and not a bit-flag. If there are
multiple bits set, then clear rules need to be
given as to which algorithm would be picked and why.
In general, if multiple profiles are specified or multiple options, the
draft needs to give a clear algorithm for
what and how an MRT island is created.
Certainly, MRT needs ISIS and OSPF extensions to define the signaling, but
I find this draft a bit naive in
simply taking what is in the
draft-ietf-rtgwg-mrt-frr-architecture<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-mrt-frr-architecture/>
and
turning it into the protocol parts without
fully thinking through the implications and rules to be used.
Alia
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
