[mpls] [Errata Rejected] RFC5036 (4465)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 18 November 2015 19:04 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19411A7012; Wed, 18 Nov 2015 11:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.487
X-Spam-Level:
X-Spam-Status: No, score=-107.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmawSTRZ0wcP; Wed, 18 Nov 2015 11:04:33 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2B51A6FE9; Wed, 18 Nov 2015 11:04:33 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 7B801181EAD; Wed, 18 Nov 2015 11:03:14 -0800 (PST)
To: guijuan.wang@ericsson.com, loa@pi.se, ina@juniper.net, rhthomas@cisco.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20151118190314.7B801181EAD@rfc-editor.org>
Date: Wed, 18 Nov 2015 11:03:14 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/lVXGpu-_G2OR_8nKjJ0yjBWD-E8>
Cc: mpls@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [mpls] [Errata Rejected] 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: Wed, 18 Nov 2015 19:04:35 -0000
The following errata report has been rejected for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=4465 -------------------------------------- Status: Rejected Type: Technical Reported by: Label advertisement mode negotiation rule is different in two sections <guijuan.wang@ericsson.com> Date Reported: 2015-09-05 Rejected by: Deborah Brungard (IESG) 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 3.5.7.1.3. 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 ----- --VERIFIER NOTES-- This suggested errata requires an update to the RFC, which requires consensus. -------------------------------------- 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
- [mpls] [Technical Errata Reported] RFC5036 (4465) RFC Errata System
- Re: [mpls] [Technical Errata Reported] RFC5036 (4… Guijuan Wang 3
- [mpls] Rule that is not needed and rejection of [… Loa Andersson
- Re: [mpls] Rule that is not needed and rejection … Guijuan Wang 3
- Re: [mpls] Rule that is not needed and rejection … Loa Andersson
- Re: [mpls] Rule that is not needed and rejection … Guijuan Wang 3
- [mpls] [Errata Rejected] RFC5036 (4465) RFC Errata System