Re: IPv6 header insertion in a controlled domain
Gyan Mishra <hayabusagsm@gmail.com> Mon, 09 December 2019 22:22 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0C2120113 for <ipv6@ietfa.amsl.com>; Mon, 9 Dec 2019 14:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 g71E5CcCIiu6 for <ipv6@ietfa.amsl.com>; Mon, 9 Dec 2019 14:22:33 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 C7931120086 for <ipv6@ietf.org>; Mon, 9 Dec 2019 14:22:33 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id t26so5176295ioi.13 for <ipv6@ietf.org>; Mon, 09 Dec 2019 14:22:33 -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=yBOPSrEqQQ5ZsXYuxIeb08yJwKRB/7JOzZps8xvIOYc=; b=oEmCfsZQST7KebhWtD2ZIGy+scNw5yrrUbSDsA1PMrPF40FMXyptjKa8JGj+5f00Je IJuRQmJyCHHAn+DZIdMiCIDMwoClDpvX4uAAzGP3rQ/gJ0t+PlX5wXlpCwZFY96IJ9p+ LotFOFRHmUV6dI6fL5LLdqqnOtbAZTJvU05MerkHcn6WQAPiEsKFRtB95VnniYjKfYy1 fK4gba+CdCJblURU4Ziba2vtYfviM1J4PqgcNvrr4Dp9uxKsm5gU7A+HHQHxdOt/ELzj DwdsaeWDkHKsbJToYw7uXQtiMruAXc1k6d+3shNgm2j2U3Smdc5otMSjL3ANrHkjGi81 bkkw==
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=yBOPSrEqQQ5ZsXYuxIeb08yJwKRB/7JOzZps8xvIOYc=; b=FeROdmgEyVD4eZMPD+wH417tKvEGC4KqCGbI9OfDRyvz0mARhxgdIDGuDnC+OZ7b4p GtwRFRIogksM4N2ewP8/oOVe58A05OJ93FC5l8zCZYIkYgr5nJfo8ncpWMricoq4HnqG d1ur+Q6C2ZzbZHzGs5wpJqx17bPPVS+/dCo/DW3/w1T96vJCJOXneYVYnPAwxFa6zYH7 tkwnUBnpuWc3ERr3IFvBDUcy7WIGsm9RRf43LU72atfiVxD+fS9bPiEXY6vYATMiLloe 5xjoA/uvGca1D8SkM52DsmHTh7mHRst3O44kV4jA89s1i+s8G/FkWEujtB8K9tNVgFVB COWA==
X-Gm-Message-State: APjAAAX9XKHal0tXp7J99/hGbWTAzqoqGZYYzALb4QamzgRxEuJwABuA 5RzU8QD1gG1p85rZxPCXioH3tOoehs5dExrw0ZYxTU6s
X-Google-Smtp-Source: APXvYqz1FyokINybS2xSTaGnCqFcaHU/I4VDDCK7uBB27QE4WA/Cb63nGkWVSLWOQg7quXN0U+XGVSgoJCADZQcDk4U=
X-Received: by 2002:a6b:7316:: with SMTP id e22mr23256932ioh.205.1575930152871; Mon, 09 Dec 2019 14:22:32 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org> <CALx6S34tpSKa1AhOB0Wr3v_NLxaNeO1aOdvb2FAULErfxn=Jpw@mail.gmail.com> <3D6F543F-FFDE-4959-B4FF-5F09B77D79AF@employees.org> <42762b44-6c81-986c-b1ec-2478da1ef06f@si6networks.com>
In-Reply-To: <42762b44-6c81-986c-b1ec-2478da1ef06f@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 09 Dec 2019 17:22:21 -0500
Message-ID: <CABNhwV0BAgAi60dq36MiauUv43+-r23AU-D=zV4jygo3gU=Cqg@mail.gmail.com>
Subject: Re: IPv6 header insertion in a controlled domain
To: Fernando Gont <fgont@si6networks.com>
Cc: 6man WG <ipv6@ietf.org>, Tom Herbert <tom@herbertland.com>, otroan@employees.org
Content-Type: multipart/alternative; boundary="000000000000f3ea3805994cd4d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/U0Cb-OTBenc_RNg7gkv4puOealI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2019 22:22:36 -0000
I would like to make a point which I tried to do earlier on this thread that with SRv6 any flow entering the domain from an external CE device is “encapsulated” upon entering the domain as an overlay BGP service instance and then in the underlay is hop by hop routed based on explicit segment list from SRH header inserted on the ingress PE node of the SR domain. What I am trying to say is that we had asked Spring to do encapsulation since in flight eh insertion violated 8200 IP6 spec. It appears the fact is that encapsulation is part of the SRv6 spec for flow entering the SR domain from a customer CE external device. So now if we have Spring do another encapsulation it would be a double encapsulation. In another thread with Adrian I have asked a detailed questions related to the the TI-LFA 2nd EH header which I believe TI-LFA behavior is similar to MPLS ldp remote LFA when with MPLS a label is added at the PLR junction point. So with TI-LFA I believe an encapsulation has to happen for that to work and must already be in the specification. I am still researching to find the spec where that is stated. So in a nutshell it is very possible we maybe good to go and SRv6 is abiding by the IPv6 rules with eh insertion. See draft below. https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3> I had posted a draft from BESS WG that mentions the encapsulation as part of the SRv6 spec. So it does appear that SRv6 is following adherence to IPV6 specification. 3 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3>. SR Nodes There are different types of nodes that may be involved in segment routing networks: source SR nodes originate packets with a segment in the destination address of the IPv6 header, transit nodes that forward packets destined to a remote segment, and SR segment endpoint nodes that process a local segment in the destination address of an IPv6 header. 3.1 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.1>. Source SR Node A Source SR Node is any node that originates an IPv6 packet with a segment (i.e. SRv6 SID) in the destination address of the IPv6 header. The packet leaving the source SR Node may or may not contain an SRH. This includes either: A host originating an IPv6 packet. An SR domain ingress router encapsulating a received packet in an outer IPv6 header, followed by an optional SRH. The mechanism through which a segment in the destination address of the IPv6 header and the Segment List in the SRH, is derived is outside the scope of this document. 3.2 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.2>. Transit Node A transit node is any node forwarding an IPv6 packet where the destination address of that packet is not locally configured as a segment nor a local interface. A transit node is not required to be capable of processing a segment nor SRH. 3.3 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3.3>. SR Segment Endpoint Node A SR segment endpoint node is any node receiving an IPv6 packet where the destination address of that packet is locally configured as a segment or local interface. On Mon, Dec 9, 2019 at 4:45 PM Fernando Gont <fgont@si6networks.com> wrote: > On 8/12/19 14:19, otroan@employees.org wrote: > > Tom, > > > >> IMO, even before we ask the of how to make header insertion work, we > >> need to ask and get answers to the question why it's needed. That's > >> why I created the thread on necessity (please comment on it). Until > >> there is a clear justification for this mechanism, I personally don't > >> see why the WGshould spend time trying to "make it work". > > > > I started this thread to see if there was agreement that the mechanism > _could_ be made to work in the most simple topology. > > I don't think "why" is required to have that discussion. > > Well, you are going against the way I've seen IETF wg operate -- > including 6man. > > Every time I've seen anybody propose something, there was something to > be achieved, and there was an argument why a particular solution had > been selected and was being evaluated. > > But, if we are at it: I want one solution that stuffed three SRHs, and > two DOHs. Will we evaluate that one, too? -- If you wonder why such > strange thing: I won't answer why, either. > > Any proposal for EH insertion should explain why they need it, and why > the most obvious, and compliant, encapsulation doesn't work for solving > the problem. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > 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
- Network Programming - Penultimate Segment Popping Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… otroan
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: Network Programming - Penultimate Segment Pop… otroan
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- We don't seem to be following our processes (Re: … Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Tom Herbert
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Enno Rey
- Re: We don't seem to be following our processes (… Enno Rey
- RE: We don't seem to be following our processes (… Ron Bonica
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Sander Steffann
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Bob Hinden
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- RE: [spring] We don't seem to be following our pr… Ron Bonica
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- RE: Network Programming - Penultimate Segment Pop… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: We don't seem to be following our processes (… Ole Troan
- Re: We don't seem to be following our processes (… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: We don't seem to be following our processes (… Fernando Gont
- Separating issues (was Re: [spring] We don't seem… Suresh Krishnan
- RE: Separating issues (was Re: [spring] We don't … Ketan Talaulikar (ketant)
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… Joel M. Halpern
- Re: We don't seem to be following our processes (… Mark Smith
- Re: We don't seem to be following our processes (… otroan
- Re: We don't seem to be following our processes (… otroan
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: Network Programming - Penultimate Segment Pop… Darren Dukes (ddukes)
- Re: We don't seem to be following our processes (… Fernando Gont
- Re: Network Programming - Penultimate Segment Pop… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: We don't seem to be following our processes (… Tom Herbert
- Re: Network Programming - Penultimate Segment Pop… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: We don't seem to be following our processes (… Mark Smith
- IPv6 header insertion in a controlled domain otroan
- IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Joel M. Halpern
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain jmh.direct@joelhalpern.com
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain otroan
- Re: We don't seem to be following our processes (… Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Brian E Carpenter
- Re: IPv6 header insertion in a controlled domain Warren Kumari
- Re: IPv6 header insertion in a controlled domain otroan
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: We don't seem to be following our processes (… Ron Bonica
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Sander Steffann
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain otroan
- RE: [spring] We don't seem to be following our pr… bruno.decraene
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: IPv6 header insertion in a controlled domain Tom Herbert
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- RE: IPv6 header insertion in a controlled domain Ron Bonica
- Re: IPv6 header insertion in a controlled domain Gyan Mishra
- Re: IPv6 header insertion in a controlled domain Fernando Gont
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Gyan Mishra
- Re: topics to circulate Erik Kline
- Re: topics to circulate Alexandre Petrescu
- Re: topics to circulate Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu
- Re: IPv6 header insertion in a controlled domain Alexandre Petrescu