Re: [Teas] RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04

"Rakesh Gandhi (rgandhi)" <> Tue, 28 August 2018 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C63D8130F24; Tue, 28 Aug 2018 07:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uabF-SFMTxzO; Tue, 28 Aug 2018 07:48:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B255130DD0; Tue, 28 Aug 2018 07:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=57082; q=dns/txt; s=iport; t=1535467710; x=1536677310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IKh6YuvyWigza/EIYYHBE41inIQp5vpKmxw/lh/bNoo=; b=H/XrJine0CoXBU680vVH6Ew7wTMIbtjXRHONBoQmuro74fnUvpBAg7lC WZCycsyTaQwDwTZVnIVrfgcve0XDrKGPvI9G7DuwIccRT/xvLyDxFy+pb XpCaCQH8lau+67AqnQ22GDNUI/ByhgDEx6BimeXNJez0T8Vw9OWgEolzJ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.53,299,1531785600"; d="scan'208,217";a="441097470"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 14:48:28 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w7SEmSn8022487 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2018 14:48:28 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 28 Aug 2018 09:48:27 -0500
Received: from ([]) by ([]) with mapi id 15.00.1367.000; Tue, 28 Aug 2018 09:48:27 -0500
From: "Rakesh Gandhi (rgandhi)" <>
To: Daniele Ceccarelli <>, "<> (" <>
CC: "" <>, "TEAS WG (" <>, "" <>
Thread-Topic: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04
Thread-Index: AdQlm/SWFN83nAOVQmKg2miyrumEwAChYgCAAc1HYgACQwcaIAGg9jiA
Date: Tue, 28 Aug 2018 14:48:27 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E51A0C3E660448CAB39B45EB25001012ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Teas] RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Aug 2018 14:48:34 -0000

Hi Daniele,

Thank you for the review comments and feedbacks.

We have addressed the comments in the latest draft @



Please let us know if you ok with the document.


From: Daniele Ceccarelli <>
Date: Monday, August 20, 2018 at 4:56 AM
To: "=SMTP:rgandhi@cisco. com" <>om>, "<> (" <>
Cc: "" <>rg>, "TEAS WG (" <>rg>, "" <>
Subject: RE: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04

Hi Rakesh,

thanks for the update.

The terminology section is a very minor issues, the important thing is that it is there. I would prefer to have it at the beginning as sometimes I found it hard to read the intro where terms not yet defined were used.
Please also address the comment from Deborah to add one or two sentences to section 5 on what happens if one of the nodes does not support the feature.

When that is done I’m ok with the document.

From: Rakesh Gandhi (rgandhi) <>
Sent: mercoledì 8 agosto 2018 21:30
To: Daniele Ceccarelli <>om>; <> ( <>
Cc:; TEAS WG ( <>rg>;
Subject: Re: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04

Hi Daniele,

FYI, we have uploaded this version. Please let us know if you have additional comments.

A diff from the previous version is available at:

Rakesh (for authors)

From: "=SMTP:rgandhi@cisco. com" <<>>
Date: Monday, July 30, 2018 at 11:22 AM
To: Daniele Ceccarelli <<>>, "<<>> (<>)" <<>>
Cc: "<>" <<>>, "TEAS WG (<>)" <<>>, "<>" <<>>
Subject: Re: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04

Hi Daniele,

Many thanks for the review of the document and your suggestions.
Diff file is for the updated document is attached.
Please see inline <RG>…

From: Daniele Ceccarelli <<>>
Date: Saturday, July 28, 2018 at 10:28 AM
To: "<<>> (<>)" <<>>
Cc: "<>" <<>>, "TEAS WG (<>)" <<>>, "<>" <<>>
Subject: RtgDir review: draft-ietf-teas-assoc-corouted-bidir-frr-04
Resent-From: <<>>
Resent-To: "=SMTP:rgandhi@cisco. com" <<>>, <<>>, <<>>, Lou Berger <<>>, <<>>, <<>>, <<>>, DEBORAH BRUNGARD <<>>, <<>>, Vishnu Beeram <<>>, <<>>
Resent-Date: Saturday, July 28, 2018 at 10:28 AM


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​<>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-assoc-corouted-bidir-frr-04
Reviewer: Daniele Ceccarelli
Review Date: 27/07/2018
IETF LC End Date: date-if-known
Intended Status: Standard track


  *   I have some minor concerns about this document that I think should be resolved before publication.


  *   The document is very well written and the problem clearly stated (even if called overview 😊 ). The second part is a bit harder to follow but I don’t see how to make the procedure section easier to read.
<RG> Ok, thanks.

  *   It is not clear to me why there is an “example” of Extended Association ID in the appendix. RFC 6780 just says it “contains data that is additional information to support unique identification.” But doesn’t describe how it should be filled. Does this mean there is no standard format for it?
<RG> Right. Example shown in the Appendix is one un-ambiguous way to populate it for associated bidirectional LSPs.

Major Issues:


Minor Issues:

  *   Moving the terminology section before the introduction would improve readability, since the terms defined in the terminology section are frequently used in the introduction.
<RG> I am not familiar with an RFC where terminology is the first section. I am fine either way, please let me know if you prefer this way.

  *   When I read the title of section 3 (overview), I thought “why an overview is needed if there is an introduction?”. Actually the text in that section is very useful but more than an overview I would call it a problem statement (or something like that).
<RG> Corrected.

  *   The usage of RFC 2119 (or should we reference RFC 8174 ??) is not congruent all over the document. E.g. section 4.1

  o  The downstream PLR node always initiates the bypass tunnel

      assignment for the forward LSP.  The upstream PLR (forward

      direction LSP MP) node simply reflects the associated bypass

      tunnel assignment for the reverse direction LSP.  The upstream PLR

      node MUST NOT initiate the bypass tunnel assignment.

<RG> Corrected.


  *   Section1: “(G)Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs)”. This formatting doesn’t make much sense. In the first instance the brackets are used to say MPLS or GMPLS while in the other ones to define the acronyms.
<RG> Corrected.

  *   Section 3.1 there is no need to repeat twice that Bypass tunnel N uses path B-H-I-C and Bypass tunnel S path B-F-G-C. The second time the bracket can be dropped.
<RG> Corrected.

  *   Section 4.1.1. -  s/SHOULD trigger the procedure/ SHOULD trigger procedure
<RG> Corrected.
Rakesh (for authors)