RE: WGLC for draft-rtgwg-mrt-frr-architecture
<bruno.decraene@orange.com> Tue, 08 December 2015 14:50 UTC
Return-Path: <bruno.decraene@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E81B2EB4 for <rtgwg@ietfa.amsl.com>; Tue, 8 Dec 2015 06:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.308
X-Spam-Level:
X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ1US3AuihG9 for <rtgwg@ietfa.amsl.com>; Tue, 8 Dec 2015 06:50:00 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FC21B2EA4 for <rtgwg@ietf.org>; Tue, 8 Dec 2015 06:49:59 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 8DAE7C0967; Tue, 8 Dec 2015 15:49:57 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 2D7281A008D; Tue, 8 Dec 2015 15:49:57 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 15:49:56 +0100
From: bruno.decraene@orange.com
To: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Topic: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Index: AQHRLff/OG2l5ZYqq0Km/2NhVgzqi569VdYAgAGG8oCAAAEXgIAABO+AgAIXR9CAACSycA==
Date: Tue, 08 Dec 2015 14:49:56 +0000
Message-ID: <21567_1449586197_5666EE15_21567_14680_1_53C29892C857584299CBF5D05346208A0F6F7476@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <56608847.9040505@gmail.com> <327562D94EA7BF428CD805F338C31EF06C08630C@nkgeml512-mbx.china.huawei.com> <5665685D.2020507@gmail.com> <56656947.1070307@gmail.com> <56656D6B.6010600@gmail.com> <327562D94EA7BF428CD805F338C31EF06C0865EE@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <327562D94EA7BF428CD805F338C31EF06C0865EE@nkgeml512-mbx.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F6F7476OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/sbjZZjtvt50kKie0pIjZVV13MfA>
Cc: "draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org" <draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Mike Shand <mike@mshand.org.uk>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 14:50:11 -0000
Hi Anil, Since you have cited me, I’m probably forced to join the discussion. As a disclaimer, as already expressed, for spring capable networks, I personally believe that TI-LFA is the best solution. So I’m not sure that you involved the right guy to support MRT ;-) As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE…) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS)) So there may be a question whether the IETF: a) is fine with documenting multiple/many, independent solutions, b) is fine with many solutions but want to evaluate them to see which one is the best fit depending on the deployment case c) whether we need to choose N solutions based on technical merits Personally, I don’t really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that “a” had been chosen. May be “b” would make sense, assuming I’m not the one doing the job ;-) . I’m afraid “c” would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the “right” value for N, before even starting the technical evaluation) Probably the easiest path, and in particular for the mrt draft, would be to avoid comparing solutions, and definitely avoid saying that MRT is the best solution. (And I’m not saying the draft says that, but you do in the below email) Because IMHO, comparisons are difficult, long and putting this in the mrt draft is a risk to delay it (possibly forever). But I’m also fine with discussing the comparisons. It’s really up to MRT authors. At least I expect the choice to apply to all solutions (and not option “a” when RLFA or MRT is discussed, and then option “c” when TI-LFA is discussed) More inline [Bruno] From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Anil Kumar S N (VRP Network BL) Sent: Tuesday, December 08, 2015 1:07 PM To: Stewart Bryant; draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org; rtgwg@ietf.org; Alvaro Retana Cc: Mike Shand Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture Hi Stewart, Request you to see inline for reply. Thanks & Regards Anil S N “Be liberal in what you accept, and conservative in what you send” - Jon Postel From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: 07 December 2015 19:29 To: Anil Kumar S N (VRP Network BL); draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org<mailto:draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Alvaro Retana Cc: Mike Shand Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture On 07/12/2015 11:11, Stewart Bryant wrote: Resending with the correct draft alias On 07/12/2015 11:07, Stewart Bryant wrote: Hi Anil Please see inline. Note that here we are just discussion some of the points raised. - Stewart On 06/12/2015 04:38, Anil Kumar S N (VRP Network BL) wrote: Hi Bryant, Please find my observation on your comments in line. Thanks & Regards Anil S N “Be liberal in what you accept, and conservative in what you send” - Jon Postel From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: 04 December 2015 02:22 To: draft-rtgwg-mrt-frr-architecture@ietf.org<mailto:draft-rtgwg-mrt-frr-architecture@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Alvaro Retana Subject: WGLC for draft-rtgwg-mrt-frr-architecture Resend due to problem sending to the document alias Hi, I am sorry that this review is late, but a number of personal matters needed priority. Hopefully you can accept it still. Firstly my high order bit, and I suspect I will be in the rough on this. I am not convinced that this is the best solution that we can produce to this problem, and I am concerned about the operational issues that result from the non-intuitive repair paths when compared to other methods. I am also concerned about our ability to get a solution as complicated as this right first time in all of the corner cases. Thus I think that rather than recommend this to the industry as a standard, we should issue it as informational and see how it works out at scale. =========== 1. Introduction This document gives a complete solution for IP/LDP fast-reroute [RFC5714]. MRT-FRR creates two alternate trees separate from the primary next-hop forwarding used during stable operation. These two trees are maximally diverse from each other, providing link and node protection for 100% of paths and failures as long as the failure does not cut the network into multiple pieces. SB> I am concerned that this is an overstatement. SB> Firstly you cannot handle multiple concurrent failures in SB> even simple pathological cases. If the network is two SB> connected and you have both a red and blue failure SB> that you need to traverse, you (say) commit to the red SB> the you will fail at blue transition, even though the network is SB> is still connected at the link level. [Anil >>] I don’t think once packet moved into red path will fall back to blue path in case of red path failure. No other FRR technologies can handle simultaneous multiple failure without loops[Loop may or may not occur which is unknown]. MRT is one of the FRR technologies which provide alternate path which tries to move away from failure point to reach the destination. I feel we can count on the positive advantage of MRT. SB> I do not think that is correct. SB> Methods that construct a repair to the next-hop (link) or next-next-hop (node) SB> and refuse to repair a repair can cope with some types of multiple failure. SB> For example a repair based on not-via or strict source-routing can deal SB> with concatenated repairs. They get tricky when the second failure is in the SB> repair path. Mike Shand and I looked at this but I cannot remember what the SB> outcome was. However to a limited extent I think that even that might be SB> feasible. SB> I think that what is important here is that you specify the degree of completeness SB> which is single-link, cluster of links with a single common node and node SB> failure. SB> The root cause of this constraint is the use of a pair of trees with a single root. SB> This contrasts with SR and NV which have a tree rooted at every PLR and SB> reset the repair constraint once the packet has left the repair domain. SB> As to your point about moving away from the failure, NV certainly does this SB> and with SR it depends on whether you set the repair target as the far SB> side of the failure or Q space. SB> The root cause of the loops in Q space is that you may not have used SB> a sufficiently limited estimate of Q space. However if you require that the SB> packet get to the next-next hop it is always safe to release it into a SB> network that had previously converged. [ANIL 2 >> ] I remember Bruno pointed out a simple topology with multiple failure can cause LOOP in SR, I am yet to understand Not Via Below is the topology, Where all links have a metric of 10, except AD which has 100 For the traffic from A to C, if both AC and BD links fails at the same time (and were not identified as SRLG), there will be a loop between A and B. (and funnily (is it? ;-) ) as packets are looped, the label stack seems to increase to “infinity” as additional P nodes (alternatively C and D) are used. A – B | \ | C – D So multiple failure, the behavior could be undesirable. There could many unforeseen topologies Where the extent of multiple failure and behavior might be undesired. Please check NV against this topology. MRT guarantees one thing for sure; if in case of multiple failure Packets would be dropped but it will not be looped. Which is very important, looping congests line card and will be trigger for further failures. ☺ [Bruno] Let’s compare the solutions with the same assumptions. If we are ready to support the cost of multiplying the size of the FIB, Segment Routing could probably advertise 2 SIDs per segments: one protected with FRR and one not protected. With this, TI-LFA can use non protected segments and hence chose to drop the packet in case of multiple unrelated failures. (rather than risking loops in some cases, to gain protections for unrelated failures in the other cases). For this TI-LFA would need to double the number of FIB entries, while I think that MRT triple it. Not to mention the choice is local and possibly on a per destination. SB> The text should start with the invariants and assumptions to SB> correctly scope the claims in the introduction. SB> I think you have to say where the trees are routed since only SB> two mean you need a root, and you need to note that this is SB> different from the underlying IGP in which there is a tree SB> per node. Summary Comparison of IP/LDP FRR Methods +---------+-------------+-------------+-----------------------------+ | Method | Coverage | Alternate | Computation (in SPFs) | | | | Looping? | | +---------+-------------+-------------+-----------------------------+ | MRT-FRR | 100% | None | less than 3 | | | Link/Node | | | | | | | | | LFA | Partial | Possible | per neighbor | | | Link/Node | | | | | | | | | Remote | Partial | Possible | per neighbor (link) or | | LFA | Link/Node | | neighbor's neighbor (node) | | | | | | | Not-Via | 100% | None | per link and node | | | Link/Node | | | | | | | | | TI-LFA | 100% | Possible | per neighbor (link) or | | | Link/Node | | neighbor's neighbor (node) | +---------+-------------+-------------+-----------------------------+ SB> I really wonder how important the computational complexity is SB> given that we are moving to an SDN world where these calculations SB> can be offloaded? [Anil >>] ☺ Its not wrong to claim MRT consumes much less computation compared to other FRR technologies. Be it SDN controlled or distributed. [Bruno] The point is that there are multiple/many metrics to compare solutions. Picking a subset has a risk of biasing the discussion/choices. SB> ... but it is important to consider the importance of the computation constraint. SB> In SDN you potentially have a lot more compute power available than you SB> have in the small processor/memory systems. You also have the potential SB> (due to massive storage) to maintain a history of common network states SB> and thus have the configuration of the post-failure or post-repair states SB> on file. SB> You also need to consider how long it takes to do loop-free reconvergence SB> to see whether the new state repair time calculation is a factor or not. SB> For example, if you could do 50 SPF/sec it would take 10s to run one SB> per node on a 500 node network. So then you get to the question of SB> whether the LF strategy can be executed, and its completion notifed SB> in 10s? If not, then the SPF computation time is not a factor. [ANIL 2 >> ] Let’s compare TI-LFA and MRT computation constraints, I believe MRT need less computation than TI-LFA TI-LFA need to calculate Extended P-Space for set of destination which used each other nexthop. Number of SPF directly depends on Number of Neighbors. [Bruno] Yes and no. No TI-LFA does not require to compute the extended P space. But yes, you need 1 SPF per protected interface. Yes this is a cost, but this comes with a benefit of taking the best/optimal path, for each case of failure. IMHO 1 SPF per IGP interface seems a reasonable cost to me, especially before the failure. If Node protection is desired then more computation is expected. [Bruno] Fully agreed. But this gets topology dependent. In contrary, MRT has to prepare a graph and select alternates. If preparation of GADAG is considered as one SPF then it boils down to be very simple. [Bruno] “very simple”. As a network provider, I’d rather have the solution simple to compute/understand for the human and complex to compute for the computer. Especially as human brain is not following More’s law. Yes “simple” is difficult to measure, but I’m pretty sure that if you pick 10 regulars people, give them a network topology and ask them what would be the network behavior in case of failure, then would find TI-LFA algo easier than the MRT one. Since GADAG root is fixed, If central controller in place, if controller can collect link state information from topology Using BGP LS or by forming IGP peer. The GADAG calculation can be delegated to controller. Only alternate information can be downloaded by Controller. This cannot be achieved With this ease in case where LFA calculation done for tree rooted at every PLR My point is measurement can be of any form/measurement units, MRT has computation advantage but with implementation/understanding/algorithm complexity. [Bruno] My point is that this is one metric among many. And possibly not the most important. SB> SB> I think that it is fair to note that the other method use the SB> existing routing protocol and calculate alternate paths using SB> the methods of that routing protocol. Whereas with MRT you SB> really have a new routing protocol with all of the associated SB> operations overhead. [Anil >>] As you stated in previous comment, Moving to SDN world overhead can be offloaded ☺ [Bruno] Assuming you still need people to run and troubleshoot the network when something goes wrong, they need to understand the network. Many be your point is that at some point, these people may be softwarized in the SDN, but I’m afraid I can’t see that far in the future. But I don’t feel there is much overhead compared to R-LFA or TI-LFA [Bruno] We could discuss the R-LFA vs MRT case, but IMHO it’s much easier to understand TI-LFA behavior than MRT or RLFA one. SB> You miss my point. With MRT you have the complexity and SB> operation characteristics of a new routing protocol to take into SB> account. That is also the case for some of the other FRR methods SB> but by no means all of them. [ANIL 2 >> ] In fact , MRT provides less operation complexity, [Bruno] I disagree. If administrator know what is GADAG, he could easily figure out what would be alternate path visually for an extent. [Bruno] I’m not that familiar with MRT, but that sound like ‘if the operator know the path, then he can figure out the alternate path’. Sure, but this only move the question 1 step further: how do the operator know the GADAG in a given topology? In simple case, if primary path matches with blue then alternate path is red. The same cannot be expected with R-LFA or TI-LFA. [Bruno] TI-LFA follows the regular Post Convergence IGP shortest path. I can’t see what would be more simpler (there is no new path/algo) It’s even difficult to send OAM packets to verify backup path in case of R-LFA and TI-LFA. For MRT administrator can send OAM packets on RED or on BLUE path to a specific path. MRT is quite different from traditional FRR technologies, which really has unique positive qualities. [Bruno] In which case it will be easy for you to demonstrate. Only thing I feel which is lacking in MRT is capability to handle multiple failure and that should not be only criteria to reject a good protocol ☺ Hope its gets due appreciation for its unique capabilities ☺ ============ 1.1. Importance of 100% Coverage Fast-reroute is based upon the single failure assumption - that the time between single failures is long enough for a network to reconverge and start forwarding on the new shortest paths. That does not imply that the network will only experience one failure or change. SB> The above needs to be much earlier to qualify "complete" =========== 4. Maximally Redundant Trees (MRT) SB> Please remind me is there one red topology or one per failure. SB> There is just one - correct - so it would be useful to SB> explain what happens in a number of instances of failure. [Anil >>] Each devices will maintain three forwarding tables, one for default SPF calculated topology and other two for RED and BLUE topologies. Default forwarding table would have backup path on red or blue forwarding table based on alternate selection. On failure if Blue is selected as alternate path, packet will switch to Blue forwarding table. Packet stays in blue path till it reaches the destination If any failure is detected on blue path, packet will be dropped till SPF convergence. SB> This needs to be highlighted, together with the mechanism that you will use SB> to abandon the LF reconvergence. [ANIL 2 >> ] I am not an author, I wish I would; since I like this protocol ☺, I am sure authors will update it. ============ 5. Maximally Redundant Trees (MRT) and Fast-Reroute When there is a link or node failure affecting, but not partitioning, SB> that should be "a single link or single node" [Anil >>] In case of MRT there is Cut-Vertex and Cut-Link, When these vertex or link fails then network is partitioned Otherwise there exists a path to reach destination, the same would have been selected by MRT SB> Strictly it is partitioned in the chosen MRT topology. I think it can SB> be unpartitioned in base or the other MRT topology, it is just that SB> they are not available to you. [ANIL 2 >> ] I request you to elaborate this point. I didn’t understand. As far I can say, If network has no cut vertex or cut link. MRT can provide alternate path for single failure without any issue. Cut-vertex and Cut-Link is a issue for any FRR technologies. So it finally boils down to multiple failure which MRT doesn’t support. ============ 6. Unicast Forwarding with MRT Fast-Reroute As mentioned before, MRT FRR needs multi-topology forwarding. Unfortunately, neither IP nor LDP provides extra bits for a packet to indicate its topology. Once the MRTs are computed, the two sets of MRTs can be used as two additional forwarding topologies. The same considerations apply for forwarding along the MRTs as for handling multiple topologies. SB> It would be good to explain how you solve the problem mentioned SB> in the previous para. Maybe a forward ref to a later section? ============= 6.1.1.1. Topology-scoped FEC encoded using a single label (Option 1A) [RFC7307] provides a mechanism to distribute FEC-Label bindings scoped to a given MPLS topology (represented by MPLS MT-ID). To use multi-topology LDP to create MRT forwarding topologies, we associate two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies, in addition to the default shortest path forwarding topology with MT- ID=0. SB> Presumably you could MRT a topology other than default? SB> To be clear - you need 3 * the number of delivery labels in the SB> network, and in some cases these labels identify prefix or a SB> VPN exit point. SB> This is a lot more labels than some of the competing schemes SB> and so I think we really need a label table size comparison SB> in the comparison section earlier in the document. [Anil >>] Yes MRT needs multiple tables only then packet can be guided to take disjoint path to destination. The devices with higher forwarding entry capacity can choose to use MRT. In case of TI-LFA label stack size is a constraint, for older devices with limited label stack capacity that would be a serious restriction. [Bruno] For TI-LFA link protection, assuming the metric are symmetric, you can mathematically prove that the maximum number of additional labels to push is 2. For node protection this topology dependent and unbounded in theory. In practice, we have run simulation and for our networks the maximum number of labels is 4 (and if could can only push 3 labels, you only loose 0,02% of coverage). cf MPLS World Congress 2015 presentation. So point is it’s a tradeoff SB> Indeed, it is a tradeoff, but I don't think you set out the full tradeoff SB> earlier in the text, and it is by no means clear that MRT is always SB> the best trade-off. [Bruno] +1 It’s indeed a trade-off on multiple metrics. IMHO it’s clear MRT is not always the best. SB> Also you need to make it clear how large the tables are. [ANIL 2 >> ] MRT can be a best trade off in cases where , Network device has low computing powers but better forwarding capacity (access devices), Network devices has small label stack support etc... [Bruno] access device are usually deployed in simple topologies, replicated N times. e.g. U,V, ring. In those 3 topologies, the access device has only 2 IGP links, which mean that TI-LFA link protection needs 1 SPF, typically 0 to 1 additional label to push, and typically link protection will offer de facto node protection. May be to prove the point Comparison section is needed ☺ [Bruno] definitely needed. I’m not sure that a section will be enough. I’d rather see a research paper. ============= 6.1.1.2. Topology and FEC encoded using a two label stack (Option 1B) With this forwarding mechanism, a two label stack is used to encode the topology and the FEC of the packet. The top label (topology-id label) identifies the MRT forwarding topology, while the second label (FEC label) identifies the FEC. The top label would be a new FEC type with two values corresponding to MRT Red and Blue topologies. When an MRT transit router receives a packet with a topology-id label, the router pops the top label and uses that it to guide the next-hop selection in combination with the next label in the stack (the FEC label). The router then swaps the FEC label, using the FEC- label bindings learned through normal LDP mechanisms. The router then pushes the topology-id label for the next-hop. As with Option 1A, this forwarding mechanism also has the useful property that the FEC associated with the packet is maintained in the labels at each hop along the MRT. This forwarding mechanism has minimal usage of additional labels, memory and LDP communication. It does increase the size of packets and the complexity of the required label operations and look-ups. This forwarding option is consistent with context-specific label spaces, as described in [RFC 5331]. However, the precise LDP behavior required to support this option for MRT has not been specified. SB> So I wonder if this should be normative text given that the underlying SB> control plane behavior is currently unknown? SB> You should comment on the impact on forwarding moving from SB> a one to a two label action at every hop along the repair path. SB> This is not an issue that the competing approaches have and so SB> should feature in the comparison section. [Anil >>] I agree to move to comparison section. ============ 6.1.2. MRT IP tunnels (Options 2A and 2B) IP tunneling can also be used as an MRT transit forwarding mechanism. Each router supporting this MRT transit forwarding mechanism announces two additional loopback addresses and their associated MRT color. Those addresses are used as destination addresses for MRT- blue and MRT-red IP tunnels respectively. The special loopback addresses allow the transit nodes to identify the traffic as being forwarded along either the MRT-blue or MRT-red topology to reach the tunnel destination. Announcements of these two additional loopback addresses per router with their MRT color requires IGP extensions, which have not been defined. SB> So help me understand here. How do you do this with just two SB> loopback addresses. If I have red to a, red to b etc how SB> do I distinguish them. Presumably you have to do this by SB> looking inside the tunnel to find the payload. Unlike MPLS SB> this is a much larger departure from the standard forwarding SB> process isn't it? Again this needs to go in the comparision. [Anil >>] I agree to move to comparison section. Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the tunneling mechanism. Note that the two forwarding mechanisms using LDP Label options do not require additional loopbacks per router, as is required by the IP tunneling mechanism. This is because LDP labels are used on a hop- by-hop basis to identify MRT-blue and MRT-red forwarding topologies. 6.2. Forwarding LDP Unicast Traffic over MRT Paths In the previous section, we examined several options for providing MRT transit forwarding functionality, which is independent of the type of traffic being carried. We now look at the MRT ingress functionality, which will depend on the type of traffic being carried (IP or LDP). We start by considering LDP traffic. We also simplify the initial discussion by assuming that the network consists of a single IGP area, and that all routers in the network participate in MRT. Other deployment scenarios that require MRT egress functionality are considered later in this document. In principle, it is possible to carry LDP traffic in MRT IP tunnels. However, for LDP traffic, it is very desirable to avoid tunneling. Tunneling LDP traffic to a remote node requires knowledge of remote FEC-label bindings so that the LDP traffic can continue to be forwarded properly when it leaves the tunnel. This requires targeted LDP sessions which can add management complexity. SB> I have been thinking a lot about this problem just recently SB> whilst gardening, and you could take page from the SR playbook and use the SB> known offset approach. I guess that is a big change, but SB> I think we might be able to use it to avoid the longstanding distribution SB> issue - i.e. convert the problem to offset math. The two MRT LDP Label forwarding mechanisms have the useful property that the FEC associated with the packet is maintained in the labels at each hop Atlas, et al. Expires April 17, 2016 [Page 14] Internet-Draft MRT Unicast FRR Architecture October 2015 along the MRT, as long as an MRT to the originator of the FEC is used. The MRT IP tunneling mechanism does not have this useful property. Therefore, this document only considers the two MRT LDP Label forwarding mechanisms for protecting LDP traffic with MRT fast- reroute. SB> I do not understand the preceding text =========== 6.2.3. Other considerations for forwarding LDP traffic using MRT LDP Labels Note that forwarding LDP traffic using MRT LDP Labels requires that an MRT to the originator of the FEC be used. For example, one might find it desirable to have the PLR use an MRT to reach the primary next-next-hop for the FEC, and then continue forwarding the LDP packet along the shortest path tree from the primary next-next-hop. SB> Does this mean that the packet looses it's MRT marking at this point? SB> If so can't this result in a multi-failure repair loops? ============= 6.3. Forwarding IP Unicast Traffic over MRT Paths For IP traffic, there is no currently practical alternative except tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red forwarding topology. SB> Well isn't there a possible solution based on IPv6 options? The choice of tunnel egress MAY be flexible since any router closer to the destination than the next-hop can work. SB> Again isn't there an SRLG or other multiple failure issue with this? ========== 6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option 1B) The MRT LDP Label option 1B forwarding mechanism encodes the topology and the FEC using a two label stack as described in Section 6.1.1.2. When a PLR receives an IP packet that needs to be forwarded on the Red MRT to a particular tunnel endpoint, the PLR pushes two labels on the IP packet. The first (inner) label is the normal LDP label learned from the next-hop on the Red MRT, associated with a FEC originated by the tunnel endpoint. The second (outer) label is the topology-identification label associated with the Red MRT. For completeness, we note here a potential optimization. In order to tunnel an IP packet over an MRT to the destination of the IP packet (as opposed to an arbitrary tunnel endpoint), then we could just push a topology-identification label directly onto the packet. An MRT transit router would need to pop the topology-id label, do an IP route lookup in the context of that topology-id , and push the topology-id label. SB> What are you optimizing - certainly not the forwarding cycles. ============= 12.2. MRT Recalculation When a failure event happens, traffic is put by the PLRs onto the MRT topologies. After that, each router recomputes its shortest path tree (SPT) and moves traffic over to that. Only after all the PLRs have switched to using their SPTs and traffic has drained from the MRT topologies should each router install the recomputed MRTs into the FIBs. At each router, therefore, the sequence is as follows: 1. Receive failure notification 2. Recompute SPT 3. Install new SPT 4. If the network was stable before the failure occured, wait a configured (or advertised) period for all routers to be using their SPTs and traffic to drain from the MRTs. Atlas, et al. Expires April 17, 2016 [Page 34] Internet-Draft MRT Unicast FRR Architecture October 2015 5. Recompute MRTs 6. Install new MRTs. While the recomputed MRTs are not installed in the FIB, protection coverage is lowered. Therefore, it is important to recalculate the MRTs and install them quickly. SB> that is one way of doing it, anothey way is to have n MRTs running SB> ships in the night as each failure occurs and clean up later. I think SB> that this makes the migration timing less critical. I an not SB> sure whether you don't need some approach like "new labels" to make SB> this unconditionally safe. =========== 15. IANA Considerations Please create an MRT Profile registry for the MRT Profile TLV. The range is 0 to 255. The default MRT Profile has value 0. Values 1-200 are by Standards Action. Values 201-220 are for experimentation. Values 221-255 are for vendor private use. SB> I am suprised that this is not in a protocol documnet rather than the SB> architecture since you have no data structures or encodings in here. 16. Security Considerations This architecture is not currently believed to introduce new security concerns. SB> I suppose you could express this in terms of the parameters being SB> carried in the existing routing and thus you inherit their security SB> mechanisms, and that the topology boundary is set by their boundary SB> and thus you inherit their security and privacy characteristics. SB> I am supprised that the draft does not say anything about the SB> management of this new approach to FRR and the OAM that you will SB> need to test it. =========== _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
- WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Anil Kumar S N (VRP Network BL)
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Anil Kumar S N (VRP Network BL)
- RE: WGLC for draft-rtgwg-mrt-frr-architecture bruno.decraene
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Anil Kumar S N (VRP Network BL)
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Alvaro Retana (aretana)
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- RE: WGLC for draft-rtgwg-mrt-frr-architecture bruno.decraene
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Alvaro Retana (aretana)
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Rob Shakir
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Chris Bowers
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Chris Bowers
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Chris Bowers
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Rob Shakir
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Chris Bowers
- Re: WGLC for draft-rtgwg-mrt-frr-architecture Stewart Bryant
- RE: WGLC for draft-rtgwg-mrt-frr-architecture Chris Bowers