Re: [mpls] Martin Vigoureux's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)

Tarek Saad <tsaad.net@gmail.com> Wed, 26 February 2020 18:34 UTC

Return-Path: <tsaad.net@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F007D3A10AC; Wed, 26 Feb 2020 10:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RE1LLd3bwkTw; Wed, 26 Feb 2020 10:34:22 -0800 (PST)
Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 1F0453A105B; Wed, 26 Feb 2020 10:34:21 -0800 (PST)
Received: by mail-yw1-xc2d.google.com with SMTP id x184so385218ywd.6; Wed, 26 Feb 2020 10:34:21 -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=ZNAw2Mn27iN+aFI1/laF/FPAiG2iY9WyoF1149WDB2c=; b=S1hKtJBtOGUWcjPV9Qp7kwrru7XeCwn4clHmKpp12SX3FCL50dtdSYF8+WM8p7eRmI hMfzas5XQyV990IVhxn01OiGIOBjmjLlovEsHOWL3MexjIFq/KHkbnehQR7W1lE7n1Ri GuRXdhPkgR9o6IBteDAES/Ym6f2MyU5pC8Yhde/BaEtKFbmQqkli313Z0kCwejitGde2 WyV8utMcCw2WzZ1nL3V4czMb2ZfOlEUsEon/R0zyrWiFthdY4WACSYW7LAZXGa4ow3mh coip5EAzc1reBa7EOkx3CcEOP45tOwABHGXHjv+zPGeUPIxkYhjzu3GQR1Q2QrRpVpZJ E0+A==
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=ZNAw2Mn27iN+aFI1/laF/FPAiG2iY9WyoF1149WDB2c=; b=B2iO/luXX+wzcroBEufOQvBoNMILonfxh0U4vsJKwqQxkCuTFrYRDIjdt7Z5I5METV EoQFcS/xGkXSO+kfiHsj9Zg5baQPVKPrMk7RzKUTdI/y4TLDv3qG5/EJCQ1w2sA76iIS AtEN96LWJ1fCBPgtLLSVQADlDsDRZ1UiexJ+Xd15WQYK77rAUhQSie+SRgIv84ShbQEh 9PiEKekaVOeSyySexkvDwSthpecMPp5kdtiEYN8dMvgtxQhDpjD3l6amN2Gg/SHCKAWK FqaD8tpfa1VsG3Z7bHgsuVmj4rLaCIzgzxLrKQV5yOZ8UCnE5A0e1usPWmL5Yj7QMXMO 115Q==
X-Gm-Message-State: APjAAAWKNfjWHhTMx6E+TTdd9t2Gk5Q/PjYdnNK7VHdXk2STcZo2aCXu 3ZzetKWyJINwHrDUNLT4ipk=
X-Google-Smtp-Source: APXvYqztIYZ/fYrJWGEFPODtBfvpQooQEOMXPUc87j4kETkHu2oAkG009VIqtOf1Yk6GZODYiSjvbA==
X-Received: by 2002:a05:6902:68c:: with SMTP id i12mr213181ybt.51.1582742060374; Wed, 26 Feb 2020 10:34:20 -0800 (PST)
Received: from MN2PR19MB3167.namprd19.prod.outlook.com ([2603:1036:302:409e::5]) by smtp.gmail.com with ESMTPSA id l19sm1335907ywe.29.2020.02.26.10.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 10:34:19 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" <draft-ietf-mpls-summary-frr-rsvpte@ietf.org>, Nicolai Leymann <n.leymann@telekom.de>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)
Thread-Index: AXIuNDEzHpYnpqsUlj6Yda5HHNy5+cd9PlCJ
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 26 Feb 2020 18:34:17 +0000
Message-ID: <MN2PR19MB3167EB264FD4E66C34AD03BAFCEA0@MN2PR19MB3167.namprd19.prod.outlook.com>
References: <158216251073.17710.2187878116475113514.idtracker@ietfa.amsl.com>
In-Reply-To: <158216251073.17710.2187878116475113514.idtracker@ietfa.amsl.com>
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/mpls/xHaskqs0YpM0DoLWXT348LqAq64>
Subject: Re: [mpls] Martin Vigoureux's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 18:34:34 -0000

