IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 24 May 2020 21:51 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 23FD13A0D04; Sun, 24 May 2020 14:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham 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 n5tLHAlieW-L; Sun, 24 May 2020 14:51:01 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 7166D3A0CB1; Sun, 24 May 2020 14:51:01 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id z64so3507161pfb.1; Sun, 24 May 2020 14:51:01 -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=/PSBez+oVJrRfSBoSFmSUBcswKG+lLRP3hveUqMJWx0=; b=q73tCu75ZZrmmvHDVAXmaraLqlEEbSw39tclY901+W5DVuZ/8+QYq6KWuFiGdFcXdp yyPMNNqGa+E2LTHjuXtX4SQYrLSj6xJWiJAWiMhzTsGDEP8E5X2OAH4mJ5A226b+ra95 4Y24LOPRJFWZbHlkPgQ/S5SsMhnJoc1g+hQeMAeLeUOeDWQ32R/d1T7nW49FZ4UfsqF4 t0xnSlxopC0JDuBJn/cmGEnDdovn5iDRN15wJ5vtAJmZ/D1MDeY/mfl6p0LDfi3n74GY D9e8wACm6ksggngkrsSkpTD1h0n26PRXNNi9HSQf1MzL5pw3wXkbLaxk11aTxUf1MmGX dVIA==
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=/PSBez+oVJrRfSBoSFmSUBcswKG+lLRP3hveUqMJWx0=; b=QrU+0nu4MZYqMuQFkmNo4mjcev6WcypGnK80MRQrZRKRnQS1JtE3ifg/4wRb+ElBV1 Tg3SsqVWVH+XGIguC2ItaRt+RIXA57jpsWyG67m8h/YljCaGvuPUGiR/OJQ453UkKuhd F4W3OHVMPjFzV+eB6dVvBr4Rp/JopFu9Acy8LIHPGf8p6cR9rxvdPRiYH0vdqciF3gP4 I1tUTzvtZu1LOMIK/nfGfRKvpnaXaR8p/F4dXDz7UWqpR7GKgPNBJjPEaIgIfSU+sHpf 86YUcDpgoB/tXtc9/rLauu6Ba6cN7ySiFZSC5JZ/I80EIySepEP0Za4jkOOP9ElshuGj YULg==
X-Gm-Message-State: AOAM532AtHZwql7HJgtWHqpqpc8LKNR9sXhNN6par9/G9kXffWXq/NTw JUK3/O6byrvxUD3C0azBaIKGAUTT
X-Google-Smtp-Source: ABdhPJze1PAHR9goGKc1qezrUXsk3iYnpof2GgxeW0ixpA7kclyJ68gT4QJhRdX+9LTaFFeYI5hntA==
X-Received: by 2002:a62:7bc8:: with SMTP id w191mr14622711pfc.30.1590357060656; Sun, 24 May 2020 14:51:00 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id o16sm3018155pgg.57.2020.05.24.14.50.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2020 14:51:00 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@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> <CALx6S36yJ5CS6ykQhd_sW3T6=PjVJNOqewtg2joUtHnbsZPxSA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <15815a80-7fe3-7d85-61a8-f7168a99cabb@gmail.com>
Date: Mon, 25 May 2020 09:50:54 +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: <CALx6S36yJ5CS6ykQhd_sW3T6=PjVJNOqewtg2joUtHnbsZPxSA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CaBnmmopUK7_3rA_S_SZ_0r6Az4>
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 21:51:05 -0000

On 25-May-20 09:08, Tom Herbert wrote:
> On Sun, May 24, 2020 at 3:23 AM Robert Raszuk <robert@raszuk.net> 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.
>>
> Robert,
> 
> Look at Destination Options before the routing header in RFC8200.
> These are intended to be processed at every intermediate destination
> in the routing header 

That intention is not specified in the text, and IMHO cannot be deduced from the text. Hence my comment on draft-bonica-6man-ext-hdr-update.

   Brian

> and precede any fragment header.
> 
> Tom
> 
>> Keep in mind that in number of networks P routers are also PE routers so executing DOH even if CRH still contains many hops to go may result in very unexpected behaviours. I am sure you recall that L3VPN labels are locally significant and there is no mechanism in place to assure uniqueness of VPN demux values across PEs..
>>
>> Why is this important here - because CRH by design is decoupled from any functions or network application handling.
>>
>> Many thx,
>> Robert.
>>
>>
>> On Sun, May 24, 2020 at 3:24 AM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
>>>
>>> Cheng,
>>>
>>>
>>>
>>> The CRH is a building block. It has exactly one function. That is, to steer a packet along its delivery path.
>>>
>>>
>>>
>>> The CRH does not attempt to deliver parameters or metadata to service function instances. It relies on other mechanisms. One possibility is a destination options header that precedes the CRH. I am sure that there are other mechanisms. CRH should be compatible with all of them.
>>>
>>>
>>>
>>> Personally, I am not an NSH expert. Maybe someone who is can speak up.
>>>
>>>
>>>
>>>                                                                                               Ron
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email