Subject: comments on draft-li-rtgwg-ldp-mt-mrt-frr

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

I've done a read through on this draft and have the following comments:

In Sec 3.1: "If there is no secondary route of LFA, the blue topology is
preferred since it can be protected again by the red topology."
This is incorrect. Please read the more recent
draft-ietf-rtgwg-mrt-frr-architecture<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-mrt-frr-architecture/>
 and draft-enyedi-rtgwg-mrt-frr-algorithm<http://tools.ietf.org/id/draft-enyedi-rtgwg-mrt-frr-algorithm-02.txt>
;
the method for computing which of the blue and red MRT to use as the
alternate is clearly specified.  The idea of failing from the blue
topology to the red was only in the very initial work - since then Gabor
figured out (and I've verified in an analysis tool) how to precompute
whether the blue or red provides protection.

Similarly, in Sec 3.3: "For the blue topology, the secondary label
forwarding entry is created according to the secondary route in the red
topology."
Again, the blue topology routes do not have alternates. Neither do the red
topology. Only the primary SPF topology has alternates.

In Sec 3.4, the reason to delay installing new MRT routes is NOT because of
slowing down the SPF topology reconvergence, but rather because
the MRT topologies are carrying traffic and shouldn't be disrupted until
the new SPF routes are installed everywhere so that traffic is moved off of
the MRT topologies.

In Sec 3.5, do you anticipate that LDP will be running in other than
Downstream Unsolicited Liberal Label Retention mode? In that mode, the
necessary labels should already be learned.

In Sec 3.6 "IGP MT and LDP MT", I'm not sure what point you are trying to
make. Is it that in OSPF, different link topologies are used for IPv4 and
IPv6 and therefore different MT-IDs should be used as well -i.e. a Blue
IPv6 MT-ID and a Blue IPv4 MT-ID? In as much as MT-IDs are used by the IGP,
they would be associated just with loopback addresses - which could clearly
be either IPv4 or IPv6 to disambiguate. For LDP, both types of FECs can use
the same MT-ID. Do you see other issues here? Using well-known and reserved
MT-IDs for MRT makes the most sense to me - ones that are the same for the
IGP and LDP. Rather than discussing the issues, I'd specify the desired
solution and reasoning for why it works well.

In Sec 3.7 "Multiple IGP", I do know that running multiple IGPs is not
uncommon. I don't see a reason why this causes a problem with MRT. If one
assumes there are consistent rules for which IGP provides a route across
the network, those same rules can be used to populate the MRT topologies.
Can you clarify a scenario where this would not apply or be sufficient?

In Sec 3.8 "Label Space", certainly MRT requires additional LDP labels -
but how many depends on whether per-prefix FECs are advertised and on
whether LDP traffic as well as IP traffic needs to be protected.

In Sec 3.9 "Proxy Egress", it says: "In several scenarios where MRT FRR is
deployed, proxy egress LSPs have to be setup by LDP. The proxy egress LSP
maybe not end-to-end to bear VPN service in the network." I am unclear on
what you are talking about here. In the computation, there are proxy nodes
to represent FECs outside the local area/level; in the actual usage, there
are no additional LDP labels needed. Instead, the appropriate Blue or RED
label for the actual node transited to reach the proxy egress node should
be used. In other words, if a proxy egress is connected to ABR-1 and ABR-2
and the Blue MRT goes through ABR-1 and the Red MRT goes through ABR-2 to
reach the proxy egress, the Blue MRT label advertised by ABR-1 for that FEC
would be used.

In Sec 3.11, it's good to see thought about LDP DoD mode - but the required
labels for the blue and red MRT topologies would have to be requested in
advance of the failure to provide useful protection. I'm unclear on what
you mean by "The difference from LDP DU is that there is no label
distributed for the secondary route calculated in the default topology. The
label forwarding entry in the blue topology or the red topology will be
used as the secondary one directly."

In Sec 4.1, I'm not sure which algorithm you used to compute or what the
GADAG was. Rather than making assumptions about link costs, it'd be much
better to just show the ones used. Also, it says: "From the above
calculation example, we can see that how the tie- breaking rule has to be
applied when choose the nexthop in a specific topology and the topology
which is used for the secondary route. For the reason of simplicity, there
is no LFA calculation for the secondary route. If exists, it should be
preferred." If there are multiple options for the Blue MRT next-hops, then
it's just like ECMP - the router can pick all of them or any one without
causing difficulty. I've already talked about the rule for picking the
correct topology for the alternate.

In Sec 4.1, I personally find the example with the labels and the
associated LFIB to be quite hard to follow. Perhaps using actual label
values would help? What is interesting/special for MRT is handling label
distribution at area/level boundaries.

In Sec 4.4, it says "In order to optimize the second mechanism,when the
penultimate router receive a packet with MRT label, it can swap the label
to corresponding FEC's default topology label instead of penultimate hop
pop." That is exactly what is said in Sec 8 of
draft-ietf-rtgwg-mrt-frr-architecture-01 "The penultimate router can
determine that the ABR/LBR will forward the packet out of area/level and,
in that case, the penultimate router can remove the MRT marking but still
forward the packet along the MRT next-hop to reach the ABR." However, the
first mechanism where the ABR/LBR provides different LDP labels to the
different areas/levels is STRONGLY preferred. It avoids the need for all
neighboring routers to understand and recompute what area/level the ABR/LBR
has selected - and all the associated interoperability problems that could
come from that.

In Sec 4.4, it talks about label distribution to/from a proxy node! This
makes no sense to me. The proxy node is there for the MRT graph algorithm
to run - it isn't instantiated by one of the routers. I'm sure you're
trying to make a point here, but I do not understand it.

In Sec 4.5, again there's the idea that the proxy node has to have labels
advertised to and from it. I believe that the border routers of the MRT
island can properly install the next-hop to outside the MRT island as
computed based on whether the packet is received with the Blue label or the
Red label.

Can you clarify what you are concerned about in Sec 4.6? Nodes that don't
support LDP and are hidden from the IGP topology by TE links don't need to
support MRT at all...

In general, what I see lacking in this draft is anything specifying the
extensions, algorithms or methods needed to support MRT using LDP?? I can
see the usefulness of something that references the LDP multi-topology
draft and defines the necessary behavior for MRT support. I can see the
need to potentially advertise capabilities... I do see that this draft is
intended for Informational, but I'm not personally seeing what areas you
feel it is significantly amplifying from what is in
draft-ietf-rtgwg-mrt-frr-architecture.

Regards,
Alia