RE: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

<> Thu, 12 October 2017 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03579120724; Thu, 12 Oct 2017 00:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ahecCYSFgtoi; Thu, 12 Oct 2017 00:11:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC1FE126B71; Thu, 12 Oct 2017 00:11:21 -0700 (PDT)
Received: from (unknown [xx.xx.xx.4]) by (ESMTP service) with ESMTP id 963B012069B; Thu, 12 Oct 2017 09:11:20 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by (ESMTP service) with ESMTP id 6FE56180068; Thu, 12 Oct 2017 09:11:20 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Thu, 12 Oct 2017 09:11:20 +0200
From: <>
To: Ben Campbell <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Subject: RE: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)
Thread-Topic: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)
Thread-Index: AQHTQxBpVNJO0PvcO0GJhjzke28HZqLfy+kA
Date: Thu, 12 Oct 2017 07:11:19 +0000
Message-ID: <2716_1507792280_59DF1598_2716_45_1_9E32478DFA9976438E7A22F69B08FF921EA86DE8@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_002_9E32478DFA9976438E7A22F69B08FF921EA86DE8OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Oct 2017 07:11:25 -0000

Hi Ben,

Thanks for your review, I will publish a revision soon addressing your comment.
The RFC type (BGP vs info vs STD) has been discussed in the WG, and we are following the way of LFA,rLFA... that are standard track RFCs. Please see the email attached.


-----Original Message-----
From: Ben Campbell [] 
Sent: Thursday, October 12, 2017 06:13
To: The IESG
Subject: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


(Oops, sorry, I entered the bit about addressing my comments for the wrong

- General: Do I undertand correctly that this is a black-box implementation detail? I note that section 4 explicitly says that it is a local-only feature that does not require interoperability. If so, then standards track seems inappropriate. BCP or informational seems to make more sense. Since there are recommendations here, I think BCP is the right choice.  (I note Adam made a similar comment.)

-11: Do you expect this section to stay in the RFC? It is likely to become outdated rather quickly.

Editorial Comments:

- General: Please number the tables.

- sections 2 and 3 and their child sections have quite a few grammar errors.
Please proofread it again. I mention a few specifics below, but doubt I caught everything.

- 2, first paragraph: " That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free." I can't parse that sentence. Is it a run-on sentence, or are there missing words? -- S / "can be work" / "can work"

-3: " may cause high damages for a network."
I suggest " may cause significant network damage".

-4, last paragraph: "This benefit comes at the expense of eliminating transient forwarding loops involving the local router. " How is that an "expense"? Isn't it the whole point?

-5.3, first paragraph and paragraph before figure 4:
The MUST is stated twice. Please avoid redundant normative statements. Even if they agree now, they can cause maintenance issues down the road.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--- Begin Message ---

I will accept whatever the consensus is.

- Stewart

On 05/06/2017 16:22, Chris Bowers wrote:


   It seems to me that this document is not qualitatively different from the LFA, RLFA, and

   node-protecting LFA RFCs which were all published as standards track.  The behavior of the PLR

   in those documents is also a local matter, and in principle can be deployed on a single router without

   the knowledge of the rest of the network (except for allowing establishment of targeted LDP

   sessions in the case of remote LFA).

   Publishing this draft as standards track seems to be consistent with the decision made on those drafts.


   From: Stewart Bryant []
   Sent: Monday, June 5, 2017 4:48 AM
   To: Chris Bowers <><>; Acee Lindem (acee) <><>; RTGWG <><>
   Subject: Re: WG last call for draft-ietf-rtgwg-uloop-delay

   Hi Chris

   An RFC is surely sufficient to specify the behaviour of the router, and communicate to others the capability of a product.

   If multiple routers needed to act identically across the network I could see ST as better, but this is really a single router feature.

   - Stewart

   On 04/06/2017 17:47, Chris Bowers wrote:

      As a WG participant, I think standards track makes most sense, since it specifies a precise behavior for a router under certain conditions.  It is likely that network operators and software implementers will want to use the document as a means of communicating about whether or not a given implementation supports that precise behavior.  In my opinion, a standards track document is the best format to support that interaction.


      From: Acee Lindem (acee) []
      Sent: Saturday, June 3, 2017 6:05 PM
      To: Chris Bowers <><>; RTGWG <><>
      Subject: Re: WG last call for draft-ietf-rtgwg-uloop-delay

      I support advancement and publication of this draft.  I think we should have the discussion of whether or not it should be standards track, BCP, or informational as invariably this question will arise during all the reviews.



      From: rtgwg <<>> on behalf of Chris Bowers <<>>
      Date: Friday, June 2, 2017 at 4:43 PM
      To: Routing WG <<>>
      Subject: WG last call for draft-ietf-rtgwg-uloop-delay


         This email starts the two week WG last call for draft-ietf-rtgwg-uloop-delay.

         Please indicate support for or opposition to the publication of this

         standards track document, along with the reasoning for that support or



         If you are listed as a document author or contributor, please respond to

         this email stating whether or not you are aware of any relevant IPR. The

         response needs to be sent to the RTGWG mailing list. The document will

         not advance to the next stage until a response has been received from

         each author and each individual that has contributed to the document.

         The document currently has the following IPR disclosure associated

         with it.

         This last call will end on Friday June 16th.


         Chris and Jeff

      rtgwg mailing list<>

--- End Message ---