[Teas] Comments on draft-ietf-teas-gmpls-lsp-fastreroute
"Matt Hartley (mhartley)" <mhartley@cisco.com> Wed, 04 November 2015 23:12 UTC
Return-Path: <mhartley@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064A51B3782 for <teas@ietfa.amsl.com>; Wed, 4 Nov 2015 15:12:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 tjfdXKDATlOP for <teas@ietfa.amsl.com>; Wed, 4 Nov 2015 15:12:41 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7801B3787 for <teas@ietf.org>; Wed, 4 Nov 2015 15:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20743; q=dns/txt; s=iport; t=1446678760; x=1447888360; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=en9Wbmkk+ti4+3OlasjjK1SnjK3DlfCnsMP+y1IvcBE=; b=X8rnmlxzVJILH6tD30q9OV1E5jQfiWAS11ga8GbpxF93XLMt0FJEx0eW sml1nF8DX5V4M9pWYWl35KzNpA/os6Qi/Kxl/eMYn2zkYH77VH8147A7X jaAQsYixQS8UR+5mH1X3MbtJ9F9aBh3rAcRqIEsdB06mIhdoyo0HMGz6A I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAgAfkDpW/4sNJK1UCoM7gUi9bQENgV6DPoJUgUA4FAEBAQEBAQGBCoQ4BCcTDTISAT5CJgEEDg0TiBO2RotnAQEBAQEBAQEBAQEBAQEBAR2GVIkfD4UIBZJng2EBe4UKggeFD4Fhh2STAgEfAQFChASFHwGBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.20,245,1444694400"; d="scan'208";a="42137748"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2015 23:12:39 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tA4NCdwX024570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <teas@ietf.org>; Wed, 4 Nov 2015 23:12:39 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:12:38 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:12:39 -0600
From: "Matt Hartley (mhartley)" <mhartley@cisco.com>
To: "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: Comments on draft-ietf-teas-gmpls-lsp-fastreroute
Thread-Index: AdEXNMWOLfVuDR+0RiCWS6Gmn2QmcA==
Date: Wed, 04 Nov 2015 23:12:39 +0000
Message-ID: <af94cc08cd8645d1aef9229858acf8c2@XCH-RCD-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/xGnUM50OXmd36WfzLoVCEvXyFn0>
Cc: "Matt Hartley (mhartley)" <mhartley@cisco.com>
Subject: [Teas] Comments on draft-ietf-teas-gmpls-lsp-fastreroute
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 23:12:45 -0000
All, Some comments on this. In general: post -> after. It's just easier to read (IMO :) You don't need to expand MP every time you use it. I lost count of the number of places you've done this. The document talks about PSC LSPs. Presumably it doesn't apply to LSPs with any other switching capability, but it might be a good idea to explicitly say so (maybe around section 3, where you're setting out other things this document doesn't apply to). Section 4.1 Does RFC 4090 specify that the upstream label MUST be added to the Path RRO? If not, this draft needs to. Section 4.2: Similarly, does 4561 specify that the node-id MUST be added? Again, this draft relies on it. Does this draft work on the assumption that the backup tunnel goes in the same direction as the primary LSP that it protects (i.e. that the backup's head is at the upstream PLR rather than the downstream PLR)? I get the feeling it does (more on this later) but it's not explicitly stated anywhere. If this is the case, it means that perfectly good backup tunnels that happen to be running in the wrong direction can't be used. 4.4.1: This means that a Path message is going to be regenerated every time there's a backup assignment. Given that backup assignments are generally done during Resv processing, this means that if every hop can be a PLR, you're going to get a *lot* of updated Path messages while the LSP is being established. Is this a problem? Can it be mitigated if so? It would be good to see some discussion of this. 4.4.1: this doesn't say that a downstream MP needs to examine the entire Path RRO and look at all BYPASS_ASSIGNMENT objects; it probably should do. It should probably also say that the choice of backup tunnel (if multiple choices exist) is discussed in section 4.4.2. As written, the draft prevents an upstream backup being assigned unless that backup is also assigned in the downstream direction (4.4.1). The reverse, however, does not apply; when a downstream PLR assigns a backup, there's no guarantee that this backup will also be used for upstream traffic. Is this a problem? And if not, why shouldn't an upstream PLR be permitted to assign an upstream backup in its own initiative if it wants to? Section 4.4.2 seems quietly resigned to the fact that some links may be unprotected in the reverse direction. Is this inevitable? 4.4.3: is the data present in the BYPASS_ASSIGNMENT subobject sufficient to uniquely identify the backup tunnel? I see two issues here. First, the tunnel-id alone is sufficient only if the source and destination are already known from the RRO, and that's only possible if we assume the source is the node that inserted the BYPASS_ASSIGNMENT subobject and the destination is the processing MP. As mentioned earlier, a backup tunnel originating at the MP could also do the job (these are bidirectional tunnels, after all) but this is precluded at the moment. I think this limitation needs to be justified if you wish to impose it. Second: even if we only allow backups to originate on the downstream PLR, do we also need the extended tunnel id as an additional discriminator? Section 5 seems to be based on the assumption that all link failures are bidirectional. Is this reasonable? In particular, what if a link failure is only detected by the upstream PLR? 5.1, at the end: does the upstream PLR have to wait until it receives Path state over the bypass tunnel before redirecting Resv state onto the bypass, or can it redirect Resv state as soon as it detects a failure? It strikes me that the latter might be a good idea, especially if unidirectional failures are a possibility. 6.2: Under what circumstances could the PRR fail to find a reverse bypass tunnel? Given that it became a PRR because it was already a MP, doesn't it always have a suitable bypass? If it didn't, it would be a MP... 6.2: this example focuses on what R3 and R5 are doing. Could you also describe the expected behavior of R2 and R4? Finally... some nits/readability suggestions. I've pasted significant chunks of the draft below with my suggested changes inline: look for 'MRH'. Cheers Matt Abstract This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of bidirectional bypass tunnel MRH: ...coordination of a bidirectional... assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. (snip) 1. Introduction Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are signaled using Generalized Multi-Protocol Label Switching (GMPLS) signaling procedures specified in [RFC3473] for both unidirectional and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely deployed in the packet TE networks today and is preferred for TE MRH: preferred -> desirable. 'preferred' implies it exists already, and if that were the case you wouldn't need this draft :) GMPLS tunnels. Using FRR methods also allows to leverage existing MRH: ...Using FRR procedures also allows the leveraging of... (or maybe ...re-use of...) mechanisms for failure detection and restoration in the deployed networks. MRH: ...in deployed networks. FRR procedures defined in [RFC4090] describe the behavior of the MRH: The FRR procedures... Point of Local Repair (PLR) to reroute traffic and signaling onto the bypass tunnel in the event of a failure for unidirectional LSPs. These procedures are applicable to unidirectional protected LSPs signaled using either RSVP-TE [RFC3209] or GMPLS procedures [RFC3473], however don't address issues that arise when employing FRR MRH: ...[RFC3473], but they do not address... for bidirectional co-routed GMPLS Label Switched Paths (LSPs). When bidirectional bypass tunnels are used to locally protect bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs may independently assign different bidirectional bypass tunnels in the forward and reverse directions. There is no mechanism in FRR MRH: ...in the FRR procedures... procedures defined in [RFC4090] to coordinate the bidirectional bypass tunnel selection between the downstream and upstream PLRs. When using FRR procedures with bidirectional co-routed GMPLS LSPs, it is possible in some cases (e.g. when using node protection bypass tunnels post a link failure event and when RSVP signaling is sent in-fiber and in-band with data), the RSVP signaling refreshes may stop reaching some nodes along the primary bidirectional LSP path after the PLRs complete rerouting traffic and signaling onto the bypass tunnels. MRH: maybe replace this lot with: When using FRR procedures with bidirectional co-routed GMPLS LSPs, it is possible in some cases for the RSVP signaling refreshes to stop reaching some nodes along the primary LSP path after the PLRs finish rerouting signaling onto the bypass tunnels. This may occur when using node protection bypass tunnels after a link failure event and when RSVP signaling is sent in-fiber and in-band with data. This is caused by the asymmetry of paths that may be taken by the bidirectional LSP's signaling in the forward and reverse directions after FRR reroute. In such cases, the RSVP soft-state timeout eventually causes the protected bidirectional LSP to be MRH: ...timeout causes... destroyed, and consequently impacts protected traffic flow after FRR. MRH: ...destroyed, with subsequent traffic loss after FRR. Protection State Coordination Protocol [RFC6378] is applicable to FRR [RFC4090] for local protection of bidirectional co-routed LSPs in order to minimize traffic disruptions in both directions. However, this does not address the above mentioned problem of RSVP soft-state timeout in control plane. This document proposes solutions to the above mentioned problems by providing mechanisms in the control plane to complement FRR MRH: ...complement the FRR procedures... procedures of [RFC4090] in order to maintain the RSVP soft-state for bidirectional co-routed protected GMPLS LSPs and achieve symmetry in the paths followed by the traffic and signaling in the forward and reverse directions post FRR. The document further extends RSVP signaling so that the bidirectional bypass tunnel selected by the upstream PLR matches the one selected by the downstream PLR node for a bidirectional co-routed LSP. Unless otherwise specified in this document, fast reroute procedures MRH: ...document, the FRR procedures... defined in [RFC4090] are not modified for GMPLS signaled tunnels. (snip) 3. Fast Reroute For Unidirectional GMPLS LSPs FRR procedures defined in [RFC4090] are applicable to unidirectional MRH: The FRR procedures... protected LSPs signaled using either RSVP-TE or GMPLS procedures and are not modified by the extensions defined in this document. These FRR procedures also apply to bidirectional associated GMPLS LSPs where two unidirectional GMPLS LSPs are bound together by using association signaling [RFC7551]. 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs This section describes signaling procedures for bidirectional bypass tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE LSPs. 4.1. Merge Point Labels To correctly reroute data traffic over a node protection bypass tunnel, the downstream and upstream PLRs have to know, in advance, the downstream and upstream Merge Point (MP) labels so that data in the forward and reverse directions can be tunneled through the bypass tunnel post FRR respectively. MRH: .... can be redirected through the bypass tunnel after FRR. [RFC4090] defines procedures for the downstream PLR to obtain the protected LSP's downstream MP label from recorded labels in the RRO of the RSVP Resv message received at the downstream PLR. To obtain the upstream MP label, existing methods [RFC4090] to record MRH: ...label, the procedures defined in [RFC4090] to record the upstream... upstream MP label are used in the RRO of the RSVP Path message. The upstream PLR can obtain the upstream MP label from the recorded label in the RRO of the received RSVP Path message. 4.2. Merge Point Addresses To correctly assign a bidirectional bypass tunnel, the downstream and upstream PLRs have to know, in advance, the downstream and upstream Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR to obtain the protected LSP's merge point address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). [RFC4561] defines procedures for the downstream PLR to obtain the protected LSP's downstream merge point address from the recorded node-IDs in the RRO of the RSVP Resv message received at the downstream PLR. MRH: these two paragraphs repeat a lot of stuff. Merge them? To obtain the upstream MP address, existing methods [RFC4561] to MRH: ...address, the procedures specified in [RFC4561] to... record upstream MP node-ID are used in the RRO of the RSVP Path message. The upstream PLR can obtain the upstream MP address from the recorded node-IDs in the RRO of the received RSVP Path message. 4.3. RRO IPv4/IPv6 Subobject Flags RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 and are applicable to the FRR procedure for the bidirectional GMPLS MRH: ...for bidirectional... tunnels. [RFC4090] defined procedure is used by the downstream PLR MRH: The procedure defined in [RFC4090] is used... independently to signal the Ipv4/IPv6 subobject flags in the RRO of MRH: Ipv4 -> IPv4 the RSVP Path message. Similarly, this procedure is used by the upstream PLR independently to signal the IPv4/IPv6 subobject flags in the RRO of the RSVP Resv message. 4.4. Bypass Tunnel Assignment Co-ordination This document defines signaling procedure and a new BYPASS_ASSIGNMENT MRH: procedure -> procedures subobject in RSVP RECORD_ROUTE object used to co-ordinate the MRH: ...in the RSVP RECORD_ROUTE object... bidirectional bypass tunnel selection between the downstream and upstream PLRs. 4.4.1. Bypass Tunnel Assignment Signaling Procedure (snip) The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject, whose bypass tunnel and the node-ID subobject when used as a "bypass tunnel source" terminates locally, assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. Otherwise, the bypass tunnel assignment subobject is simply forwarded downstream along in the RSVP Path message. MRH: This paragraph is a bit garbled. Can you rewrite to make it clearer? Bypass assignment co-ordination procedure described above can be used MRH: The bypass assignment... for both one-to-one backup described in Section 3.1 of [RFC4090] and facility backup described in Section 3.2 of [RFC4090]. 4.4.2. Bypass Tunnel Assignment Policy In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT subobjects from multiple downstream PLRs, the decision of selecting a bypass tunnel in the reverse direction can be based on a local policy, for example, prefer link protection versus node protection bypass tunnel, or prefer the most upstream versus least upstream node protection bypass tunnel. MRH: "the selection of a bypass tunnel in the reverse direction can be based on local policy. Examples of such a policy could be to prefer link protection over node protection, or to prefer the bypass tunnel to the furthest upstream node." However, it is recommended that nodes MRH: recommended -> RECOMMENDED? Or if you don't mean to use 2119 language here, could you reword this? It's ambiguous as it stands. along the LSP path employ identical policy for bypass tunnel assignment. When different policies are used for bypass tunnel assignment on the LSP path, it may result in some links in the reverse direction not assigned bypass protection as shown in examples below. As shown in Example 1, node A assigns a node protection bypass tunnel in the forward direction but node C does not assign a node protection bypass tunnel in the reverse direction for a protected bidirectional GMPLS LSP. Both nodes B and C assign a link protection bypass tunnel. As a result, there is no fast reroute protection available in the reverse direction for link A-B for this LSP. +------->>------+ / +->>-+ \ / / \ \ / / \ \ A -------- B --------- C \ / \ / +-<<-+ Example 1: An example of different bypass assignment policy MRH: add an arrow to indicate the direction of the ABC LSP. Same in example 2 below. (snip) 4.4.3. BYPASS_ASSIGNMENT Subobject The BYPASS_ASSIGNMENT subobject is used to inform the MP of the MRH: ...inform the downstream MP... bypass tunnel being assigned by the PLR. This can be used to coordinate the bypass tunnel assignment for the protected LSP by the downstream and upstream PLRs in the forward and reverse directions respectively prior or post the failure occurrence. This subobject SHOULD only be inserted into the RSVP Path message by the downstream PLR and MUST NOT be changed by downstream LSRs. MRH: maybe... "This subobject SHOULD be inserted into the Path RRO by the downstream PLR. It SHOULD NOT be inserted into an RRO by a node which is not a downstream PLR. It MUST NOT be changed by downstream LSRs and MUST NOT be added to a Resv RRO." The BYPASS_ASSIGNMENT subobject in RRO has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Bypass Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Downstream Bypass Assignment. MRH: maybe mention that the value is TBD pending IANA assignment? (snip) 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs When a bidirectional link protection bypass tunnel is used, after a link failure, downstream PLR reroutes RSVP Path and traffic over MRH: failure... the downstream PLR reroutes traffic and RSVP messages over the bypass tunnel using the procedures defined in... bypass tunnel using procedures defined in [RFC4090]. Upstream PLR may reroute traffic and RSVP Resv upon detecting the link failure or upon receiving RSVP Path message over a bidirectional bypass tunnel. MRH: Upstream PLR behavior is unclear here. I assume you mean that it MAY use whichever trigger (Path message or link-down) it gets first? You should probably say that it MUST do one or the other. This allows both traffic and RSVP signaling to flow on symmetric paths in the forward and reverse directions of a bidirectional tunnel. (snip) Consider the Traffic Engineered (TE) network shown in Figure 1. Assume every link in the network is protected with a link protection bypass tunnel (e.g. bypass tunnel T3). For the protected bidirectional co-routed LSP whose (active) head-end is on router R1 and (passive) tail-end is on router R5, each traversed router (a potential PLR) assigns a link protection bidirectional co-routed bypass tunnel. MRH: are active and passive industry-standard terms? I'd have thought using head and tail would suffice. (snip) 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs (snip) Consider the Traffic Engineered (TE) network shown in Figure 2. Assume every link in the network is protected with a node protection bypass tunnel. For the protected bidirectional co-routed LSP whose (active) head-end is on router R1 and (passive) tail-end is on router R6, each traversed router (a potential PLR) assigns a node protection bidirectional co-routed bypass tunnel. MRH: Again, are active and passive industry-standard terms? (snip) 6.2. Behavior Post Link Failure To Re-coroute The downstream Merge Point (MP) R5 that receives rerouted protected LSP RSVP Path message through the bypass tunnel, in addition to the regular MP processing defined in [RFC4090], gets promoted to a Point of Remote Repair (PRR role) and performs the following actions to re-coroute signaling and data traffic over the same path in both directions: o Finds the bypass tunnel in the reverse direction that terminates on the Downstream PLR R3. Note: the Downstream PLR R3's address is extracted from the "IPV4 tunnel sender address" in the SENDER_TEMPLATE object. MRH: bypass tunnel's SENDER_TEMPLATE (snip) If downstream MP R5 receives multiple RSVP Path messages through multiple bypass tunnels (e.g. as a result of multiple failures), the PRR SHOULD identify a bypass tunnel that terminates on the farthest downstream PLR along the protected LSP path (closest to the primary bidirectional tunnel head-end) and activate the reroute procedures mentioned above. MRH: Don't you mean the furthest *upstream* PLR? (snip to end)
- [Teas] Comments on draft-ietf-teas-gmpls-lsp-fast… Matt Hartley (mhartley)
- Re: [Teas] Comments on draft-ietf-teas-gmpls-lsp-… Rakesh Gandhi (rgandhi)