[MPLS] LDP GR query

little_star@huawei.com Mon, 23 October 2006 01:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GboNf-0001Cm-Ex; Sun, 22 Oct 2006 21:13:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GboNe-0001Ch-0t for mpls@lists.ietf.org; Sun, 22 Oct 2006 21:13:30 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GboNa-00060S-Q2 for mpls@lists.ietf.org; Sun, 22 Oct 2006 21:13:30 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K0058REXQNS@szxga02-in.huawei.com> for mpls@lists.ietf.org; Mon, 23 Oct 2006 09:32:14 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K00KEKEXP91@szxga02-in.huawei.com> for mpls@lists.ietf.org; Mon, 23 Oct 2006 09:32:14 +0800 (CST)
Received: from w22283a ([10.111.9.56]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7K00K97ENMJ5@szxml04-in.huawei.com> for mpls@lists.ietf.org; Mon, 23 Oct 2006 09:26:11 +0800 (CST)
Date: Mon, 23 Oct 2006 09:12:36 +0800
From: little_star@huawei.com
Subject: [MPLS] LDP GR query
To: mpls@lists.ietf.org
Message-id: <004001c6f640$53e22ff0$38096f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: little_star@huawei.com
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0949475748=="
Errors-To: mpls-bounces@lists.ietf.org

空白Hi  M. Leelanivas , Y. Rekhter and R. Aggarwal,



 I have a question about RFC 3478 .Please see the below graph.



RTA----LANSWITCH-×---LANSWITCH----RTB

 

If the link between the two LAN-SWITCH is down ,RTA and RTB will think the other side LSR restarting,so these two LSR will think themselves as helper router. They will perform GR flow together.

In this scenario ,we can use other mechanism ( such as BFD) to avoid performing GR process . But if we don’t have other mechanism, then these two LSR will perform GR process.

 Another case ,

the LDP session will be down is when the LSR’s neighbor can’t send out it’s packet, including hello packet or keepalive packet, if the control plane of it’s neighbor is very busy or occurs some error ,then the LDP session will be down. In this case the LSR will conclude that it’s neighbor restart and the LSR will implement GR flow.

I  want to know whether the LSR clearly signal it’s neighbor that it is restarting through FT session TLV in RFC 3478 .


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls