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

Tarek Saad <tsaad.net@gmail.com> Tue, 11 February 2020 19:57 UTC

Return-Path: <tsaad.net@gmail.com>
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 54D3C120A8E; Tue, 11 Feb 2020 11:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ci94dZ3ngTGx; Tue, 11 Feb 2020 11:57:20 -0800 (PST)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA5E120A9F; Tue, 11 Feb 2020 11:57:20 -0800 (PST)
Received: by mail-yb1-xb2a.google.com with SMTP id l75so1747707ybf.6; Tue, 11 Feb 2020 11:57:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=ngzQwiOFyNGT2Y82aAJyOioQDJlB9EKbgOQJhmZNdNE=; b=YyJYl7AjCEOPIKnTT2gvfRxSMSRtvxxSchoz0Dk4895NiWeYzL4evmeHmFBEKAiH9q iCxgO+qNOhWZ8lVQ1MaPhzjOpz5zSnbkYsI7lXl1EtwEjgYILsaMFAc3J1DAn74JG8Ln QCGi3wTEieKMVIjWcsV2BkV0dgtVaKG5vIhQwQALhzrTM+sCx+bo+j/RykzjWCbHY8ou odqoImh7B1mS+qe61wYeReuvOl336PqyuxM0Xq22Meb7MzUQXiPTCQ0kfVXkCRDg46Lf 9HAuXff4Um6Cg/J5gmsnD3y0ZVzzIU9whmpiIZ0ZtllHNatdFAswh7yr/KO44hSHavYE g70Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=ngzQwiOFyNGT2Y82aAJyOioQDJlB9EKbgOQJhmZNdNE=; b=Zon7GxEPy5lGDW5FAEb1dGOE1OmAxHNKCiLxJ1IDGUk/K0v9uK8fuhc+1OJfYBgHsp YEKKm336lU+9zIjpNQRDO/+c9rBz16X4PwLnTMmM3M7h8ktZgmESza70P9vv9Px88C3H JFFAkyJckMy4bweEqDxOOYs2nYRKYYdJ2ZeN+gYvCiO4ox/WNl4spr1mWONEbtx5x0/d zAaQW6l4tQCIgn1sS8SONg8SXZETsQ7I+lTQH3i1GwQ/uww3/b9ZKGZKdFoXw/aMqmbf 1a7f0Xepqk2RNg7nSQfW5UCi0BhGZwL15UIvIzY5J0Q5s2oWk4nEj1KvnqxN7N0GdkGc Ihrg==
X-Gm-Message-State: APjAAAVBp35YBQuXDzTHFkIsCEaSAL4hNb1ngMHKVkC3GLwjpUf7rnRk xch507zMgukk0rCoJEIMoF4=
X-Google-Smtp-Source: APXvYqyaevg4sVDXXNyM3BS/a/vDhjCO8F9ZkgacZ/dBY31UYZ++/qlESFFSWBHBU/pj14wIAkrrDg==
X-Received: by 2002:a25:cb49:: with SMTP id b70mr6938850ybg.233.1581451039246; Tue, 11 Feb 2020 11:57:19 -0800 (PST)
Received: from MN2PR19MB3167.namprd19.prod.outlook.com ([2603:1036:302:409e::5]) by smtp.gmail.com with ESMTPSA id d13sm2398401ywj.91.2020.02.11.11.57.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 11:57:18 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: Theresa Enghardt <ietf@tenghardt.net>, Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>
CC: "gen-art@ietf.org" <gen-art@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>
Thread-Topic: [Gen-art] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07
Thread-Index: ATcwMjg3qcZtvd9N/VCYnEH+LneAyjJENTQ4ZmUzMTK4nHs4Jw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 11 Feb 2020 19:57:17 +0000
Message-ID: <MN2PR19MB31674AEC730A7DBEC2D2F015FC180@MN2PR19MB3167.namprd19.prod.outlook.com>
References: <157650673758.21483.7390224855901982297@ietfa.amsl.com> <7E4C7DF8-7264-4871-A15A-13EFD123B5F2@juniper.net> <25d97422-cda1-1304-ef38-2bbde95eb73f@tenghardt.net>
In-Reply-To: <25d97422-cda1-1304-ef38-2bbde95eb73f@tenghardt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/t3xYVpoCVbi4z_q3_KIMxCMnZFY>
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 19:57:24 -0000

Hi Theresa,

Thanks again for your feedback and confirmation.
The document has been scheduled for a telechat. I accept your suggestion, and I'll hold your comment for the next update of the document.

Regards,
Tarek

On 2/11/20, 12:23 PM, "Theresa Enghardt" <ietf@tenghardt.net> wrote:

    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