Re: [mpls] [Technical Errata Reported] RFC5036 (4465)

Guijuan Wang 3 <> Wed, 16 September 2015 03:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4DB6F1B32CC for <>; Tue, 15 Sep 2015 20:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wx8DSoXY7X94 for <>; Tue, 15 Sep 2015 20:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 913721B32C9 for <>; Tue, 15 Sep 2015 20:46:41 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-53-55f8e61d92a6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2D.D8.29154.E16E8F55; Wed, 16 Sep 2015 05:46:39 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 11:46:36 +0800
From: Guijuan Wang 3 <>
To: RFC Errata System <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Technical Errata Reported] RFC5036 (4465)
Thread-Index: AQHQ6HAyGN+hHBbh1Eq13LTQQijpX54+kRaA
Date: Wed, 16 Sep 2015 03:46:36 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM+Jvja78sx+hBi/beCw+PbzEbPH351ZG i8td3ewWHQvvMFr8mzuH2eLw35VsFreWrmS1+LviCotF0/6vbBbTb05ltbg9pYnRgdvjZf8c Ro8pvzeyeuycdZfdY8mSn0we15uusnvMmt7G5tF3T9ajoe0YawBHFJdNSmpOZllqkb5dAlfG 0X+XmQpmK1bsOHGHtYHxtWQXIweHhICJRN86vy5GTiBTTOLCvfVsIGEhgaOMEtOEuxi5gMwl jBJ91+azgdSwCRhI7G+ZyQKSEBHoYJbonfWZFaSBWUBZ4tRdGRBTWMBc4tf5bJByEQELidc3 V7BC2EYSqy80MoHYLAKqEo/P/wQbySvgK3Fy3QxGEFsIqHX23b1gNidQ78Wp18FqGIFO+35q DVgvs4C4xK0n85kgThaQWLLnPDOELSrx8vE/VghbQWL6hnuMEPU6Egt2f2KDsLUlli18zQyx V1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREY zQe3/LbawXjwueMhRgEORiUe3gebv4cKsSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoFx3dRUHreCsgP+vF9alRd9et2Q6GTvuPrwfeepL1M+rFvvELvMaIGe zLeFLZyTHDd0dT6f8nje5n3F+nbHHzVft+S8kPPtV835w1o5S1i+5OwKa6puv/xHPXryi1qR yvA50TL3Leacn5pXc0HqqCHLn/8/Xdes331c8HiAlk3q5emPVBg1lLdYKbEUZyQaajEXFScC ACm3DenHAgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [mpls] [Technical Errata Reported] RFC5036 (4465)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2015 03:46:44 -0000

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.

Guijuan Wang (Jean) 

-----Original Message-----
From: RFC Errata System [] 
Sent: Sunday, September 06, 2015 2:49 PM
Cc: Guijuan Wang 3;;
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:

Type: Technical
Reported by: Label advertisement mode negotiation rule is different in two sections <>

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.


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