[mpls] Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465)

Loa Andersson <loa@pi.nu> Fri, 18 September 2015 09:27 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0BB2D1ACE09 for <mpls@ietfa.amsl.com>; Fri, 18 Sep 2015 02:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VoMfgZfUDrBl for <mpls@ietfa.amsl.com>; Fri, 18 Sep 2015 02:27:54 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EEC1ACE07 for <mpls@ietf.org>; Fri, 18 Sep 2015 02:27:53 -0700 (PDT)
Received: from [] (81-236-221-144-no93.tbcn.telia.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 62FFB18013BE; Fri, 18 Sep 2015 11:27:51 +0200 (CEST)
To: Guijuan Wang 3 <guijuan.wang@ericsson.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Loa Andersson <loa@pi.nu>, "ina@juniper.net" <ina@juniper.net>, "rhthomas@cisco.com" <rhthomas@cisco.com>, "akatlas@gmail.com" <akatlas@gmail.com>, "db3546@att.com" <db3546@att.com>, "aretana@cisco.com" <aretana@cisco.com>, "swallow@cisco.com" <swallow@cisco.com>, "rcallon@juniper.net" <rcallon@juniper.net>
References: <20150906064847.1FD3A1832B6@rfc-editor.org> <DB48EDC97E8BE148B901AE8053957D763A436E19@ESGSCMB109.ericsson.se>
From: Loa Andersson <loa@pi.nu>
Message-ID: <55FBD914.7060205@pi.nu>
Date: Fri, 18 Sep 2015 11:27:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <DB48EDC97E8BE148B901AE8053957D763A436E19@ESGSCMB109.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/BO0Q5wCNCjwp-vPxhhL2YoA8Jnw>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 18 Sep 2015 09:27:56 -0000


We have been looking at this quite extensively.

The consensus is that section describes a situation that we
can't get into with standards compatible implementation. So you can
disregard the rule in  section

We have also agreed that fixing this is not really urgent, and that the
errata process is the wrong vehicle to fix it. We require an Internet
Draft/RFC that updates RFC 5036.

I will therefore ask Deborah to reject the errata, based on the grounds
given above.


Can you execute on this? Let me know if you need more info.

mpls wg co-chair

On 2015-09-16 05:46, Guijuan Wang 3 wrote:
> Dear All,
> For negotiating DoD/DU advertisement mode between LDP peers, there are 2 rules in the RFC. I don't know which one to choose. You are LDP experts, and I am wondering if you could share your ideas on it. Thanks a lot.
> See details in the mail below.
> Regards
> Guijuan Wang (Jean)
> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: Sunday, September 06, 2015 2:49 PM
> To: loa@pi.se; ina@juniper.net; rhthomas@cisco.com; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net
> Cc: Guijuan Wang 3; mpls@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC5036 (4465)
> The following errata report has been submitted for RFC5036, "LDP Specification".
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=4465
> --------------------------------------
> Type: Technical
> Reported by: Label advertisement mode negotiation rule is different in two sections <guijuan.wang@ericsson.com>
> Section: 3.5.3
> Original Text
> -------------
> when the label advertisement mode is different between LSR peers, the resolving rule is defined twice in two chapters, both use "must" or "SHOULD NOT", but they are completely different.
> The first rule:
> In section 3.5.3
>     A, Label Advertisement Discipline
>           (skip the first paragraph)
>           If one LSR proposes Downstream Unsolicited and the other
>           proposes Downstream on Demand, the rules for resolving this
>           difference is:
>           -  If the session is for a label-controlled ATM link or a
>              label-controlled Frame Relay link, then Downstream on Demand
>              MUST be used.
>           -  Otherwise, Downstream Unsolicited MUST be used.
> The second rule:
> In section
>     In general, the upstream LSR is responsible for requesting label
>     mappings 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.
> Corrected Text
> --------------
> It's better to settle down which rule to use for this case.
> Seems the first one is simpler for implementment.
> Or if you want to keep both rules,
> better to enumerate both of those two rules in each section, and say the implement can choose any of them.
> Notes
> -----
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.
> --------------------------------------
> RFC5036 (draft-ietf-mpls-rfc3036bis-04)
> --------------------------------------
> Title               : LDP Specification
> Publication Date    : October 2007
> Author(s)           : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.
> Category            : DRAFT STANDARD
> Source              : Multiprotocol Label Switching
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG