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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 04 June 2020 09:11 UTC

Return-Path: <stewart.bryant@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 064853A0A8F; Thu, 4 Jun 2020 02:11:39 -0700 (PDT)
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 W6J7sdYrwyeC; Thu, 4 Jun 2020 02:11:37 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 27AAF3A0A7E; Thu, 4 Jun 2020 02:11:34 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id k26so4804539wmi.4; Thu, 04 Jun 2020 02:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBHBieKLizj6thFa/pmF0ILPTXddhKuDTBGL0/3/EUs=; b=RcobczNcMIK9E3pjfb2k8hkfPHHV6tsgMeiI4MpcQoTaN65FqcYmX72ZHtVAoTggyM ITg4FZzzPSigWCCPken6fXwa/wRrxMt9rUiFkJrt4Z3JLLGuNBPxflgYVLtpItdsp8KQ TEh7/ek6Dd6GuUaQhDs6MzHE0QEMTotGGgKog/alwgEi9fPxKhh2WQiKdWx5Wo2rdUi8 ja4fHTTQCMpIR5GBOiWnUu8Ee6C/qjUJ7IYIrdjxpO2BoHT1vPYNo+LLVSdPEGO/fDNw 2RenTyet/qp7LceRl5WwReVppSbXZJ+7fOckJ13tEkQr7hHa7U9y0UKw9Y1AOWr8fVP4 YnVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBHBieKLizj6thFa/pmF0ILPTXddhKuDTBGL0/3/EUs=; b=cP0ES1Nr22QJcYIFZPxJqrpzhzmmQ4ZaKqqlC8JwvinIkfwr5/3WrPRmJRL2unk5JK ZkJUqUHAIzufZOZWdGrOZJNyVCdP6B9hkIas7Mrff4MZgXwfw2S+U2hRwi2KC/oBDOHc Eo774f+/rBmZcLpigbxxO9h39DjfVDhVmsboQNuEg43xOT/zHp39zAUFaDPyL3VgwONs B6TJlD4TrJVcn9ZGQDds9WAbH4mNprlxFl9jxmQSWjlMj7k49AcWdxsJ7b8WIuanYQkv Y9jAUzxqxqbmHkxioQZLIey89XpPCh/RXzBd1+rk+hBADT3d1rBlAi6KSFQkDcYpJ2PY fh6w==
X-Gm-Message-State: AOAM531l6y2pA2t1saG5lGBw62UDpffnFLdbijG+GHzavyXzUwWQSIRb P4nYaxKnbRX6smvl+4XdmcvG2H3reqI=
X-Google-Smtp-Source: ABdhPJzg5rO+Lht1/PaYu+tuDCek30V8yOJV5ur9/5B4i4zABgVOtRQmwJFcBGUc7f5m4jbEjZZMzQ==
X-Received: by 2002:a7b:cb13:: with SMTP id u19mr3056443wmj.86.1591261892341; Thu, 04 Jun 2020 02:11:32 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id c16sm7066541wrx.4.2020.06.04.02.11.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 02:11:31 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <MN2PR19MB3167536B80B3E8E73FF8A148FC230@MN2PR19MB3167.namprd19.prod.outlook.com>
Date: Thu, 4 Jun 2020 10:11:27 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "draft-bryant-mpls-sfl-control@ietf.org" <draft-bryant-mpls-sfl-control@ietf.org>, mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <73DDE93C-2FD1-48B1-975F-92A2E8E2F598@gmail.com>
References: <MN2PR19MB3167536B80B3E8E73FF8A148FC230@MN2PR19MB3167.namprd19.prod.outlook.com>
To: Tarek Saad <tsaad.net@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/AK7kAoAfiAKfFUZG7bQfpcFsyxw>
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: Thu, 04 Jun 2020 09:11:39 -0000

Dear Tarek

Tjhankl you for your review, please see below:

> On 3 Jan 2020, at 18:43, 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?

SB> BGP and LDP run over TCP, which in turn runs over IP.

This simple protocol can run directly over the LSP and thus can run over MPLS without IP, although I anticipate that we could run the same format over IP if needed, for instance using MPLS over UDP, and would seek the advice of the MPLS WG on how much to put in the text to cover this case.

> 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

SB>There was a laundry list of protocols that people wanted, but when I asked for help none was forthcoming. I then offered to continue to
Work on this design sketch I made several years ago and the WG asked me to complete this.  I have text in tat says that this is a method that can be used without changing the existing protocols, and that alternatives are not prohibited. In the circumstances that should be sufficient.

> 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?

SB> I cannot see a restriction, can you? The packet will arrive on the GAL if there is PHP and on the delivery label in other circumstances. This is regular MPLS

> 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?

SB> There is a note that the error cases need more work, and I would like to do this as part of the WG process. I would certainly be interested in the observations of the WG.

> 	b. s/Responser/Responder

SB> Done

> Section 3.2.1
> 	a. May clarify that “SFL Control Request” message, is “SFL Control Message” with CC Flag (R=1)

SB> There is clearly some clarifying text needed. As written the text is a clone of the RFC 6374 control text. There is advantage in making it the same as RFC 6374 for familiarity and possible code reuse. On the other hand the terms would be wrong in a control protocol designed in isolation and seem a bit strange.

I would appreciate the view of the WG.

> 	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

SB> That reflects the RFC 6374 heritage. Having a single instruction per message simplifies things and I am include to leave it that way, but I would talk this on advisement by the WG. That is why I really would like to get this into the WG to get their wisdom on the matter.

> 	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?

SB> The session identifier has the context of the LSP and the request vector so yes, I think the same session ID can be used in both cases.
If this were not the case there would be a race condition to deal with as both ends of a link initiated, so I think the answer has to be yes and the  node has to keep the context.

> 	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?

SB> No, we are just doing the label exchange with this. If we think that we need to add an action registry we can do that, or we can manage it another way. What is the view of the WG?

> 	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

SB> Well MPLS is fragile against this and the assumption is that MPLS is sheltered from bad actors. It would not be a DoS attack, it would trigger a malfunction. I think this is covered by the well managed network text in the security section.

> 	f. s/SFV/SFL

SB> Done

> 	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

SB> I just looked again at the text and that expression seems only to be used on the send side so it lived in the context of the V Flag having been set or cleared appropriately and be overridden. Can you see a case where the wrong thing would happen?

> 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?

SB> I will adds some text to cover this in version 08. I will upload 07 and we can then decide if it needs to be fixed before WG adoption.

> 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)?

SB> Yes. We use the term a number of times and it is intended to add generality since restricting the path does not add any useful benefit.

> 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?
> 
SB> Text now says

A Querier MUST wait a configured time (suggested wait of 60 seconds)
before re-attempting a Withdraw request.
No more than three Withdraw
requests SHOULD be made. These restricctions are to prevent overloading the
control plane of the actioning router.


Best regards


Stewart

> Regards,
> Tarek
> 
> 
>