RE: WGLC for draft-rtgwg-mrt-frr-architecture
Chris Bowers <cbowers@juniper.net> Mon, 21 December 2015 14:47 UTC
Return-Path: <cbowers@juniper.net>
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 459611A8748 for <rtgwg@ietfa.amsl.com>; Mon, 21 Dec 2015 06:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 slMAXPuFyL61 for <rtgwg@ietfa.amsl.com>; Mon, 21 Dec 2015 06:47:21 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416111A8711 for <rtgwg@ietf.org>; Mon, 21 Dec 2015 06:47:18 -0800 (PST)
Received: from CO2PR05MB619.namprd05.prod.outlook.com (10.141.198.148) by CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 21 Dec 2015 14:47:15 +0000
Received: from CO2PR05MB619.namprd05.prod.outlook.com ([10.141.198.148]) by CO2PR05MB619.namprd05.prod.outlook.com ([10.141.198.148]) with mapi id 15.01.0355.012; Mon, 21 Dec 2015 14:47:15 +0000
From: Chris Bowers <cbowers@juniper.net>
To: Stewart Bryant <stewart.bryant@gmail.com>, "draft-rtgwg-mrt-frr-architecture@tools.ietf.org" <draft-rtgwg-mrt-frr-architecture@tools.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Alvaro Retana <aretana@cisco.com>
Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Topic: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Index: AQHRLfTf9mV+PzSAtUyZECDvldWiE57NvqkA
Date: Mon, 21 Dec 2015 14:47:15 +0000
Message-ID: <CO2PR05MB61971754BE04CE6689866A3A9E40@CO2PR05MB619.namprd05.prod.outlook.com>
References: <566083D0.1020607@gmail.com>
In-Reply-To: <566083D0.1020607@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net;
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO2PR05MB618; 5:cndg9ZjA3qxHLkuhyBB0VQncvtFyHvL6CfaHgdj6INhJp+Fg+YBJcNLSrDaSGDpQST4paGqGhBkgW5pVLZh3D+iWMPNFsbjQfVqhTX1X8SelSZGNbsSIL9M9tgOQ+2v14BM8ZSZyRg0Idh92VAaQGQ==; 24:OJBHV2JciY4JsxcV26DPbhyJ9aHlyNJHqvkp3EgxEC7QWErqMeLxSdSG7AIsbZB+XEY5CP+qnd8Lggg0kX/m6rqG4372oIeKXIfnVDahtqg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB618;
x-microsoft-antispam-prvs: <CO2PR05MB61843B34A3AF593C01B1429A9E40@CO2PR05MB618.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:CO2PR05MB618; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB618;
x-forefront-prvs: 079756C6B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(51444003)(199003)(54094003)(107886002)(66066001)(189998001)(122556002)(87936001)(86362001)(105586002)(586003)(230783001)(19580395003)(3846002)(2201001)(5001960100002)(106356001)(106116001)(40100003)(97736004)(76176999)(6116002)(5001770100001)(15975445007)(102836003)(99286002)(54356999)(101416001)(5002640100001)(50986999)(92566002)(5003600100002)(2501003)(10400500002)(1220700001)(5008740100001)(33656002)(19580405001)(11100500001)(81156007)(76576001)(2900100001)(74316001)(5004730100002)(1096002)(77096005)(2950100001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB618; H:CO2PR05MB619.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2015 14:47:15.7385 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB618
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/PNHjhRV9RHXI1zMz9FiYYX6mfx0>
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: Mon, 21 Dec 2015 14:47:25 -0000
Stewart, Thanks for your feedback. Please see inline [CB] for responses. The diff of the new version can be found at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-08 Chris From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, December 03, 2015 12:03 PM To: draft-rtgwg-mrt-frr-architecture@tools.ietf.org; rtgwg@ietf.org; Alvaro Retana <aretana@cisco.com> Subject: WGLC for draft-rtgwg-mrt-frr-architecture 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 even SB> simple pathological cases. If the network is two connected and you SB> have both a red and blue failure that you need to traverse, you SB> (say) commit to the red the you will fail at blue transition, even SB> though the network is is still connected at the link level. SB> The text should start with the invariants and assumptions to SB> correctly scope the claims in the introduction. [CB] Changed the text to read: This document describes a solution for IP/LDP fast-reroute [RFC5714]. SB> I think you have to say where the trees are routed since only two SB> mean you need a root, and you need to note that this is different SB> from the underlying IGP in which there is a tree per node. [CB] I don’t understand the distinction that you suggest noting. The MRT computation run at each source node produces a distinct red and blue tree for each destination node with each tree rooted at and directed towards the destination node. The end result is similar to way that the forward SPF computation run at each source node produces a shortest path tree for each destination node with each tree rooted at and directed towards the destination 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 given SB> that we are moving to an SDN world where these calculations can be SB> offloaded? 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 the SB> methods of that routing protocol. Whereas with MRT you really have a SB> new routing protocol with all of the associated operations overhead. ============ 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" [CB] I removed the unqualified occurrences of "complete" and left those which refer to "complete coverage". =========== 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 explain what SB> happens in a number of instances of failure. [CB] There is one red tree per destination. ============ 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" [CB] corrected. ============ 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 in SB> the previous para. Maybe a forward ref to a later section? [CB] I decided to delete this paragraph. It seems like the info in it is covered more clearly elsewhere. ============= 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? [CB] It could be done, but we focused on supporting the use case using the default IGP topology. There is existing text in section 7 explaining this. Deployment scenarios using multi-topology OSPF or IS-IS, or running both ISIS and OSPF on the same routers is out of scope for this specification. 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 VPN SB> exit point. SB> This is a lot more labels than some of the competing schemes and so SB> I think we really need a label table size comparison in the SB> comparison section earlier in the document. ============= 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 SB> underlying control plane behavior is currently unknown? SB> You should comment on the impact on forwarding moving from a one to SB> 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. [CB]The second to last paragraph above mentions the complexity of the required label operations and look-ups. ============ 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 do I SB> distinguish them. Presumably you have to do this by looking inside SB> the tunnel to find the payload. Unlike MPLS this is a much larger SB> departure from the standard forwarding process isn't it? Again this SB> needs to go in the comparision. [CB] I added the following text to the draft to clarify. For example, an MRT ingress router can cause a packet to be tunneled along the MRT-red path to router X by encapsulating the packet using the MRT-red loopback address advertised by router X. Upon receiving the packet, router X would remove the encapsulation header and forward the packet based on the original destination address. ---------------------------- 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 whilst SB> 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 I think we SB> might be able to use it to avoid the longstanding distribution issue SB> - 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 [CB] I changed the text to: As described below, the two MRT forwarding mechanisms that use LDP labels do not require targeted LDP sessions. =========== 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? [CB] I rewrote the paragraph as below to make it clear that main usage is to stay on the MRT all the way to the destination. Note that forwarding LDP traffic using MRT LDP Labels can be done without the use of targeted LDP sessions when an MRT path to the destination FEC is used. The alternates selected in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> use the MRT path to the destination FEC, so targeted LDP sessions are not needed. If instead one found 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, this would require tunneling to the primary next-next-hop and a targeted LDP session for the PLR to learn the FEC-label binding for primary next-next-hop to correctly forward the packet. ============= 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? [CB] Agreed. I have modified the text in the draft to read: For IPv4 traffic, there is no currently practical alternative except tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red forwarding topology. For IPv6 traffic, in principle one could define bits in the IPv6 options header to indicate the MRT-Blue or MRT-Red forwarding topology. However, in this document, we have chosen not to define a solution that would work for IPv6 traffic but not for IPv4 traffic.--------------------- 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? [CB] I don’t think there is a special consideration with respect to multiple failures for taking an MRT path to a router that is not the destination, except that the process of analyzing the end-to-end path to identify shared risks would involve to parts, the MRT path to the intermediate node and the shortest path from the intermediate node to destination. ========== 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. [CB] clarified with the text below. For completeness, we note here a potential variation that uses a single label as opposed to two labels. ============= 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 SB> think 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. [CB] Agreed. I added the following text to this section to clarify that this is the procedure being specified for the Default MRT profile, but that other approaches are possible. I also made some minor changes in the description of profiles in general and the Default Profile specifically to clarify this. ------- This section describes how the MRT recalculation SHOULD be performed for the Default MRT Profile. This is intended to support FRR applications. Other approaches are possible, but they are not specified in this document. =========== 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 surprised that this is not in a protocol documnet rather than SB> the architecture since you have no data structures or encodings in here. [CB] Since the MRT Profile value can be carried in ISIS or OSPF (with corresponding documents in those WGs), and the MPLS LDP MT-ID values corresponding red and blue MRT FEC for the Default profile are in a document in the MPLS WG, the current document seems like a reasonable place to define a common registry in a protocol neutral document, and allow the protocol specific documents to reference it. 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. [CB] I changed the security considerations section to read as below. In general, MRT forwarding paths do not follow shortest paths. The transit forwarding state corresponding to the MRT paths is created during normal operations (before a failure occurs). Therefore, a malicious packet with an appropriate header injected into the network from a compromised location would be forwarded to a destination along a non-shortest path. When this technology is deployed, a network security design should not rely on assumptions about potentially malicious traffic only following shortest paths. It should be noted that the creation of non-shortest forwarding paths is not unique to MRT. -------------------- 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. [CB] I added the following section to address this. 14. Operations and Management Considerations An implementation SHOULD provide an operator with the ability to test MRT paths with OAM traffic. For example, when MRT paths are realized using LDP labels distributed for topology-scoped FECs, an implementation can use the MPLS ping and traceroute as defined in [RFC4379] and extended in [RFC7307] for topology-scoped FECs. ===========
- 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