Re: [mpls] Determining proper TTL of a tunnel in Fast LSP-alert Mechanism
Sriganesh Kini <sriganesh.kini@ericsson.com> Mon, 26 July 2010 21:43 UTC
Return-Path: <sriganesh.kini@ericsson.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FC03A69B4 for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 14:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qaz7wb0Lgva for <mpls@core3.amsl.com>; Mon, 26 Jul 2010 14:43:13 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 519C23A684E for <mpls@ietf.org>; Mon, 26 Jul 2010 14:43:13 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o6QLhXe8015614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jul 2010 16:43:33 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 26 Jul 2010 17:43:32 -0400
From: Sriganesh Kini <sriganesh.kini@ericsson.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Autumn Liu <autumn.liu@ericsson.com>, "mpls@ietf.org" <mpls@ietf.org>
Date: Mon, 26 Jul 2010 17:43:31 -0400
Thread-Topic: Determining proper TTL of a tunnel in Fast LSP-alert Mechanism
Thread-Index: AcstBKXyP4QXzx89TaOowREeHFvMvwAArHig
Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F567DB80D0D@EUSAACMS0703.eamcs.ericsson.se>
References: <AANLkTinf_TdjCXfvZDhEMjrkuM3bowYwKe-2NsSftTrf@mail.gmail.com>
In-Reply-To: <AANLkTinf_TdjCXfvZDhEMjrkuM3bowYwKe-2NsSftTrf@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80D0DEUSAACMS0703e_"
MIME-Version: 1.0
Subject: Re: [mpls] Determining proper TTL of a tunnel in Fast LSP-alert Mechanism
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 26 Jul 2010 21:43:14 -0000
Greg, I wouldn't interpret that as invalidating the requirement. Those are thoughts on potential workarounds and should be considered only for scenarios that have LSRs that don't support the functionality. Thanks - Sri ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Monday, July 26, 2010 1:53 PM To: Autumn Liu; Sriganesh Kini; mpls@ietf.org Subject: Determining proper TTL of a tunnel in Fast LSP-alert Mechanism Dear Authors, the Section 3.2.2 states new requirement which ends with the sentence: "An LSP label on the forwarded packet MUST continue to have TTL set to 1." But at the same time, in Section 6 when outlining direction for future work, it is said that in heterogeneous environment value of TTL must be determined by each node that supports the Fast LSP-alert mechanism. Does that scenario invalidates the requirement put forward in Section 3.2.2? Regards, Greg
- [mpls] Determining proper TTL of a tunnel in Fast… Greg Mirsky
- Re: [mpls] Determining proper TTL of a tunnel in … Sriganesh Kini