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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
