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

Theresa Enghardt <ietf@tenghardt.net> Tue, 11 February 2020 17:23 UTC

Return-Path: <ietf@tenghardt.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB48712093D; Tue, 11 Feb 2020 09:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
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 SIMVz9nxHlna; Tue, 11 Feb 2020 09:23:30 -0800 (PST)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A16120929; Tue, 11 Feb 2020 09:23:27 -0800 (PST)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 09A12B4; Tue, 11 Feb 2020 18:23:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; 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 <tsaad=40juniper.net@dmarc.ietf.org>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org" <draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
References: <157650673758.21483.7390224855901982297@ietfa.amsl.com> <7E4C7DF8-7264-4871-A15A-13EFD123B5F2@juniper.net>
From: Theresa Enghardt <ietf@tenghardt.net>
Message-ID: <25d97422-cda1-1304-ef38-2bbde95eb73f@tenghardt.net>
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: <7E4C7DF8-7264-4871-A15A-13EFD123B5F2@juniper.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/1hrVKKmd7LJ1CEuGOv-bsGCoZG8>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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
response.

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.

Best,
Theresa