Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 11 December 2019 01:10 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 B234012008C; Tue, 10 Dec 2019 17:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 nNDaczzxxxxf; Tue, 10 Dec 2019 17:10:56 -0800 (PST)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 6FA3A120059; Tue, 10 Dec 2019 17:10:56 -0800 (PST)
Received: by mail-pf1-x443.google.com with SMTP id d199so879889pfd.11; Tue, 10 Dec 2019 17:10:56 -0800 (PST)
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=3gWkON3gxH+9yMMejayB+NUq1uEMRVohp4L8X70p5BQ=; b=V8UI8KyCHXCLFrorij3JeF/8ImThV/R2fFnYpRudDijxSzOo2BEbfN+p9Zebl4Kcpe 5LhWKaO0WizhGZ9EiKMomFxxcpWrJGobNGFz9ou5XsWQh/V7g/n/1xd/AU/91mH5EUad gpQxmyDlFHELxk6aZggpLSmLsCFxPkCEjH9DQ0d100gPvqPlw1memkOAgGqthk+UMoiW ydVyaw6RB8HovWIFgHLlbSXr2exCWgupmfmz+w5U62gXsdkifM4RwoGEEeoWZFWxBkgf QHqO+ZPwiTI1tUv1fyxBjVCfHbRrM8e5ku5NHQO6Q/7oO8W6Uweq5nXeKhKj4rs9zdBc 3Mpw==
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=3gWkON3gxH+9yMMejayB+NUq1uEMRVohp4L8X70p5BQ=; b=W9CWiPJUJGdmxqzrqs1G6ILv7A6AP7xxctnfL5sRHADqYpMQzsomb2VGcv6Q1a7LGZ mAaYXaj5ClRTDfpgtPyNYp3FhS6V3mZogioGNj4VDijvlcGDpY4mFjhePhHyKc07K5pl FpzZhnmKWr2RwZjSnflzHCXLdcGGrefq/6abeBceyMpcODJf7+5SAc3Lff5ZIKTccmU5 Jg6i9F/mOb0PzhIYVeaE+WbjUKt7Fq9tHKiHRfJXrFMNvOzzGykNQXOVkS4xPqQvuoo+ JFTwEUtlNSavGGfnPAEYDYZCyBLxkFQw2tMhDkKX+lzvB6lQ0eM4SpyFUZWhq4DLIRoI S4hA==
X-Gm-Message-State: APjAAAUqrpw+Lf6ecZGN757zfBQwkEc544WIByh60YCV63hVEV+F4MiJ QKn+nfuUIlTIyikJR57XFcN5VOxM
X-Google-Smtp-Source: APXvYqyMOIEPkAm7/djFrkwv039Ekw4/XDB/CUkd+ryIrJAlMRweSt/xfE4YKbW+2s2uSloR91JfqQ==
X-Received: by 2002:a62:7986:: with SMTP id u128mr943595pfc.192.1576026655617; Tue, 10 Dec 2019 17:10:55 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id y17sm261040pfn.86.2019.12.10.17.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 17:10:55 -0800 (PST)
To: Robert Raszuk <robert@raszuk.net>, Erik Kline <ek.ietf@gmail.com>
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, Fernando Gont <fernando@gont.com.ar>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <129bbb32-0f14-b799-430c-8f76fb6b1279@gont.com.ar> <1824_1575998223_5DEFD30F_1824_112_1_53C29892C857584299CBF5D05346208A48D24EBD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4384c08a-65f5-dbfb-85c7-8365feba9662@gmail.com> <CAOj+MME1+JXth8m4U_E5R6VLvurVR_y_DQvOBy7JmGxHZp7T=Q@mail.gmail.com> <CAMGpriV8BFjOed_-QJYEZc_BANvEuc1hRgYjSdaVUYygVzPj+Q@mail.gmail.com> <CAOj+MMHCA+=9zv_UJAF3gC6R1TWKb6LQJxaGsrRa0N7Amdxrww@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f86050ed-dc45-7b2f-3098-94173efdf949@gmail.com>
Date: Wed, 11 Dec 2019 14:10:49 +1300
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+MMHCA+=9zv_UJAF3gC6R1TWKb6LQJxaGsrRa0N7Amdxrww@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/ViEEQL8P1Ix0PRvX2LsCKY3CF0g>
Subject: Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)
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, 11 Dec 2019 01:10:58 -0000

