Re: [mpls] [Gen-art] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07

Theresa Enghardt <> Tue, 11 February 2020 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB48712093D; Tue, 11 Feb 2020 09:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SIMVz9nxHlna; Tue, 11 Feb 2020 09:23:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66A16120929; Tue, 11 Feb 2020 09:23:27 -0800 (PST)
Received: from user.client.invalid (localhost []) by (Postfix) with ESMTPSA id 09A12B4; Tue, 11 Feb 2020 18:23:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20170414; t=1581441805; bh=9y9ay9aL8BQC2Wmui7gKL3Y5imL/CUGFFs8n8+iiuks=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eKvBzs4E2yDlSJt+AUvNbgDjaz3Scyc+Kdl1LW0LRm2Ijx0p+fMlrM6z/x3LtvUmC UBpRh/bISXAh6qeGzHMiIacFZG3R6q51hcJG9s58JyTD9bYMxdTbdMVDIPSXxglt9W 5Fpu3jUv03ZuEwzmbXv+pcbncFvCgQLKyr7+lMk8ArjYeuTQlvnPiLp73UDUf0SE1/ D5AnnyTYNu5eZkdsHGRbeA8QPDAA/eKPS3XHvC0CIqMhGa6SaQPT6tJN7KWBvtNZ+q WZrwo/KTkrsi5nzLbuqpD5hvwu9CYctzGNEaZh7TtRnGtz/mY+raURsmFhbsLlcv3m BSXT9hJ8kP+ow==
To: Tarek Saad <>
Cc: "" <>, "" <>, "" <>, "" <>
References: <> <>
From: Theresa Enghardt <>
Message-ID: <>
Date: Tue, 11 Feb 2020 18:23:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [mpls] [Gen-art] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 17:23:33 -0000

Hi Tarek,

Thanks for the replies and the new revision, and sorry for the late

Your recent revision addresses most of my comments.

Please find one further comment below:

On 29.12.19 20:38, Tarek Saad wrote:
> […]
>     3.3
>     "the PLR MUST ensure bypass tunnel assignment can satisfy the protected LSP MTU
>     requirements post FRR" - Is there an existing mechanism to do this?
> [TS]: Section 2.6 in RFC3209 describes a mechanism to determine whether a node should fragment or drop a packet that exceeds the Path MTU as discovered using RSVP signaling on primary LSP path. A PLR can leverage the RSVP discovered Path MTU on the backup and primary LSP path to ensure MTU is not exceeded after rerouting traffic on to the bypass tunnel.

I think it'd be helpful to add a reference to that RFC and section here.