[mpls] Comments on draft-ietf-teas-rsvp-ingress-protection

Gregory Mirsky <gregory.mirsky@ericsson.com> Sun, 12 April 2015 06:03 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7D71B34DB; Sat, 11 Apr 2015 23:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.5
X-Spam-Level:
X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Bg9XuZOWSdRu; Sat, 11 Apr 2015 23:03:56 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB731B34D8; Sat, 11 Apr 2015 23:03:55 -0700 (PDT)
X-AuditID: c618062d-f79686d0000030a8-7b-5529b4114d58
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.FD.12456.214B9255; Sun, 12 Apr 2015 01:53:54 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Sun, 12 Apr 2015 02:03:46 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" <draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Comments on draft-ietf-teas-rsvp-ingress-protection
Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+Cg==
Date: Sun, 12 Apr 2015 06:03:46 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPoK7QFs1Qg6M7xSwuPnzKbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVsev+EfaCLXMZ K37OXM3SwPirg7GLkZNDQsBE4tmthWwQtpjEhXvrgWwuDiGBo4wS7dvfsUA4yxklfgOtAqli EzCSeLGxhx3EFhE4zSjxpVEJxGYW8JK49HwaM4gtLGAr0d/9hgmixknizLIrULaexJO578G2 sQioSmz7+JQFxOYV8JV4/PQeWJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwph K0l8/D2fHaI+X2Lh+dtsEDMFJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY +8yBx0zI4gsY2VcxcpQWp5blphsZbGIERtIxCTbdHYx7XloeYhTgYFTi4X3grhEqxJpYVlyZ e4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYhX0OJQgcSRWNLD3yTClF Idn9TnS22wvXBfnt/1f2fN5qLVvA/dm59ujJBeIV7wMuXjkVbrJy+36rzw9keCeYVlm98L8W P63tV5n+/bIbu88uVg9tttFnmPJ9v43V2h7pw8kz9klFB35qaBK/drRJVPf2v8l7sxztcooS 84quzv4gaGEcyletxFKckWioxVxUnAgAAAoC14UCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/0vtcRjYktVLVUaQwVdGKJJm2a-M>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2015 06:03:59 -0000

Dear Editors, chairs, WG community,
please find my comments to the current version of your work below:

*         Introduction

o   The first paragraph may leave an impression that local protection of transit LSRs is not being already addressed, neither by RFC 4090, nor RFC 4875;

o   I think that "global protection" is not commonly used term, "end-to-end protection" seems to be commonly used instead.

*         Section 3.1

o   Third paragraph contains the following requirement:
"For a P2P LSP, after the primary ingress fails, the backup ingress must use a method to reliably detect the failure of the primary ingress before the PATH message for the LSP expires at the next hop of the primary ingress."
But that is not obvious that such requirement is really needed. Since this is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to control switchover. Especially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a logical link, which in general case will be a tunnel. Thus this solution puts a requirement, implicitly though, to instantiate a tunnel per protection group, tunnel that would not be used to carry traffic.

o   In addition, what is importance of requirement quoted above:
"... before the PATH message for the LSP expires at the next hop of the primary ingress"

o   Fourth paragraph makes very questionable assumption in:
"After the primary ingress fails, it will not be reachable after routing convergence."
I believe that if OAM session is between two nodes there's no reliable way to differentiate between node and link failure. Thus, to declare a node unreachable there must be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirement to use a tunnel between primary and backup ingress, multi-hop BFD could be used though its detection time being limited by IGP convergence, which may be too slow comparing with your requirement of tens milliseconds).

*         Section 5.1

o   Regarding "Ingress local protection in use" flag
As demonstrated earlier, backup ingress node has no reliable way to detect that primary ingress node is not reachable to the Source and thus protection must be activated.

Considering that backup ingress may initiate described in the document actions not when primary ingress became unavailable to Source, I believe that cases that may produce false positives must be removed along with extensions that intended to support these cases. In my opinion, the only viable case of ingress protection is Source-centric where Source monitors availability of both primary and backup ingress nodes and controls traffic switchover. I'd ask WG to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

                Regards,
                                Greg