[mpls] Question regarding RFC 5036 on resolving conflict between DOD and DU
Saravanan Narasimhan <saravanannarasimhan@gmail.com> Wed, 02 October 2013 06:43 UTC
Return-Path: <saravanannarasimhan@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74E121E8281 for <mpls@ietfa.amsl.com>; Tue, 1 Oct 2013 23:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4NYsQ94kV67 for <mpls@ietfa.amsl.com>; Tue, 1 Oct 2013 23:43:37 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC421F9E4D for <mpls@ietf.org>; Tue, 1 Oct 2013 23:43:11 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id uo5so461877pbc.37 for <mpls@ietf.org>; Tue, 01 Oct 2013 23:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=AB7u3v7HwALpzzQVCzmBQw2YPhEoOmbVHE2w8wQiUdk=; b=yYNleUy2igxdSjOZ8B4hGBl73pwmqOTMaah3WUlhNUkwN+ZWeNzItbelqjUlmJMoGN iHj/c5BFWp48VJ2JQ7cnTDSORNZxoQreaMASDQXFgk3TB17NDO4gzXLZYJep2TFzLtzY /JxESA18qql6AS5jCmAwW+rb/a/iKq7NXK2y50vbVfLSaHJFMlQvxGvPq9rWRWNzQv/z +4EMbFYVg0sc+xYi/aSPHJBly8Dkp35X+AmWK8+vt1yz6EggN0K1cdxIOvRwwoY3bLNq XqZ41Yx6utbb7UlbVgB2cbU2tFVl8f+Tj5H+VYUXqDDhk5Qngj2ndtM8mw5doqU7wAQo IyLg==
MIME-Version: 1.0
X-Received: by 10.67.23.199 with SMTP id ic7mr1438360pad.73.1380696191447; Tue, 01 Oct 2013 23:43:11 -0700 (PDT)
Received: by 10.70.2.67 with HTTP; Tue, 1 Oct 2013 23:43:11 -0700 (PDT)
Date: Wed, 02 Oct 2013 12:13:11 +0530
Message-ID: <CAPOnYTaw=Frr7P=VV1wzA4gxwN5J3N9_2Y+ABeF9NVBT=cWwvw@mail.gmail.com>
From: Saravanan Narasimhan <saravanannarasimhan@gmail.com>
To: mpls@ietf.org
Content-Type: multipart/alternative; boundary="001a11343f7e08ba0704e7bc622f"
Subject: [mpls] Question regarding RFC 5036 on resolving conflict between DOD and DU
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Oct 2013 06:43:43 -0000
Hello MPLS WG, I have a question regarding the solution given for conflict between DOD and DU. Can you please help me explain the required behavior? Please ignore if the question is very basic. As per RFC 5036 Section 3.5.7.1.3, the problem of a live lock situation and solution to resolve the same is mentioned as below. Downstream LSR (operating in DOD) do not send unsolicited label mapping advertisements for a FEC till it is requested by Upstream LSR (operating in DU). I have captured the snippets from RFC below. 3.5.7.1.3 <http://tools.ietf.org/html/rfc5036#section-3.5.7.1.3>. Downstream on Demand Label Advertisement In general, the upstream LSR is responsible for requesting labelmappings when operating in Downstream on Demand mode. However, unless some rules are followed, it is possible for neighboring LSRs with different advertisement modes to get into a livelock situation where everything is functioning properly, but no labels are distributed. For example, consider two LSRs Ru and Rd where Ru is the upstream LSR and Rd is the downstream LSR for a particular FEC. In this example, Ru is using Downstream Unsolicited advertisement mode and Rd is using Downstream on Demand mode. In this case, Rd may assume that Ru will request a label mapping when it wants one and Ru may assume that Rd will advertise a label if it wants Ru to use one. If Rd and Ru operate as suggested, no labels will be distributed from Rd to Ru. This livelock situation can be avoided if the following rule is observed: an LSR operating in Downstream on Demand mode SHOULD NOT be expected to send unsolicited mapping advertisements. Therefore, if the downstream LSR is operating in Downstream on Demand mode, the upstream LSR is responsible for requesting label mappings as needed. As per RFC 5036 Section A.1.6, Recognize a new FEC, Section FEC.4 (Perform LSR Label Request procedure), if LSR is operating in “Request Never” mode (As per RFC 3031 Section 5.1.2.1, Request never is DU and Liberal Retention mode), it need not send label request message. Question I have is, How an LSP will get formed if Upstream LSR is operating DU and liberal mode and Downstream LSR is operating in DOD? Because Downstream LSR will never send a label mapping message and upstream LSR will never send label request. I feel there is a contradiction between the statements in the RFC 5036 between Sections 3.5.7.1.3 and A.1.6. “To avoid livelock situation, Downstream LSR (operating in DOD) do not send unsolicited label mapping advertisements for a FEC till it is requested by Upstream LSR (operating in DU). Upstream LSR (operating in DU) will request Downstream LSR (operating in DOD) if it requires a mapping for a FEC.” “If Upstream LSR is operating in DU and Liberal mode, it will NEVER send a label request”. Please correct me if i am wrong. Expecting your response. Thank You, Regards, Saravanan Narasimhan
- [mpls] Question regarding RFC 5036 on resolving c… Saravanan Narasimhan