Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1131344pxa; Wed, 5 Aug 2020 23:45:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRIdxW4PcwU5YNCLprVpr/K4CnDNjdzWGJT3h/W9xWl4/IIUbwExyi44WGGNkFx1fkQSdz X-Received: by 2002:a50:fb94:: with SMTP id e20mr2685452edq.103.1596696332317; Wed, 05 Aug 2020 23:45:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596696332; cv=none; d=google.com; s=arc-20160816; b=iLiWUpxyLG9qm5ok6LtVC9HSyavuuOYBPxGO5HHDR7nV7pNBl/iyIg9p3DrXSffdGJ +bpTavHZ/v1kfJ6YH2kb9Fh4A+OwvNwje5JLpYdKFOPgX+B3TfNwAWvHBMMEPETmjNUJ wFOFvdQChz9pgy51iUwQEkPHJJsMeOAZikRZq1pfqtGuuWZmqdnR2wJeW0id5RyqPL4G X+51qzfw5IfFqWibM9zCFL+ituGVvzVFrNvt7MC/omL7Yvpyv79Q9Gn1NK5viKKAu4h3 51788K9h0qG92aSPaHZodbNLozfwlUEGho/xhCoByY3Qs1IS6bngJAQ5SMkjnuIcxgYF Gi/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=46ceznf8owg3s+9NXjpM+2fx/1Tzs0h2vk3bq2eXF5Y=; b=jMuKM0zqFhPTK50LkuHlZsnpgbQwJxCpqHAjINXdzFYFzHYbPUDvd2gcLn2wh+W2I8 hdu3hzfkvFu9ZfRsoPXK+ckCKKdjIhmhk3kO1BhcfXqwtnOVWMe/eGTaGLFiUWrVJUrB YQLWNoBo6MQBo0LwBoNBRslCQUDJleM4QFbjSmLN4vdNctzd6bmKOVcCxr6/npAPpeVf +i+qQl+vw0nQx4pbM8AiI0vgmt35VrXSPxt+Ll4gLnjOI2/QeuCMNQ78TnITwfqnDaaq Dt+iCkcbNZrCyEQ4oaq8aEhZXMa79uJ3hGMLFoUB9qH6iy0yqwayX7I2k+djdvQpSykh FDIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NBq6G2Ht; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx19si2605087ejb.691.2020.08.05.23.45.10; Wed, 05 Aug 2020 23:45:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NBq6G2Ht; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728320AbgHFGnO (ORCPT + 99 others); Thu, 6 Aug 2020 02:43:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728050AbgHFGnM (ORCPT ); Thu, 6 Aug 2020 02:43:12 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30736C061574; Wed, 5 Aug 2020 23:43:11 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id z18so39292106wrm.12; Wed, 05 Aug 2020 23:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=46ceznf8owg3s+9NXjpM+2fx/1Tzs0h2vk3bq2eXF5Y=; b=NBq6G2HtRLOhigjZvBcapT0e6ZDZndnZ9JxRXY2wmvxGRm08XiFcmmLI+1EaM6lUWu d5bPfa7bWn+r4wFAl8QCpqE9DcQ/hLvDKwy+PVZM8aTfLL2me3VzjuirayqTMthN+jNV e0T5MpMnkbhmOBXXZsrurSg0Acbubp00avvhOa+GGxIpyP9UKdRduTPyvwvF+dziGhM6 x3+hMMQ1iao3AZ6ho+HaVCtxwMirT98P9EvzKvEzn4sv8gYILdNK7YyBe4tqTBedSVjw pUzbjYGiwY/beqgBlwE7yJ7QQrc7R46kf4tZN71ya4rzUtF5HJ0NOUqmJwwfpMrJg/f6 C3Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=46ceznf8owg3s+9NXjpM+2fx/1Tzs0h2vk3bq2eXF5Y=; b=K6+jCTfc4NH6tyaN27rsIhSMwpA0bk3V4fvYJHksL45KiGe7eSBQtsZKYuHylchQx8 R8pAWx22ufRBnwvCdiY+4fsYUoRZVtyYXhr/P7lT3PohxaBAlIyRt393Lky0EpNA9XTR vdEaTsp9pZWEY3YS7g8Vl1y8je4xYlhtTj9vrM8hA5RitugKdvns1Xcs/VLKh5EIbheS s3UMlKR9dqNMuxEuFCXsi/YN8mfBmR/lAYTIkKe3KfE+R1w4kIy5aZIw4UU5Wz7pQ3HD xdxTT5UQLmuwlT93DKQdyWBwfecEQ8QOpgP4TMBV37APYKlvpNPfQo1kByfCNl7HYv8C 57qg== X-Gm-Message-State: AOAM530dHhfLDkHpSE51mlNTmDt3kz3yCtGv0bhwn6X3WdEvGYb5AK2o N5q+fTzYXY54SvT1/1/4sc4= X-Received: by 2002:a5d:4603:: with SMTP id t3mr6382527wrq.175.1596696189840; Wed, 05 Aug 2020 23:43:09 -0700 (PDT) Received: from [10.55.3.148] ([173.38.220.41]) by smtp.gmail.com with ESMTPSA id p15sm5237192wrj.61.2020.08.05.23.43.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 23:43:09 -0700 (PDT) Subject: Re: [PATCH] seg6: using DSCP of inner IPv4 packets To: David Miller Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, andrea.mayer@uniroma2.it References: <20200804074030.1147-1-ahabdels@gmail.com> <20200805.174049.1470539179902962793.davem@davemloft.net> From: Ahmed Abdelsalam Message-ID: <7f8b1def-0a65-d2a4-577e-5f928cee0617@gmail.com> Date: Thu, 6 Aug 2020 08:43:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200805.174049.1470539179902962793.davem@davemloft.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, SRv6 as defined in [1][2] does not mandate that the hop_limit of the outer IPv6 header has to be copied from the inner packet. The only thing that is mandatory is that the hop_limit of the inner packet has to be decremented [3]. This complies with the specification defined in the Generic Packet Tunneling in IPv6 [4]. This part is actually missing in the kernel. For the hop_limit of the outer IPv6 header, the other SRv6 implementations [5][6] by default uses the default ipv6 hop_limit. But they allow also to use a configurable hop_limit for the outer header. In conclusion the hop limit behavior in this patch is intentional and in my opnion correct. If you agree I can send two patches to: - decrement hop_limit of inner packet - allow a configurable hop limit of outer IPv6 header [1] https://tools.ietf.org/html/rfc8754 [2] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16 [3] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-5 [4] https://tools.ietf.org/html/rfc2473#section-3.1 [5]https://github.com/FDio/vpp/blob/8bf80a3ddae7733925a757cb1710e25776eea01c/src/vnet/srv6/sr_policy_rewrite.c#L110 [6] https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-6/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-66x/b-segment-routing-cg-asr9000-66x_chapter_011.html#id_94209 On 06/08/2020 02:40, David Miller wrote: > From: Ahmed Abdelsalam > Date: Tue, 4 Aug 2020 07:40:30 +0000 > >> This patch allows copying the DSCP from inner IPv4 header to the >> outer IPv6 header, when doing SRv6 Encapsulation. >> >> This allows forwarding packet across the SRv6 fabric based on their >> original traffic class. >> >> Signed-off-by: Ahmed Abdelsalam > > You have changed the hop limit behavior here and that neither seems > intentional nor correct. > > When encapsulating ipv6 inside of ipv6 the inner hop limit should be > inherited. You should only use the DST hop limit when encapsulating > ipv4. > > And that's what the existing code did. >