Re: IPv6 header insertion in a controlled domain

Gyan Mishra <hayabusagsm@gmail.com> Tue, 10 December 2019 00:28 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 8AE6E12021C for <ipv6@ietfa.amsl.com>; Mon, 9 Dec 2019 16:28:42 -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 3KtIhCQbhqMm for <ipv6@ietfa.amsl.com>; Mon, 9 Dec 2019 16:28:40 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E3D21120020 for <ipv6@ietf.org>; Mon, 9 Dec 2019 16:28:39 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id u7so16895491iop.5 for <ipv6@ietf.org>; Mon, 09 Dec 2019 16:28:39 -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=Qa1+BBjny8/QmmpWAt/gaQ7i/C943yfwZqU2wj5pWQ0=; b=i72TUMBLLaLQPlGobRu6j0g2vmbLUnre5vG37FB1tP62QVe52w9FBHCu6zllijt+iB lcgD/sxbU2IFHOWsFtH9bjYYS//hj2gLwF3IWWnX9W0Gn0vqrqeHP/TiLFNVNtjvNtS6 wbfycP9V2rICyqgfckiBXpbeDukGk7bT/9EVdNqWqk96RiCgCZamxBz2G8HkZ9Y/zsPS O9B3Wk+s0iFv+YKWO/e9RyNMououPCWR0rn1MaC6QoUyaDZCMTKNV3o3b4l8kmhBT9rP nkb1szpTNbhymm3pfk3fhK9ZXh2xm3t9tvyVJf52NFimJ+xOWWysHdN3y4eToN2Deub7 5WLA==
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=Qa1+BBjny8/QmmpWAt/gaQ7i/C943yfwZqU2wj5pWQ0=; b=mjfqlyHUDC0Gn4mMxxTAfRV/h37L2z4mgtWLX2VqPTHNjRoijJHowiUtfEee6kac85 R1/L9p1kVSVpgJKA/5FYBcJU8W57I07BPQfVEVXrI2NI7RKQ+q16FUTFmI1w/zObhX+D Qp1xtv8NkPByd03U7jEg9m9B5ZwFFjM/V5P3ae8Rj5OXFsND26jhO1gw8gjz1uwAxTH3 zBlRdyVs/7o9MEynB3mY6tlFJcjCecgkufW+D3da1KPJdzPUVtvqXLNFLkhHILuGjr/P zDoi2q0vUEbr5bSkaIxhuSI5A6oxwd9bCeQ3ahKPj4wyrHkY8dqNNpfRQ3k9X+Vbnn5p QlSg==
X-Gm-Message-State: APjAAAU3awhDFmPKmKtwlPQrqHnCIFMnp1tgY+BA3WK4IBKomY6JUaN6 a9Vm9c06rx0sqW86DjW4pzPRfLVohJNnpsjyY7A=
X-Google-Smtp-Source: APXvYqxm5u/NLxhzIsemSuHiW5ACbVsIrD5gfz0d9CvQ27+fNiGl9g9oUowYhRWllAxMQ9+QWyb2yUbjBicTzcmcjyQ=
X-Received: by 2002:a6b:7316:: with SMTP id e22mr23639111ioh.205.1575937718988; Mon, 09 Dec 2019 16:28:38 -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> <CABNhwV0BAgAi60dq36MiauUv43+-r23AU-D=zV4jygo3gU=Cqg@mail.gmail.com> <c380b922-f11d-40df-173a-5faec0d8f7d3@si6networks.com>
In-Reply-To: <c380b922-f11d-40df-173a-5faec0d8f7d3@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 09 Dec 2019 19:28:27 -0500
Message-ID: <CABNhwV3LoSaR6PvjmZRU_w__A=P6fQ4rJmsGPPmnc8dSgCx2oQ@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="000000000000edb3e105994e97b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZROzJr1wStsfj09aMmSyaCS9o4E>
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: Tue, 10 Dec 2019 00:28:43 -0000

On Mon, Dec 9, 2019 at 5:37 PM Fernando Gont <fgont@si6networks.com> wrote:

> On 9/12/19 17:22, Gyan Mishra wrote:
> >
> > 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.
>
> What do you mean by SRv6? draft-ietf-6man-segment-routing-header?
> Something else?
>
> If you meant draft-ietf-6man-segment-routing-header, and without
> re-reading now, I'd probably agree.


   Yes SRH draft Sec 3.1

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26

>
So from any external CE Ingress PE-CE link to source PE of SR domain the
traffic has to be encapsulated for the BGP services overlay vpnv4 vpnv6
IPv4 IPv6 so that becomes the payload and the new outer header
encapsulation added has the EH inserted.

IPv6 | SRH | Payload BGP overlay IPv4 or IPv6

>
>
> Now, if you mean network-programming, then the very words "Penultimate
> segment popping" should probably ring some bells. Because if you are
> popping anything at any place other than the last segment, you are
> violating RFC8200.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --

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