[Ila] Questions about SRv6 mobile user-plane

Tom Herbert <tom@quantonium.net> Fri, 26 January 2018 17:13 UTC

Return-Path: <tom@quantonium.net>
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 DAD7012DA4D for <ila@ietfa.amsl.com>; Fri, 26 Jan 2018 09:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 4_BK9paho6cH for <ila@ietfa.amsl.com>; Fri, 26 Jan 2018 09:13:47 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D6616126BF6 for <ila@ietf.org>; Fri, 26 Jan 2018 09:13:46 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id r78so22638374wme.0 for <ila@ietf.org>; Fri, 26 Jan 2018 09:13:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DcBUbkkGP87weoRkkSXURxvewdpPAmqi9BKJxweXz84=; b=BwvSmCbgqXdndvd38uXLRhtOmQ/xA/yZxudrGMOx1SMG7o4T6pWr/MPSsCIT0vGPhv M2cHjUCCjJ++PURfNZ8FN6bQmE3W7TcO6UMVNUg2F8H/2HYRzHPlKTOJQOKYIqYDScLL LH0m9pC9NjmekEWrn7CgcoIhMP50VaIsjwpzbBbKZdChM9+ZIecK2pGHxlqVYzZchBMY D9B6TDca4/C/6psREMqL8PObb2MpNQo8fJb7GPNPQDcGpebzZ6aOhwMtKnqiLMmm6tbU LeNbClIq8sRwNH6fHO/tbT/rQURCQJx21+b3U4FWBXOZLpJV5I6rNTplxMs1gXTCPeUv QpjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DcBUbkkGP87weoRkkSXURxvewdpPAmqi9BKJxweXz84=; b=V/EO+4pKEJyNBxRQbcFC0WpGaprrWB+q50rbrjhbKelY3WF/HB20d0ZmdM6lLXMxu5 c1uLQaK62ozoz9wifOfZ3msIINQAVG8tjzqS32aWGt0nFKS3vQ9ZPtPM1da6zRSnxgIo um63rjXNgHDwvc7WImjB40ThlAtNHSxFpMbg0sGyyZC2dkBcWd3fJiX6QRozhJwCfYwn Uy6ezFi+cVb9z8bX0R3Xf/W1wqCPBCiba4pqGNk6lwPkjHKPjnXR1wSIkoWBlSFYwprP ijoFtZLMYmYjKu1IUVN8CESt5G5EzGCq2NwhrrSiZ74c/NofVyoViUXAMNFkCpFEzg3l 2w/A==
X-Gm-Message-State: AKwxytdEVnWH1uRcdxk6BNsemszEOvsp9s9IlHSoul9TGLG1Lpd/1745 UsDaprU+bplESHKp6ajgaVqSxgsmogh/ktddlVmMUuzk
X-Google-Smtp-Source: AH8x226jKe6F/GbwPZ5N0f5ZPjamvmUTqKDAvfltTODTsRJcJMfADUsy2IIq/Sze6kftfD0RAHE5hSlierKgRB3Vca0=
X-Received: by 10.28.91.68 with SMTP id p65mr11700337wmb.119.1516986825345; Fri, 26 Jan 2018 09:13:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.66 with HTTP; Fri, 26 Jan 2018 09:13:44 -0800 (PST)
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 26 Jan 2018 09:13:44 -0800
Message-ID: <CAPDqMerEUMEpKWSu3nC+rxcNpOj_LckvQwPga9bzkDdAYpSwwQ@mail.gmail.com>
To: dmm@ietf.org, ila@ietf.org
Content-Type: multipart/alternative; boundary="001a11442262da9a430563b10487"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/4sG66ezcOYs94V2pUK66d8j2Paw>
Subject: [Ila] 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: Fri, 26 Jan 2018 17:13:50 -0000

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