[mpls] draft-bryant-mpls-sfl-control - Control Response Codes

Stewart Bryant <stewart.bryant@gmail.com> Fri, 03 January 2020 18:29 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 4AAA4120013; Fri, 3 Jan 2020 10:29:12 -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, HTML_MESSAGE=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 hdgJAwI83AD8; Fri, 3 Jan 2020 10:29:10 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 470D512002F; Fri, 3 Jan 2020 10:29:10 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id q10so4315078wrm.11; Fri, 03 Jan 2020 10:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Gug00eZzEIOuD23/hcuxgh+hIh3vi1tBy8iHg2SIjNg=; b=OLt5rWvVdpsc+3ViX1vruQGT/CMZSGs5WzAj8fiKFpHQFfCagT67GTq/LHGa1tOfaE TuWcf9N+CLSqLAI3VkCqu7Wd3QfbwojisuyVRu7aM4P7frDyVlT4ACuUenfqKYRS76Fn +kHClWq/Fw0iwFIZR9M5zhCSlV1mwsIIg4FOZWQ9d2no885g+yevk3hLnFPKH4mBst5X p5btCfmVVVPrQKvkp3vNJYZ8vNqQm2+Ng6139Go3rpWL39z/ggN7W1n9haZVxDzjj5WH 6FhLmV5Kr9wpyYGPJhRcvQDd9mHid6uaRA2k4dgDejZeI0paxBa/pNE4e9eVPRX9V+Y8 DDxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Gug00eZzEIOuD23/hcuxgh+hIh3vi1tBy8iHg2SIjNg=; b=RMAS6ocE5aJ0eV24cX3ASGhTddZwRv+BH1vPpCaRgr28W8CB0fD83hxW1eBr98kUGP Y73KdrmeEmRUcTbUXOL3kBNkP4jRYzxbdpq4lCxEP0QHitfcNU2YOd/55kpWO+t4lCkv WIFtNanovuei8hD+14I2NLVIDiVE/+nJ75OvXrAQV7o4tqcAFn6osNCSEk9f53+cDSRO OYYRXYcnAtSFqN8+qG1afkPJIpwZnePOxZFEFc45wXtwH9N6SV17EmA7gxuD5T2OmJBf Z9ZoCf94b88ojXonLKcm8dnZ0VN6mD3ZB/ZAUEVxcuFwCKjMSF1/GA+ukau0V4Kc/UUI 1Qug==
X-Gm-Message-State: APjAAAWIhXa4ARji4c7CvJiC5FA2NbBD9H76TLofX5X88XOTj26oTYdF wl1yHlCdAOisTKp7w2XqJHM=
X-Google-Smtp-Source: APXvYqz4QTB3qH4oHIRs5FdxhZCF/cALwRWI+clrqNKWJtjPpFE0v+Ueu5CB3uvMQAbkWJgMAWew0w==
X-Received: by 2002:adf:b193:: with SMTP id q19mr89268713wra.78.1578076148785; Fri, 03 Jan 2020 10:29:08 -0800 (PST)
Received: from broadband.bt.com ([2a00:23a8:4140:0:3894:cb5f:d37a:1d9c]) by smtp.gmail.com with ESMTPSA id s15sm62076636wrp.4.2020.01.03.10.29.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 10:29:08 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <180BB750-CFD0-4BFE-99CD-4EB095262276@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_51FC5758-A0B9-4667-8730-463972257B8B"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 3 Jan 2020 18:29:07 +0000
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B93BD37@dggeml511-mbx.china.huawei.com>
Cc: "Andrew G. Malis" <agmalis@gmail.com>, "draft-bryant-mpls-sfl-control@ietf.org" <draft-bryant-mpls-sfl-control@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>
To: Zhenghaomian <zhenghaomian@huawei.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43B93BD37@dggeml511-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZyRzErpG5Oad_svoAVBuaaN2Ehs>
Subject: [mpls] draft-bryant-mpls-sfl-control - Control Response Codes
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: Fri, 03 Jan 2020 18:29:12 -0000


> On 3 Jan 2020, at 02:44, Zhenghaomian <zhenghaomian@huawei.com> wrote:
> 
> 
>  
> 5. section 3.1 SFL Control Message
> Regarding the 'Control Code', do we allocate specific value for the query/response actions? For example, we can have request (control code = 0), refresh (control code = 1) and withdraw (control code =2) for a query. Currently there is no such allocations.

Thanks for picking this up. It is quite significant since without these values you cannot implement the protocol.

I brushed over this about five years ago when I quickly pulled the first draft together and so far no one (including the authors) noticed. The implications is that no one has implemented the protocol. Obviously I think it will work, but you cannot be sure with a signalling protocol, and as the WG knows I have been a bit nervous on that point. I wonder if we should downgrade it from PS to Experimental?

The codes need to go into a registry and we have two choices, we create a new registry for it or we recognise the string ties to RFC6374 and add the values to its registry (presumably updating the RFC and renaming the registry).

It is tempting to put the values into RFC6374 because of the strong heritage but I made a mistake like that before with the ACH code points and it caused all sorts of problems, so I will clone the RFC 6374 IANA text and use it to create a new registry. However it makes me wonder if we should be trying to get some commonality in the ACH

In doing that I note that we originally proposed 0x60. I think we meant the next one after 0x59 which is 0x5A, so unless anyone objects I suggest we request 0x5A rather than leave the gap in the registry.

I will compile and upload the latest version, but need to take a much loser look at the error codes and I think we can do a better job than I have done so far.

This will need at least one more revision, but so long as it is on track the chairs could adopt it and allow it to proceed under WG control.

Best regards

Stewart