Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Sander Steffann <sander@steffann.nl> Thu, 12 March 2020 13:44 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 894F93A092D; Thu, 12 Mar 2020 06:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (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 96sOk1MtdjXy; Thu, 12 Mar 2020 06:44:26 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 4033E3A092C; Thu, 12 Mar 2020 06:44:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 19F064C; Thu, 12 Mar 2020 14:43:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1584020631; bh=SLMv2irukBuOQCJzw3av96sIWsbEcroUV3QoAbmZVxo=; b=T sE7knItLlEQoeYR5/vq0RxKa4i5tbqTB+L7ZviFf0jpyTUh/DKs+/daXvd57dvjf w/YyiQs743S4jOlMcQpXSkNKo9EiBDZS8nBVr1iEf+/HR0d+jtFNCOBrqdId9PYN U5ewmLAWrhNvn311wIQmlZqDxKfgkBGQA2FA8QTnGI=
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 erSWFFNvsx0x; Thu, 12 Mar 2020 14:43:51 +0100 (CET)
Received: from [IPv6:2001:9e0:4:12:70e9:5c77:14c9:5b54] (unknown [IPv6:2001:9e0:4:12:70e9:5c77:14c9:5b54]) (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 2E9B23C; Thu, 12 Mar 2020 14:43:51 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <MW3PR11MB4570257104C28AFC09D00670C1FD0@MW3PR11MB4570.namprd11.prod.outlook.com>
Date: Thu, 12 Mar 2020 14:43:50 +0100
Cc: Andrew Alston <Andrew.Alston@liquidtelecom.com>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E23B8581-16ED-4C1D-8FF6-AE28F599D74A@steffann.nl>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> <265A3B0A-358B-4163-B7E1-2FFE36B3607E@liquidtelecom.com> <14D40038-77D4-43DB-AC36-1199EE547944@cisco.com> <DBBPR03MB5415A2097FD500326B7907FCEEE30@DBBPR03MB5415.eurprd03.prod.outlook.com><C223D73B-D556-427C-82AB-0042C33E32F4@cisco.com> <DBBPR03MB5415ADF9271EE267C3205CCBEEFC0@DBBPR03MB5415.eurprd03.prod.outlook.com><0F51DF13-B058-4850-91E1-AF4B49DE158C@cisco.com> <DBBPR03MB54150C911B32F8F0B2CC7C59EEFC0@DBBPR03MB5415.eurprd03.prod.outlook.com><ED4F23CB-C6EE-454F-89B5-E4C088218046@cisco.com> <DBBPR03MB54159F78083CBCA412243A91EEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com> <MW3PR11MB45701FA2CE7AC6823891A1F1C1FD0@MW3PR11MB4570.namprd11.prod.outlook.com><AF5782C8-DB7C-4C20-BDB5-E9212DCC3244@steffann.nl> <MW3PR11MB457048CF5DA72DF87D1BC0ABC1FD0@MW3PR11MB4570.namprd11.prod.outlook.com><5004D04F-11DB-4F3E-B5F1-2D6309FC449B@steffann.nl> <MW3PR11MB4570257104C28AFC09D00670C1FD0@MW3PR11MB4570.namprd11.prod.outlook.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8kGzQht1j4vOTTVI-HiQ7m2raYs>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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, 12 Mar 2020 13:44:30 -0000

Hi,

> In this context, we are talking about allocations for the provider's infrastructure.

No, we’re not. Allocations are the superblocks that RIRs delegate to an LIR. Before being allowed to use address space an LIR has to make assignments from that allocation. It is that assignment policy that seems incompatible with the way that net-pgm seems to use addresses.
 
> > So what is it that you and Andrew see in the net-pgm draft or the SRv6 proposal that lead you to believe such a change in the IPv6 assignment or allocation sizes are required by RIRs?
>  
> Well, your example mentions that a /40 is used for SRv6 in a very large setup. A regular business entity has a /48 and a regular ISP will have a /29 available.
> [KT] The example of /40 is for a large SP across their network infrastructure – not a single POP.

I understand. At least one RIR has a policy that doesn’t allow for assignments to network-side infrastructure, only assignments per PoP. I’m not saying this shouldn’t be fixed (I think this is an oversight), but this working group should be aware of that.

> I think it is necessary to look at what an expected address space requirements for SRv6 will be for such entities, and whether that fits and leaves enough remaining address space for the rest of the network.
> [KT] Sure and I would expect such discussions to happen at NOGs or in other operational forums including within the IETF.
>  
> What is also necessary is to see if the way SRv6 uses addresses is compatible with the RIR policies. In the RIPE NCC region we havehttps://www.ripe.net/publications/docs/ripe-707#assignment_infra, which basically allows for a separate /48 per PoP and a single /48 for in-house operation of the operator. If changes are required in RIR policies their communities need to be told so, and mutual expectations of what will and will not be considered acceptable address space use will have to be discussed.
> [KT] I believe so and we should get the feedback and inputs of operators that have deployed or deploying it. AFAIK none of them have raised such a concern or any issue with the RIR policies.

That’s nice. I’m just making you and the rest of the working group aware of the incompatibilities that I have noticed. Apparently so far you have been lucky that you haven’t hit the limits of RIR policies yet, or that the operators have violated the RIR policy without realising it. This is why I am informing the WG of this potential issue that might need some work.

> > I am assuming this is the same "IP Space burn" topic that Andrew alludes to …
>  
> Yes
> [KT] Thanks for confirming. So this is then a discussion on how providers want to manage their address space and allocations within it for SRv6. Nothing prevents such a discussion from continuing. I just don’t see how this as being related to the progression of the net-pgm draft towards publication.

The draft introduces an new IPv6 address format, so I think it has to at least give guidelines on the expected use and the expected sizes of LOC (L), FUNCT (F) and ARG (A). Although 3.1 says "F and A may be any value as long as L+F+A <= 128” I noticed that 9.2 says "The range of the registry is 0-65535 (0x0000 - 0xFFFF)”. That places at least a minimum size limit on the length of F that should be reflected in 3.1. What I am missing completely are guidelines on the size of A that can be reasonably expected.

Concretely: 
- Section 3.1 needs guidelines on the expected sizes of F and A, which will give operators guidance on the L they should assign to network programming
- Explicit guidance on the size of L would be greatly appreciated
- The guideline on the size of F should state that at least 16 bits are required (considering section 9.1). Whether the authors want to specify F==16 or F>=16 is up to them.

Cheers,
Sander