Subject: comments on draft-li-rtgwg-igp-ext-mrt-frr-00

From: Alia Atlas <[email-masked]>
Date: Fri, 8 Feb 2013 14:19:34 -0500

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