Re: [mpls] Note on p2mp ingress and egress protection proposals

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 18 December 2013 21:30 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 510061ADFFA for <mpls@ietfa.amsl.com>; Wed, 18 Dec 2013 13:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Gf3OjSSUVL2c for <mpls@ietfa.amsl.com>; Wed, 18 Dec 2013 13:30:18 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E3F971AE192 for <mpls@ietf.org>; Wed, 18 Dec 2013 13:30:17 -0800 (PST)
X-AuditID: c6180641-b7fbd8e0000011cc-c7-52b213e543ed
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 28.AB.04556.5E312B25; Wed, 18 Dec 2013 22:30:13 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Wed, 18 Dec 2013 16:29:58 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Alia Atlas <akatlas@gmail.com>
Thread-Topic: [mpls] Note on p2mp ingress and egress protection proposals
Thread-Index: Ac77SQgjFiRx71WkT86cjtgOzPNpQwA9e2EAAAIZXpA=
Date: Wed, 18 Dec 2013 21:29:57 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B73ECAD@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF1121B73C6B8@eusaamb103.ericsson.se> <CAG4d1rfWGX6k3AF7P1ed4X7c_=gBCd4AcnPTi4wL=ejKBJb1Dg@mail.gmail.com>
In-Reply-To: <CAG4d1rfWGX6k3AF7P1ed4X7c_=gBCd4AcnPTi4wL=ejKBJb1Dg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B73ECADeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPoO5T4U1BBpf3SVp8eniJ2eLW0pWs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGtPsrmQuWJFXMmbCItYHxQ0gXIyeHhICJ xP4zl1ggbDGJC/fWs3UxcnEICRxhlNh55SE7hLOcUWLLjcuMIFVsAkYSLzb2ACU4OEQElCSm vhQGMZkFlCVO3ZUBqRAW8JCYub+TFcQWEfCUOLFtD1S1lcSfs8EgYRYBVYnFNxezgdi8Ar4S R9Z9Z4XYNIVR4um+k2wg9ZwCgRJft/uB1DACnfb91BomEJtZQFzi1pP5TBAnC0gs2XOeGcIW lXj5+B8rhK0s8X3OIxaI+nyJo4vOMUHsEpQ4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2 tsSyha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLiJERhRxyTYHHcwLvhkeYhRmoNFSZz3y1vn ICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MYrluzq/WXrFrdX+/kDs8NT2oMrowgOtR/7ZS doljNTvcJ/95dv4m+9alXD3FewLPd0v5cJb4mHqu3mKms2ze9J6FC80C6vf+T1l34bPZgl6l eR2qFg3mLoeuT7gYeX+hU6BQ3PGDk5R/OHqaXmlleHJwCaPN4T8s22KdXjAZpr4wCQ9v/xGi xFKckWioxVxUnAgAvTdCQ3YCAAA=
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Note on p2mp ingress and egress protection proposals
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: Wed, 18 Dec 2013 21:30:24 -0000

Hi Alia,
yes, I'd consider using the ICCP, Inter-Chassis Communication Protocol, in cases of LSP ingress and egress protection to synchronize state. I agree with your analysis that ICCP unlikely to support fast protection switchover but I'm not certain that such is required because we don't have any use case and/or requirements for LSP ingress and/or egress protection scenarios. As I can see and was commenting, proposed application of OAM monitoring does create likely positive negative scenarios. The ICCP will address them, I believe. Is that required? We can determine that if we have agreed upon requirements but until then that is matter of personal opinion.
I think that both scenarios present cases of LSP redundancy that are similar to PW redundancy where ICCP plays integral and important role. Hence my recommendation to discuss applicability of ICCP. But even more stronger I'd encourage and would gladly cooperate on requirements towards LSP ingress and egress protection.

                Regards,
                                Greg

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Wednesday, December 18, 2013 9:18 AM
To: Gregory Mirsky
Cc: mpls@ietf.org
Subject: Re: [mpls] Note on p2mp ingress and egress protection proposals

Hi Greg,

Can you briefly summarize what part of the problem ICCP is solving and why you think it can be improved to offer fast protection?  From a quick glance at the first couple pages, it looks like it does the state coordination for the service - but not setting up the transport LSPs??

The RSVP-TE ingress protection draft describes different failure detection modes so that the appropriate action on detecting a failure is clearly agreed before the failure occurs.

Handling a failure in a non fast fashion is fairly rivial; for instance, the backup ingress could run BFD to the ingress node's loopback and see if it fails after the network has converged.

I do think that there are basic RSVP-TE mechanisms required to set up the backup LSPs, indicate the traffic to insert, and what type of failure detection will be used.  Those seem to require standardization for interoperability - not just informational.

Perhaps you can more clearly describe what you are proposing?  Of course, if you already have a draft written, please just point me at it.

Regards,
Alia

On Tue, Dec 17, 2013 at 12:11 PM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:
Dear All,
I've been following these proposals for a quite some time and actively participated in the discussion with authors. I do believe that both scenarios represent use of redundancy and hence explicit coordination of Active/Standby roles is required. That certainly would simplify OAM for both cases. And I believe that ICCP is good candidate for coordination within Redundancy Group. Though it would hardly be "fast protection" then.
Hence I believe that all pieces needed to address both scenarios already exist and Informational documents may be needed if anything at all.

                Regards,
                                Greg

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls