[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