Robert,

On 11-Dec-19 09:18, Robert Raszuk wrote:
> Hi Erik,
> 
> What you are proposing IMHO is not needed. 
> 
> Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so is already doing an insertion of new SRH 

That isn't "insertion" in the sense of draft-voyer. It's prepending an extra layer of encapsulation, which is indeed just fine and I don't think anyone here is objecting to it. The spring draft currently uses (IMHO) imprecise language, even in its pseudo-code, but if all it's doing is describing successive layers of encapsulation that's fine too. Wasted bytes perhaps, but that isn't an IETF problem.

Whether prepending new headers, each with their own SRH, is the best way of doing service-based traffic engineering is another question. Having just reviewed draft-ietf-bess-nsh-bgp-control-plane for Gen-ART, I do believe there's more than one possible approach.

Regards
   Brian

> while maintaining src address and previous  SRH content (modulo updating it). That is legally permitted operation based on IPv6 tunneling RFC. 
> 
> The word insertion has been questioned in the context of adding SRH at non SR midpoints (say for TI-LFA) into existing "private" IPv6 header. For this sure one could think of more structure (bypass section) of original SRH already present or addition of 2nd SRH. 
> 
> Thx
> R.
> 
> 
> 
> 
> 
> 
> On Tue, Dec 10, 2019 at 9:10 PM Erik Kline <ek.ietf@gmail.com <mailto:ek.ietf@gmail.com>> wrote:
> 
>     My apologies for raising something that might have already been discussed a rejected, but I'm finding it non-trivial to track this wide-ranging discussion across multiple mailing lists.
> 
>     Regardless of how SRv6 works now (using header insertion, as Darren said in Singapore), I'm wondering if it would suffice to say that the ingress encapsulation node could/should pad the SRH with an operationally determined amount of extra space to allow for header re-writing.
> 
>     This would effectively turn the SRH into a scratch space could be specified as able to be re-written by SR-aware nodes along the path.
> 
>     For example, if the ingress router new the SR domain's carefully curated path MTU, it could pad out the SRH to some fraction of that, a la:
> 
>         {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_2, sr_rtr_1, ::0, ::0, ::0]}
> 
>     then permit intermediate SR routers to rewrite all of that scratch space for router insertion/deletion as needed.  For example, if sr_rtr_1 needs to route around sr_rtr_2 via sr_rtr_4 and sr_rtr_5 it could rewrite this as:
> 
>         {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_5, sr_rtr_4, sr_rtr_1, ::0, ::0]}
> 
>     If there's no scratch space left with which to fiddle then generate an ICMP error to the ingress router (ICMP source address selection aside).  The rules for examining this header scratch space in the returned ICMP error might need to be suitably lax.
> 
>     I'm unsure of how this would interact with the HMAC bits, but overall, if this could work then perhaps we don't need to worry about insertion anymore.
> 
>     Yes, there's more overhead on each packet, but that should be tunable by the operator based on things like (1) operational path mtu in the SR domain, (2) operationally acceptable padding overhead, (3) expected space required for adding routers for re-routing or whatever...
> 
>     On Tue, Dec 10, 2019 at 11:45 AM Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
> 
>         Brian,
> 
>             > Situation has changed since this email: the network programming draft has now removed text related to SRH insertion.
>             > Please comment on the text if you see text related to SRH insertion.
> 
>             For example:
>             https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
> 
>             Why would draft-voyer-6man-extension-header-insertion exists if the SRH proponents do not intend to perform SRH insertion?
> 
> 
> 
>         What Bruno is describing is the new situation after removal of SRH insertion at non SR midpoints from NP draft under last call... 
> 
>         Section 8.2 is referring to SRH insertion at the SR encapsulation node (for example ingress to the domain). 
> 
>         draft-voyer-6man-extension-header-insertion  is progressing as recommended to relax the RFC8200 restricting EH insertion at any arbitrary node - not necessarily segment endpoint. 
> 
>         Regards,
>         R.
> 
> 
> 
> 
> 
> 
>          
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         ipv6@ietf.org <mailto:ipv6@ietf.org>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
> 
>     _______________________________________________
>     spring mailing list
>     spring@ietf.org <mailto:spring@ietf.org>
>     https://www.ietf.org/mailman/listinfo/spring
>