Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-control

Tarek Saad <tsaad.net@gmail.com> Wed, 08 January 2020 21:11 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 0D89512012A; Wed, 8 Jan 2020 13:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 iXKTlzZuz_nk; Wed, 8 Jan 2020 13:11:42 -0800 (PST)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 29CDF1208B2; Wed, 8 Jan 2020 13:11:42 -0800 (PST)
Received: by mail-yb1-xb2e.google.com with SMTP id b12so2090262ybg.6; Wed, 08 Jan 2020 13:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=zhI61GayA8SIe9JefgSP25T0Ve5RA9KIv9YJ2UglgfI=; b=indtFZ+gKdSt6yUhRSCTu5JdZyU0w3H0D8IKYsoh7ssNFpl2I8XQoG15dohfRfno64 D5MxgOs1obi2LEXTaWkOwW6srta9VqchDxuzqX40vXr3okynelxINC9ll0SvpMnt5fMQ TtMueOHehvQ5vqmCjkljpG35d3oaqJESwGH8KeyOrYSmdDeM0WT48YVSzKalIINQRSsM ZnvF3Xga73jVU+XDG/fbJAO/ZJjjKfDLJ9zI+Ae5heUOvTyqYzE/BVRANM9pH3qdgU5B 271Qna1QjBf6ISEjIRIECfyGMCh9Ez7qtCri6sSXOn3mHRFfTYBk8rcKb0QSIKa/dGph svzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=zhI61GayA8SIe9JefgSP25T0Ve5RA9KIv9YJ2UglgfI=; b=Uq1bVLiP84zDsxJwEko5cGB01r7dqAJ/p2HpNrkQI3+28z/ESiTrldf/4cYzp1afEN +52vbhOUOwlKpYv8w5QahoyOiaT7h2zdliG/jQ1NDFP8LtFtzNMAQJXiZyQhxqOaty6O O8h3mquE8xf7I85GVQrxBChOhtaITLf0YjIgnxLP+B3mQET2lSsg0uQ75PpKleVxOHIt pIpOi2PNJCJ9XQEhQSdhrVuoYe6tukM1wH/0FmTMf9NIxgppE9Eetu0YbX9kf1/YsCSa I75opQ+MnmFNLXYaHwXjFZERdZyA9rWLDCxc1XC9vx0GMYtwjhrx4CdeCC6PsKo0zsdM OiGw==
X-Gm-Message-State: APjAAAV2v0aQjoyqYYDTvOHIXBoViaOwlOJqUWpgxKhGrmrLUWzLK0xK 9qjmQzEjMwY3QUWG5oFkEgUXieWYEuk=
X-Google-Smtp-Source: APXvYqzF+u7E0sRLmRSv+OlcUu9roP2wosP5NalzHgbacSrRYAQjTrZ71044g2ax4u4GKmfVOCzxlw==
X-Received: by 2002:a25:cc4f:: with SMTP id l76mr5173563ybf.327.1578517900918; Wed, 08 Jan 2020 13:11:40 -0800 (PST)
Received: from MN2PR19MB3167.namprd19.prod.outlook.com ([2603:1036:302:409e::5]) by smtp.gmail.com with ESMTPSA id e63sm1909299ywd.64.2020.01.08.13.11.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 13:11:40 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: "draft-bryant-mpls-sfl-control@ietf.org" <draft-bryant-mpls-sfl-control@ietf.org>, mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>
Thread-Topic: MPLS-RT review of draft-bryant-mpls-sfl-control
Thread-Index: ATAxRUIz0qsKtGHlIv6ANjLcHwobncsqRen/
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 8 Jan 2020 21:11:38 +0000
Message-ID: <MN2PR19MB3167E4560DF347F62FB94D43FC3E0@MN2PR19MB3167.namprd19.prod.outlook.com>
References: <MN2PR19MB3167536B80B3E8E73FF8A148FC230@MN2PR19MB3167.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB3167536B80B3E8E73FF8A148FC230@MN2PR19MB3167.namprd19.prod.outlook.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/j5KzRjTSmIUCtowJDsF61WYHcS4>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-control
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, 08 Jan 2020 21:11:50 -0000

Hi authors,

Again, thanks for working on this document.

For completeness of my review, please see inline for the comments I expect be concluded before the document is adopted.

On 1/3/20, 1:43 PM, "Tarek Saad" <tsaad.net@gmail.com> wrote:

    Hi,
    
    I’ve been selected as an MPLS-RT reviewer for this draft being considered for WG adoption.
    After reading it, I have the following comments on it:
    
    1. Since the SFL control protocol uses ACH – the SFL control messages flow in-band over the MPLS datapath (e.g. PW, LSP, etc.). Is this restriction required? How does it differ from other protocol(s) that do out-of-band control messaging -- e.g. BGP, T-LDP, etc. that allocate PW labels?
    2. It would be useful to have text for any considerations/comparison given to existing control plane protocols that can do same/similar function and if/why they are not adopted/extended
[TS]: I'm OK to defer adding the text to the document on this. Howver, it'll be very useful to have your initial thoughts on this shared on the list so the WG has better understanding why the proposal is more favorable/suitable.

For the remaining points below, I think these can be addressed after WG adopts the document.

Regards,
Tarek

    3. Section 3 mentions, the SFL ACH can be carried over PW, or LSP. What about MPLS section/i.e. MPLS link? E.g. for use with single-hop LM? Any restrictions for this?

    4. Section 3.1:
    	a. Some flags may be meaningful at one side (i.e. either querier or responder) and depending if CC flag is R set or not -- some flags may be invalid if received - e.g. W Lflag is not expected to be received by a querier. Do such cases necessitate errors? How is it handled - rejecting the whole SFL batch or the whole SFL message?
    	b. s/Responser/Responder
    5. Section 3.2.1
    	a. May clarify that “SFL Control Request” message, is “SFL Control Message” with CC Flag (R=1)
    	b. Can the same message serve as Request, Refresh and Withdraw for a specific Batch? i.e. to allow existing (allocated) SFL batch to be resized by refreshing some existing SFL(s), withdrawing some, and requesting some new ones? If yes, may clarify it - since as-is the sections defined in the document hint that a message can be one of (request/refresh/withdraw) at any time
    	c. In cases where a  node functions as both requester and responder, can same session Id be used for sending requests and respond by the same node?
    	d. As per https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework, the high runner case for SFL is for additional action packet counter - is this action assumed implicit always for all SFL(s)? Is there a way in the protocol to associate different/additional action with a specific SFL?
    	e. “A Querier MUST NOT send an expired SFL to a Responder since to do so may invalidate another SFL operation.”: this may be considered a security for a DoS, you may want to highlight this in the security section
    	f. s/SFV/SFL
    	g. The text “All other LFlags are cleared.” Seem to override the previous text that. V LFlag can be also set at same time to cover requesting a specific label
    6. For unidirectional LSP(s), how is the return path for response messages specified? Is the Querier source address derived from LSP control plane state? Or, is the SA TLV from RFC6374 for p2p unidirectional added too? In this case, how to force the SFL Control Response message – e.g. be IP routed back or go over a specific reverse LSP?
    7. "3.2.3.  Withdraw  
               [...] via an appropriate path.", does this mean control messages can be sent over any path (other than the underlying LSP or PW)?
    8. "
       A Querier MUST wait a configured time (suggested wait of 60 seconds)
       before reattempting a Withdraw request.", may be useful to highlight why the restriction? Is this to avoid frequent sending of control plane messaging?
    
    Regards,
    Tarek