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

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 26 January 2018 18:36 UTC

Return-Path: <jefftant.ietf@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 6B217124235; Fri, 26 Jan 2018 10:36:09 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6yEjq7I26gG4; Fri, 26 Jan 2018 10:36:06 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 C32001205F0; Fri, 26 Jan 2018 10:36:06 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id y27so781633pgc.5; Fri, 26 Jan 2018 10:36:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eX/Zn62styJ6MiVCsnfP9h1wcKiq3kCiEdOBKmyRrqM=; b=ntBtln16xVOhYyUzXjfCxEVJ1RSTah5oZWVRi1brC/AFIZkNd/YptVL0j++g5yJLMU fspDe4opNu1lOrb50nC9j8wlII2JEnLj0UAnCZhi7HyqGJF4ng2tFO68NEFzAPEkH7RU pPKjJJ7MGOx+92tJ2w9gwyRgOwmAGo1bZ2kyTnbXqrefw+AR6q+Upv7N/NIo//CIAd6W m4EQ8l+yPKvwIFhdj1yz7jFN0c4csgQpqIb44jKi8HJhtkzye86Htbs7ex/TtdeVMO3B Ik5XzFkihyy3Hl6VYwlq7GSOmLYgECuSHW0sVoMtuW8du5u4IWDwHvGBcuZUllRhf4Pv pNcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eX/Zn62styJ6MiVCsnfP9h1wcKiq3kCiEdOBKmyRrqM=; b=cwRkL32JN/UnkaIZ8D4CPd/FxM7WxekIVgM1QxJSz5G/As1m2WpLL9b0Jhy/y2rdq9 l4HmfGWEXVLCj5xztwMIsRgW0HxpdF9aMpGr8S8cqPoEtKt8FUqsA+//QxOXFpcuWXe4 mwhW/NfEIOIFmiwmT0DvnjgPo1Xswfz07OGE5sMcjcVVEqb2OfH7iCdJKf+0O92Mp0cp Y4O9oYzSeLks5TH+vOVWyLUQL5eVoJb9IETcktsUI0yFzduFq1f81dGEIlB/XkVYr2a3 9j9ji7LSFaLHZQr/W80MrcBIxqillqUG2wbkXeobGf+zGuEoPWvtjRLSagVINGgnk2lu z7XQ==
X-Gm-Message-State: AKwxytdw58LYjwbEDLBSHyzG4BVe8smg/lYBaEg3UvDDVzRMM8QrRVVc 6yUIRMWrd2/oWCVkNc4FUkDCKtQW
X-Google-Smtp-Source: AH8x2247gEgEUM50rMrBImfEcY96ZxEKh5lngwSGLQKYu2gzpo3UeR32rccxfGxDt7b3qiRURwZraw==
X-Received: by 10.99.96.203 with SMTP id u194mr16276712pgb.167.1516991766215; Fri, 26 Jan 2018 10:36:06 -0800 (PST)
Received: from [192.168.1.2] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id m67sm18586245pfi.157.2018.01.26.10.36.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 10:36:05 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-DA797D09-2AFD-4691-87BD-AA53D2C9A90A"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (15C202)
In-Reply-To: <D690A211.2A1F12%sgundave@cisco.com>
Date: Fri, 26 Jan 2018 10:36:05 -0800
Cc: Tom Herbert <tom@quantonium.net>, "dmm@ietf.org" <dmm@ietf.org>, "ila@ietf.org" <ila@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <949DAF6E-4537-4BFE-A0D5-15AC0FC5198E@gmail.com>
References: <CAPDqMerEUMEpKWSu3nC+rxcNpOj_LckvQwPga9bzkDdAYpSwwQ@mail.gmail.com> <D690A211.2A1F12%sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/_pRa5njOPdDlNGsfUzq0SIKgpBw>
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: Fri, 26 Jan 2018 18:36:09 -0000

Hi Sri,

My observations are very close to Tom’s.
Is new draft going to address questions asked or there will be follow up?

Thanks!

Regards,
Jeff

> On Jan 26, 2018, at 09:19, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
> 
> Hi Tom:
> 
> Marco and myself are planning to publish another proposal on anchor-less mobility (leveraging SRv6). That may be of interest to you from ILA point of view. We will post the draft in one or two weeks.
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> From: dmm <dmm-bounces@ietf.org> on behalf of Tom Herbert <tom@quantonium.net>
> Date: Friday, January 26, 2018 at 9:13 AM
> To: "dmm@ietf.org" <dmm@ietf.org>, "ila@ietf.org" <ila@ietf.org>
> Subject: [DMM] Questions about SRv6 mobile user-plane
> 
> 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
> 
>  
> 
> 
> _______________________________________________
> ila mailing list
> ila@ietf.org
> https://www.ietf.org/mailman/listinfo/ila