IETF Logo Mail Archive

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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 12 December 2019 18:54 UTC

Return-Path: <hayabusagsm@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 1F06A120024; Thu, 12 Dec 2019 10:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bQXJJO7ykhOn; Thu, 12 Dec 2019 10:54:50 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 8D8921200C3; Thu, 12 Dec 2019 10:54:50 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id v18so3947705iol.2; Thu, 12 Dec 2019 10:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LZ7uYoJUSooq+Lbtb+UXE3wLlKhD9tzZyPee0hoYS90=; b=qwax9kMIRfh40Oow+Ajq42+IJSuKOfL+zaSQh5n4EwJOo6m5jJQFZ73wGXnRL8v6vR 0X+O+VBRg7IGf8YFSGkbMWfaM3L7Yo6UBqfN18VvTqF+zSojB7clTzMpwY+j3fVpFOwq bobFAcouUSuGGkB5surGMtNgfKGFbExLC2HrN2VSb6fOekD8gXPcP4C9CM9iRn45tsS/ VUQP1VsJh6VF0nwQE9SbCBMTbZUD04VcH6Ad/QMQ2TIdHSnEQKZdiqLcETvHM+X4XMin uMUMkayCu/oBQH7XFvz6OSwbWvQTQRF+5J9ynHS2PRKBiutd+wBXERhSDygfC4+UYEI6 TdHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LZ7uYoJUSooq+Lbtb+UXE3wLlKhD9tzZyPee0hoYS90=; b=Mzktqq3dyGAkj+LzQy2J+mcZBS2DTfK79NWm0LsyGzUjwtg5DF80Jg+IWHtz00zBxc 9KKZMR8+DV6dGTSvsKP8y4zwQn95dlBEtxtSIWnT7/m689P66vyG6CIabMrKscAjz1rj AyPyrKoYb7fb1V9te4c7alQYiPOutZV0USCIpwolSTM6U8DAosb7WQiOZ/4GkSN2y1q8 0EpupRtVtyOf/ZlYGv2kfKT49pZyFfa6w9IttweJUn1rrpukZZAIa5vsX5899x4ajxuB Nd6UwoZUQZv8JO2b9bO7ulbYgqarbRapaVFrhbr3Z4CHtNZ8c7nW8K09nSd3SP56Gnu+ yO9g==
X-Gm-Message-State: APjAAAXYdI/8Hq5x7a95kSslPNT7p4r09xM3jIiqYyI+YEt0Zby6IMeM 6aCSxCxtlwZCGN8bse0zgoIqxUVV01KAt+DLcndgvdzRvIE=
X-Google-Smtp-Source: APXvYqyk+TuuHO6h664h8dyeA8Rpwm4ruK8z9TIikbmD9qQaJQDspkzZOdalESfDZVSU8F7tJciGhWxq761T5t3pGsY=
X-Received: by 2002:a05:6638:76c:: with SMTP id y12mr9414690jad.95.1576176889724; Thu, 12 Dec 2019 10:54:49 -0800 (PST)
MIME-Version: 1.0
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> <f86050ed-dc45-7b2f-3098-94173efdf949@gmail.com> <CAOj+MMHCJPPiA-znmkvi3VfES181_VWMsK+3ecESnO1bFo5iXg@mail.gmail.com>
In-Reply-To: <CAOj+MMHCJPPiA-znmkvi3VfES181_VWMsK+3ecESnO1bFo5iXg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 12 Dec 2019 13:54:39 -0500
Message-ID: <CABNhwV18K-_J4CwAGrDVd-Qd-vAH5jgKn-Tqp1fG1io-D8q0rg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "6man@ietf.org" <6man@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fernando@gont.com.ar>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d87ce0599864774"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CK9vi7v0SMRWcVjXx_OkNOdbECw>
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: Thu, 12 Dec 2019 18:54:53 -0000

On Wed, Dec 11, 2019 at 3:37 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Brian,
>
> > 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.
>
>
> Correct. But we are not discussing draft-voyer here.
>
> I think recent mail threads prove that it is much better to discuss one
> topic at a time rather then mix three different and pretty orthogonal
> "issues" interchangeably.
>
>
>>  . 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.
>
>
> Great that we agree.
>
>
>> 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.
>>
>
> 100% agreed. In fact as you may have seen I have another non data plane,
> but control plane proposal posted:
> https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00
>
> Kind regards,
> R.
>

  Robert

    Your ip-te teas WG draft sounds like a fine solution and maybe can be
used in conjunction with Gen-ART sfc draft in centralized SDN controller
based architecture.  So with draft is pulls the control plane function or
Ti-LFA and SR-TE and/or binding SID policies into control plane nodes which
could be the PEs eliminating SRH state in the P core.  So this in essence
using this feature we would save on overhead bytes with the additional 6in6
encap plus SRH state.

Warm regards,

Gyan

>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant

v2.23.0 | Report a Bug | By Email