Re: [spring] SRv6 Network Programming: ENH = 59

Sander Steffann <sander@steffann.nl> Wed, 08 May 2019 18:34 UTC

Return-Path: <sander@steffann.nl>
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 AF7771201D9; Wed, 8 May 2019 11:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 ePZk_jVG-haC; Wed, 8 May 2019 11:34:52 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 DBE85120106; Wed, 8 May 2019 11:34:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id DC34E4A; Wed, 8 May 2019 20:34:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1557340483; bh=7i2SLVCF/czT4/EIeJ6 zyox/0fi6IMO4gLvv5kfhthM=; b=RBx4QGiNRoG8PpQ6C2V7AiT4w0+SISasMt7 2EQwxGvkjLs9S05OdVsPFZiGqGbx7Wk1wuPt2tmW68SlYRo8Uh9ipMnPh1MJ4LwR alaCbf2s/6lVjJtW/nVV2XFohEC9vSzHoJ0hI7BI1aQ4BPV1v5ulwEk93arX3gpX 2xDtZmw4=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7WQBDXK-1iBo; Wed, 8 May 2019 20:34:43 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:40a0:383a:ab:afc1] (unknown [IPv6:2a02:a213:a300:ce80:40a0:383a:ab:afc1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id BDF0549; Wed, 8 May 2019 20:34:42 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <A1AE8525-F7A8-4375-AA53-BCFC466433AC@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_CC60DA3E-22B5-401B-85CA-6AB78A82DA0F"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 08 May 2019 20:34:42 +0200
In-Reply-To: <B2E808BB-E995-4AEE-A9E4-8AA7F92E4939@employees.org>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
To: Ole Troan <otroan@employees.org>
References: <BYAPR05MB4245988C3A47C3665BD91172AE300@BYAPR05MB4245.namprd05.prod.outlook.com> <AA81898A-9E6C-4AD5-9629-4BA283378A79@cisco.com> <BYAPR05MB4245AEA785C959D29E4ECE61AE310@BYAPR05MB4245.namprd05.prod.outlook.com> <58529f07-acfc-3678-5381-4ae271143a45@gmail.com> <94EF12FB-0598-4E76-9A60-0CF67096DD04@employees.org> <CALx6S360dJD4_YcqMMy9k8NOLNdy1UZPAzBNOw1WpAz6iYfWag@mail.gmail.com> <CAO42Z2wBL=h=MKLshKUJa4m6aqTSGn4XQgKao06wKvvreKpB8w@mail.gmail.com> <CALx6S36q+7L7=7m_TgFJL5BN1ryM=9Kgb3sND1Rw+Pmza5OVYQ@mail.gmail.com> <DD003840-92D2-4878-B1CC-CDCB18FA527B@gmail.com> <BYAPR05MB42459C7A22F5AF2F1AB75CD1AE320@BYAPR05MB4245.namprd05.prod.outlook.com> <B2E808BB-E995-4AEE-A9E4-8AA7F92E4939@employees.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/vZzxwvQqpZkCGR9jQFmh7ejdGE0>
Subject: Re: [spring] SRv6 Network Programming: ENH = 59
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: Wed, 08 May 2019 18:34:54 -0000

Hi,

> Ron,
> 
>> <adding the SPRING mailing list, because this is a SPRING draft>
>> 
>> Folks,
>> 
>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 define a set of SIDs that have the following things in common:
>> 
>> - they are consumed by the egress node (SL == 0)
>> - they tell the egress node how to forward the payload into a VPN
>> 
>> If the payload is IPv4, the next-header value in the SRH must be IP4 (value 4).
>> If the payload is IPv6, the next-header value in the SRH must be IPv6 (value 41).
>> If the payload is Ethernet, the next-header value in the SRH must be No Next Header (value 59).
>> 
>> In the interest of consistency, we should probably allocate a new next-header value for Ethernet and use it.
> 
> It's a fairly precious name space though.
> What would a general IP stack do with an Ethernet frame? It's kind of a neat feature that "IP processing terminates here".
> Or are we going to specify Ethernet over IP?

The next-header should identify what follows, so that anybody parsing the packets knows what to expect. Using "No Next Header" should mean "nothing follows". Once we start using No-next-header for "some stuff may follow" it will become very hard to make sense of packets. Overloading the meaning of no-next-header will only create confusion. What when someone starts using it for "encrypted stuff follows"? How do we distinguish between "payload is ethernet" and "payload is encrypted"?

The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me of MPLS implementations that tried to guess what the payload was by looking at the first nibble (if it's 4 then it's probably an IPv4 packet, if it's a 6 then it's probably IPv6 and otherwise we treat it as ethernet). That kind of worked until MAC addresses starting with 4 and 6 started to be used... Let's not make such mistakes again and put proper labels on our payloads.

Cheers,
Sander