Thank you Martin for reviewing the document and providing comments. We have uploaded version -09 that addresses them.
Please see inline for responses.

On 2/19/20, 8:35 PM, "Martin Vigoureux via Datatracker" <noreply@ietf.org> wrote:

    Martin Vigoureux has entered the following ballot position for
    draft-ietf-mpls-summary-frr-rsvpte-08: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-mpls-summary-frr-rsvpte/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Hello
    
    it's getting late here so please dismiss any tiredness induced comment.
    
           3.1.1.  IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID  . . .   7
           3.1.2.  IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID  . . .   8
    IPv4 and IPv6 appear twice. Not sure the second is needed.
[TS]: Indeed. Corrected now:
NEW:
           3.1.1.  IPv4 B-SFRR-Ready Extended ASSOCIATION ID  . . .   7
           3.1.2.  IPv6 B-SFRR-Ready Extended ASSOCIATION ID  . . .   8
    
    You leave unspecified how to set the Global Association Source of Extended
    ASSOCIATION object. If it is as in 6780 then I suggest to explicitly say it.
    Indeed you explicitly refer to 4872 for the three other fields.
[TS]: we don’t deviate from the recommendations in rfc6780. We explicitly added this in the text too.
NEW:
   The Extended ASSOCIATION object's Global Association Source MUST be
   set according to the rules defined in [RFC6780].
END
    
    It might be a stupid thing to do, but the text is not clear on whether an IPv4
    B-SFRR-Ready Extended ASSOCIATION ID can be added as the Extended Association
    ID of an IPv6 Extended ASSOCIATION object and vice versa. Text is clear for
    B-SFRR-Active however.
[TS]: Indeed. We revised to make it explicit for B-SFRR-Ready Extended ASSOCIATION ID too.
NEW:
3.1.1.  IPv4 B-SFRR-Ready Extended ASSOCIATION ID

   The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association
   type is carried inside the IPv4 Extended ASSOCIATION object and has
   the following format:

and

3.1.2.  IPv6 B-SFRR-Ready Extended ASSOCIATION ID

   The IPv6 Extended ASSOCIATION ID for the B-SFRR-Ready association
   type is carried inside the IPv6 Extended ASSOCIATION object and has
   the following format:
END
    
    Why the MP does the test on the Bypass_Destination_Address:
       When forwarding an RSVP Path message downstream, the MP SHOULD remove
       any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association
       ID contains Bypass_Destination_Address matching the MP node address.
    while the PLR does it on the association source (and not on the
    Bypass_Source_Address):
       Note, when forwarding an RSVP Resv message upstream, the PLR node
       SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
       Association Source matches the PLR node address.
[TS]: this was modified to check against Bypass_Source_IPv4/6_Address
NEW:
   Note, when forwarding an RSVP Resv message upstream, the PLR node
   SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
   Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address field
   matches any of the PLR node addresses.
END

    
    By the way, Bypass_Destination_Address does not exist per se in your spec, only
    Bypass_Destination_IPv4_Address and Bypass_Destination_IPv6_Address
[TS]: yes, this was revised to mention Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address accordingly.
    
       The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
       ID is set to the common RSVP_HOP that was used by the PLR in
       Section 3.3 of this document.
    There is no mention of RSVP_HOP in Section 3.3
    
[TS]: this text was revised to provide more clarity:
NEW:
   The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
   ID is set to a common object that will be applied to all LSPs
   associated with the Bypass_Group_Identifiers that are carried in the
   B-SFRR-Active Extended ASSOCIATION ID.
END

Regards,
Tarek