Re: [spring] How CRH support SFC/Segment Endpoint option?

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 24 May 2020 20:54 UTC

Return-Path: <brian.e.carpenter@gmail.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 DBCA43A0C11; Sun, 24 May 2020 13:54:44 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 U2lNSmXmpaCs; Sun, 24 May 2020 13:54:43 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 D69E03A0EBF; Sun, 24 May 2020 13:54:12 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id x18so5626108pll.6; Sun, 24 May 2020 13:54:12 -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=LlZEWSPMqZnHuPrMLZeggDAyWYeP40LWGTAX1E3hMmk=; b=B1Q5dDy6vRn+JCVEmCF75KqLic9gAiec6LzLPOf7PGNHMOkfb03AaxLxzPlgEgsRcL Wy7tQ1VStDwAiGa1op72SAcygJOQc7QaB0sibYZcFySkeIEwN8piprN4j2aDK1RzuGPT tjmJd0/hMAHt5WhvLWMC21KbZygZmgd+IJZNDz704NiRlKG8hIQtbE64DuvLmHwoXdJo vlftb1z1VFMHlCSA6/uOKVZnclg7b2aKpvrrDlTFOGPLizcfYS3hiDB3N8TZZoe61gbs LoJ9eotUZYtHfeoQ5OU3+AmiqzKcErKWOA2lXDdPczgFxWntrJNCq4gpuiOxOMu9C3Mt fYKg==
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=LlZEWSPMqZnHuPrMLZeggDAyWYeP40LWGTAX1E3hMmk=; b=kQ4Pqf29KXVCMRYtWTMalS3pnRJv0JslTbwmPs6F1kdFDp5dLRgRNs1ZpchwPw9i9t MLmLOlhGYIszh5SOPhHPrveP9v0McV1SnDzg2lBldphSgLKbVO8sXxaMyrzcpdZyMejs teOF1jjpMY2Tdl5Wi4pOuIvmb/k7c4FtBDWl2c6yqMmysdXi6wP8aXY3gtvRsJoZpPtC nDRXu/4dd8XMrkRZtHWljKkub3yIpEpfyxSsM5081LCfphn8s2WDMn7YY1GEA1qIRwIx TwYWZLMD8RkoOQn1nScUI0EnkIxya74TQ+V3SqcpKB9PHVMNBCnqC+JMjHjZ2V1c2P/k eBKQ==
X-Gm-Message-State: AOAM5334e3d0Qb0EOVKsk25lozdmH0wZb7myL1qjOWu1PN0DV/AY5a0B EXtVnkJ7AReW4gJAiVS2umGJhnTd
X-Google-Smtp-Source: ABdhPJxCaTOKKBJUWIZqF5JQ6oJYa69Ke6pvrbtdiapSkWj+tM2oeeTH0AR5OqDSvvYLd7unZTvacQ==
X-Received: by 2002:a17:902:c489:: with SMTP id n9mr24393954plx.186.1590353652044; Sun, 24 May 2020 13:54:12 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id n38sm1370121pgm.1.2020.05.24.13.54.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2020 13:54:11 -0700 (PDT)
To: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 6man <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
References: <C7C2E1C43D652C4E9E49FE7517C236CB02A2CD12@dggeml529-mbx.china.huawei.com> <DM6PR05MB63482CFA4D5AB938D5A4B818AEB40@DM6PR05MB6348.namprd05.prod.outlook.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A37DC6@dggeml509-mbs.china.huawei.com> <DM6PR05MB63489256A7C8357BEF526EE2AEB20@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMGLj9OgFCcsB21oWXbcCqHZ7B4qTvCcrK9LXuKDYVu_vQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <811e0a83-6dee-5d08-2293-832d0eb6708a@gmail.com>
Date: Mon, 25 May 2020 08:54:05 +1200
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: <CAOj+MMGLj9OgFCcsB21oWXbcCqHZ7B4qTvCcrK9LXuKDYVu_vQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/e8YVQfvbxffRX-ZJSSH2bXeIGCQ>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
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: Sun, 24 May 2020 20:54:45 -0000

Hi Robert,

On 24-May-20 22:22, Robert Raszuk wrote:
> Hi Ron,
> 
> I have one small question on the Destination Option Header you keep referencing to carry for example VPN demux instructions. 
> 
> As DOH follows Fragment Header it is indeed inspected before CRH. 
> 
> So please kindly clarify what is there in the IPv6 packet header which would stop each segment endpoint (during the transit over SR anchors)  which destination is obviously in DA of the arriving packet not to inspect DOH and not trying to execute it ? 
> 
> If you could please also provide reference to RFC8200 defining it. 

I think you are playing with words a bit here. 8200 says:
"The Destination Options header is used to carry optional information
that need be examined only by a packet's destination node(s)."

That clearly means that other nodes *do not need* to examine the DOH, so they can simply skip over it. Because it isn't encrypted, of course they physically can examine it if they want to waste CPU cycles, but they *do not need* to do so. Since they are not the destination node, obviously the information in the DOH is not intended for them. If it isn't obvious that they are not intended to act on that information, I don't know why we bother to write RFCs at all.

Regards
    Brian