Re: [Ila] [DMM] Questions about SRv6 mobile user-plane

Miya Kohno <miya.kohno@gmail.com> Sun, 28 January 2018 13:30 UTC

Return-Path: <miya.kohno@gmail.com>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08312EBCF; Sun, 28 Jan 2018 05:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 bEFeOXvcXlr0; Sun, 28 Jan 2018 05:30:39 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 A80A512DA11; Sun, 28 Jan 2018 05:30:39 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id l17so4873372ioc.3; Sun, 28 Jan 2018 05:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QSUZNK3RZ3gClpPBEyifSQ2P52EOCxYgizPs2obAg3A=; b=tzO0HRtj00zAI9PluRggnSxoBvsaHUUq/A6th1HSq6KdIO1zMcQc3ddFf/bB36Dmag 2aldWBF3PqNapVVLNwKT/ZP4xWYb4Au0CT2XDLVxOf4xkYBux3m0hblCNG1a44gKe40P PLZuAztQWXb9dXDkbreF3/r5t192cLTYhdikxfyk8ecacKWlrW4pywCZuCTkKl/Z2pFQ M/UtcmaA2DJdSuHH6Z+QCnDfvqrgGBMbIDWhTK6nzkyVp6FfOcPxiex1qOrQA3sly5Nb +yqI+IQqsg2OU64UjOBw8R2pnAPDzPmNUSP73skF0t6sZInaRXK27yD98daRLEXJuvWp 1LQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QSUZNK3RZ3gClpPBEyifSQ2P52EOCxYgizPs2obAg3A=; b=fSqKXb1ud1n2cFVBi+gP5b8W+LscX0Sun8iQsqoloZxvRIqP5l/ARWFPv0UVIyaFBO MVwT0A6UVpmbc075ihD7+DgV9VvGzX7ZJvCYRMPjB5KYo0l1REv4T2LhC8biJeNnoja+ YheTCWJ2WvlD5ZVjIUN3G7gFoXldpiaI0pvqSWiTuYFOGNfaTr+u+P5zNuOJ9cejwtPG QtrpA3cFFm+TxD7WNZ2da+Feg2f768vnrA82KjPyYaanx7/+KZ5B3r6QvJvjfvOtWNR+ xJa6744r8j2GZVopT8yKAEJdnEzOs/WGtwt1IJ5xpDb5VmZkLi1SfkH2OcG05x6llnaH S4KQ==
X-Gm-Message-State: AKwxytcnPAt8dEOh+3m9ziwLZQC94psZZTeAMqOQ2pnnbbSo8yAieOKN Oa2APR/Yv87T0icOmoVHh7bHN9ub8WcOV8eby74=
X-Google-Smtp-Source: AH8x227awzFoi+m83qb8jTFmZgyaXlypob1sKOLSGyDrieIOz1UgscQVJcbYyFQ4Gje8oI9CSfWFKBaD0iuweOIDZE4=
X-Received: by 10.107.36.195 with SMTP id k186mr22597764iok.131.1517146239002; Sun, 28 Jan 2018 05:30:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.34.204 with HTTP; Sun, 28 Jan 2018 05:30:38 -0800 (PST)
In-Reply-To: <CAPDqMerEUMEpKWSu3nC+rxcNpOj_LckvQwPga9bzkDdAYpSwwQ@mail.gmail.com>
References: <CAPDqMerEUMEpKWSu3nC+rxcNpOj_LckvQwPga9bzkDdAYpSwwQ@mail.gmail.com>
From: Miya Kohno <miya.kohno@gmail.com>
Date: Sun, 28 Jan 2018 22:30:38 +0900
Message-ID: <CAG99tekrwTV3hEw5z73unnV1ghynLdqBrm2qeTsWTKMeD9cgcA@mail.gmail.com>
To: Tom Herbert <tom@quantonium.net>
Cc: dmm@ietf.org, ila@ietf.org
Content-Type: multipart/alternative; boundary="001a1140e794a5efe50563d6226b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/eVmxjbLa8wnLkRzLTJS4C2avJQ0>
Subject: Re: [Ila] [DMM] Questions about SRv6 mobile user-plane
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jan 2018 13:30:42 -0000

Hi Tom,

Thank you, first of all, for your interest!

Yes, SID list can be reduced in some cases. I agree it should be restricted
to the minimum necessary.

I think ILA and SRv6 share a common view, while SRv6 allows more flexible
functions.

Regarding RFC8200, attacks can be and should be prevented in another way.
If under agreement, header insertion, which could make network more
efficient, should be allowed.

I hope ILA and SRv6 converge.

Miya@a co-author of SRv6 mobile data plane

On Sat, Jan 27, 2018 at 2:13 AM, Tom Herbert <tom@quantonium.net> wrote:

> Hello,
>
> I am working on a comparison between ILA and SRv6 for the mobile
> user-plane. I have some questions/comments about SRv6 and particularly on
> the example use cases that were depicted in the slides that were presented
> in IETF100:
>
> https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-dmm-srv6-for-mobile-user-plane/
>
> - It's clear from the depicted use cases that extension header insertion
> is being done by intermediate nodes, but extension header insertion is
> currently prohibited by RFC8200. There was an I-D posted on 6man to allow
> this for SR, but that was met with pushback. Is there going to be followup
> to resolve this?
>
> - For the uplink use cases, this seems to be more like using SR to source
> route to an egress router. In other words, it's not strictly related to
> mobility. Is there some connection to mobility that I'm missing?
>
> - The size or number of SR headers in the uplink cases seems to be larger
> than necessary (IMO minimizing these is important since each additional sid
> is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and
> DA=A2::1-- this seems to be redundant information. Also this depicts a
> second SR being inserted, but the first one should no longer be relevant.
> Why not just discard the first one and save the overhead? In the second
> scenario, DA is changing from A2::1 to A3::1, but AFAICT that was not done
> per the SR processing. What is the operation that happened here? (it's
> actaully looks like an ILA transfomation).
>
> - Considering the points above, could this have been done in the following
> manner to minimize overhead? A1 creates one SRH with one sid and makes
> DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet
> address, and EH is removed.
>
> - For downlink this does see to be relevant to mobility. But I have the
> same question, wouldn't it be less overhead to only use one SRH and one
> sid? i.e. A3 creates an SRH with just one sid that is the S:: (identifier
> in identifier/locator speak) and set DA to A2, and then A2 sets DA to A1,
> A1 restores original packet for delivery.
>
> - One possible typo. In the last use case slide SA=S:: and DA=D::, I
> believe these should be swapped?
>
> Thanks,
> Tom
>
>
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>