Re: [spring] SRv6 Network Programming Endpoint Behavior Registry

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 19 December 2019 18:34 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D493120A12 for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 10:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 NxNTXkC98Qld for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 10:34:14 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA20120A08 for <spring@ietf.org>; Thu, 19 Dec 2019 10:34:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47f0s24LqDz6GDGq; Thu, 19 Dec 2019 10:34:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1576780454; bh=feAZupY/YzqQE37zUyC7pTOWwQAHxaMaxJHqWyJRU5w=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TTijT7LO9m/jWX0XqxjzR4Mf0Im5ZANhpjB/o05wlqisMTVK3vPCt61vi04AuRliS KobYYnsCtr00JTmKf9fNnX3i35CY0kxySEYopMmbbm8yXPzUROJesBVOSFgCkwWoiy VnQfEd4Z6+rgTgBEh2aOfaqJA1r5kA2QmPyYWzMg=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47f0s20jKhz6GDFt; Thu, 19 Dec 2019 10:34:13 -0800 (PST)
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
References: <ef681968-6fd5-1639-99de-c644e7ec5ec0@joelhalpern.com> <B2DC1409-C8E4-4D7E-BDC8-D4CD561B487F@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <38492ce0-936e-af52-5cae-5be265ee7454@joelhalpern.com>
Date: Thu, 19 Dec 2019 13:34:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <B2DC1409-C8E4-4D7E-BDC8-D4CD561B487F@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/BRz2EODELrNqxwyMXqjPtuZ-N00>
Subject: Re: [spring] SRv6 Network Programming Endpoint Behavior Registry
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 18:34:16 -0000

Thanks Pablo.

Given that I know some folks read it differently, could we add some 
additional text.

Maybe in 3.1, after the sentence you quote about FUNCT, add "The means 
of associating the behaviors defined in this document with specific 
FUNCT bit patterns is outside the scope of this document."

And in section 9.2, could we add:  "This registry is established to 
provide consistency for control means which need to refer to these 
behaviors.  It does not represent encodings within SIDs?"

Thank you,
Joel

On 12/19/2019 12:54 PM, Pablo Camarillo (pcamaril) wrote:
> Joel,
> 
> Thank you for your question. Your original understanding is correct.
> 
> The table “SRv6 Endpoint Behaviors” contains behaviors. Behaviors are 
> not present in the SRv6 SIDs. They are only used in the control plane.
> 
> As you requested, here is the relevant piece of text:
> 
> Section 2 (Terminology):
> 
>     SRv6 SID function: The function part of the SID is an opaque
> 
>     identification of a local behavior bound to the SID.  It is formally
> 
>     defined in Section 3.1 
> <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-3.1>of 
> this document.
> 
>     SRv6 segment endpoint behavior: A packet processing behavior executed
> 
>     at an SRv6 segment endpoint.
> 
> Section 3.1 (SID Format):
> 
>     This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
> 
>     where a locator (LOC) is encoded in the L most significant bits of
> 
>     the SID, followed by F bits of function (FUNCT) and A bits of
> 
>     arguments (ARG).
> 
> ...
> 
>     The FUNCT is an opaque identification of a local behavior bound to
> 
>     the SID.
> 
>     The term "function" refers to the bit-string in the SRv6 SID.  The
> 
>     term "behavior" identifies the behavior bound to the SID.
> 
> Section 9.2 (IANA)
> 
>      Table 3: SRv6 Endpoint *Behaviors* Registry
> 
> Thank you,
> 
> Pablo.
> 
> -----Original Message-----
> 
> From: spring <spring-bounces@ietf.org> on behalf of "Joel M. Halpern" 
> <jmh@joelhalpern.com>
> 
> Date: Thursday, 19 December 2019 at 16:35
> 
> To: "spring@ietf.org" <spring@ietf.org>
> 
> Subject: [spring] SRv6 Network Programming Endpoint Behavior Registry
> 
>      In talking with folks, and looking at the draft, I realized that there
> 
>      were two different interpretations of the Endpoint Behavior Registry.
> 
>      I can not tell which is intended.
> 
>      I had assumed, possibly incorrectly, that the list of code points 
> was a
> 
>      list of code points to use in routing and control protocols (so all 
> the
> 
>      control mechanisms sould have inter-changeable semantics for SRv6 
> SIDs.
> 
>      I thus assumed that one would see in routing an advertisement that in
> 
>      some form said "SID prefix X is serviced by node Y and provides
> 
>      functionality of Endpoint Behavior Z, with the remaining bits as 
> defined
> 
>      in the registry."
> 
>      Other folks have read this text as defining the bits that must 
> appear in
> 
>      the explicit SID in the SID list, between the loactor portion and the
> 
>      arguments.  This would provide some small savings in the routing and
> 
>      control infrastructure (but not a lot since there still need to be
> 
>      advertisements about what Endpoint Behaviors each node actually
> 
>      supports.)  This would seem to constrain implementations to use 
> exactly
> 
>      these code point.  I am reminded of diffserv, where we looked at doing
> 
>      that and concluded that operator needs were such that it did not make
> 
>      sense to mandate the on-the-wire code point.
> 
>      Can the authors please clarify which meaning they intend?  Possibly by
> 
>      pointing me at the wording in the document that makes it clear?
> 
>      Thank you,
> 
>      Joel
> 
>      _______________________________________________
> 
>      spring mailing list
> 
>      spring@ietf.org
> 
>      https://www.ietf.org/mailman/listinfo/spring
>