Re: [mpls] Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465)
Loa Andersson <loa@pi.nu> Wed, 23 September 2015 09:08 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AF11AC399 for <mpls@ietfa.amsl.com>; Wed, 23 Sep 2015 02:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq3FEs4AWbAN for <mpls@ietfa.amsl.com>; Wed, 23 Sep 2015 02:08:43 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288231A9302 for <mpls@ietf.org>; Wed, 23 Sep 2015 02:08:43 -0700 (PDT)
Received: from [192.168.0.102] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 0070B18013B2; Wed, 23 Sep 2015 11:08:40 +0200 (CEST)
To: Guijuan Wang 3 <guijuan.wang@ericsson.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "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> <55FBD914.7060205@pi.nu> <DB48EDC97E8BE148B901AE8053957D763A43F9E8@ESGSCMB109.ericsson.se>
From: Loa Andersson <loa@pi.nu>
Message-ID: <56026C17.9030501@pi.nu>
Date: Wed, 23 Sep 2015 11:08:39 +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: <DB48EDC97E8BE148B901AE8053957D763A43F9E8@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/MYx4LHlx9CI3sKaojY8ttvsY75Q>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [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: Wed, 23 Sep 2015 09:08:46 -0000
Jean, To create a RFC that do a update to an other RFC is a rather simple procedure. The issue is mostly that we need someone to work on the document. This of course depends on how urgent we think it is. /Loa On 2015-09-21 17:50, Guijuan Wang 3 wrote: > Hi Deborah, > > Glad to hear from you! Then I shall disregard this rule. > BTW: do you know generally how long the cycle is for the new draft/RFC update for 5035? Thanks! > > > Regards > Guijuan Wang (Jean) > ---------------------------- > IPOS Beijing, Software Engineer > Tel: +86 10 6439 4882 > ECN: 887 17882 > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, September 18, 2015 5:28 PM > To: Guijuan Wang 3; RFC Errata System; Loa Andersson; ina@juniper.net; rhthomas@cisco.com; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net > Cc: mpls@ietf.org > Subject: Rule that is not needed and rejection of [Technical Errata Reported] RFC5036 (4465) > > Jean, > > We have been looking at this quite extensively. > > The consensus is that section 3.5.7.1.3. describes a situation that we can't get into with standards compatible implementation. So you can disregard the rule in section 3.5.7.1.3. > > 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. > > Deborah, > > Can you execute on this? Let me know if you need more info. > > /Loa > 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 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 >> ----- >> >> >> 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 >>
- [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