Return-Path: 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 ; 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 ; 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 ; 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 To: Greg Mirsky , Autumn Liu , "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: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 21:43:14 -0000 --_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80D0DEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, I wouldn't interpret that as invalidating the requirement. Those are though= ts on potential workarounds and should be considered only for scenarios tha= t 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 determi= ned by each node that supports the Fast LSP-alert mechanism. Does that scen= ario invalidates the requirement put forward in Section 3.2.2? Regards, Greg --_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80D0DEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,
 
I wouldn't interpret that as invalidating the= =20 requirement. Those are thoughts on potential workarounds and should be=20 considered only for scenarios that have LSRs that don't support t= he=20 functionality.
 
Thanks

- Sri

 

From: Greg Mirsky=20 [mailto:gregimirsky@gmail.com]
Sent: Monday, July 26, 2010 1:5= 3=20 PM
To: Autumn Liu; Sriganesh Kini; mpls@ietf.org
Subject:= =20 Determining proper TTL of a tunnel in Fast LSP-alert=20 Mechanism

Dear Authors,
the Section 3.2.2 states new requirement whic= h=20 ends with the sentence:
"An LSP label on the forwarded packet MUST con= tinue=20 to have TTL set to 1."
But at the same time, in Section 6 when outlini= ng=20 direction for future work, it is said that in heterogeneous environment v= alue=20 of TTL must be determined by each node that supports the Fast LSP-alert=20 mechanism. Does that scenario invalidates the requirement put forward in= =20 Section 3.2.2?

Regards,
Greg
--_000_5A5E55DF96F73844AF7DFB0F48721F0F567DB80D0DEUSAACMS0703e_--