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

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Sat, 27 January 2018 01:48 UTC

Return-Path: <sgundave@cisco.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 30A7812DB71; Fri, 26 Jan 2018 17:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PJt0o22U5VTV; Fri, 26 Jan 2018 17:48:39 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F3D12D84B; Fri, 26 Jan 2018 17:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11024; q=dns/txt; s=iport; t=1517017719; x=1518227319; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rygm+KpsP3oKdUtADZOcYpabhyUA0AksoTZL7CBsoyk=; b=SHvOqY7ZXZqZHcxd5ruvq66R2nwn1vEPMlcgdA+Tsl9hqf9IkrPjHBeJ 4Fs8I3oCdV2CgUwlOuGl461fXgwAu7K9DOBlV3SnXC9n8CTPCvxORsCFA XijGw7jqaqk1Q51X0EmmPqANONmFqPVFmam/y/dkyP7goBABY3ICxVQgY I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DDAAAc2mta/4MNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJKeGZ0JweNeo5rggKRcIVUFYICCiWFFgKCHlQYAQEBAQEBAQECayiFIwEBAQMBJ1cLAgEIEQMBAigHMhQJCAIEARKJUVwIELNyOopXAQEBAQEBAQEBAQEBAQEBAQEBARoFhFKCFYFXgWiDLoMvAgIBgVY4hVwFimqIH5EKAogVjU+EHpAKjWCJUgIRGQGBOwEfOYFQcBWCVwEBDoJVHIFneI4SgRcBAQE
X-IronPort-AV: E=Sophos;i="5.46,419,1511827200"; d="scan'208,217";a="348207949"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2018 01:48:38 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0R1mb0E006378 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 27 Jan 2018 01:48:38 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 26 Jan 2018 19:48:37 -0600
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 26 Jan 2018 19:48:37 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Tom Herbert <tom@quantonium.net>, "dmm@ietf.org" <dmm@ietf.org>, "ila@ietf.org" <ila@ietf.org>
Thread-Topic: [DMM] Questions about SRv6 mobile user-plane
Thread-Index: AQHTlxDyYwXheQXob0qzxxgYfwxvSQ==
Date: Sat, 27 Jan 2018 01:48:37 +0000
Message-ID: <D6911A3F.2A208A%sgundave@cisco.com>
References: <CAPDqMerEUMEpKWSu3nC+rxcNpOj_LckvQwPga9bzkDdAYpSwwQ@mail.gmail.com> <D69114C4.2A206E%sgundave@cisco.com>
In-Reply-To: <D69114C4.2A206E%sgundave@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.60]
Content-Type: multipart/alternative; boundary="_000_D6911A3F2A208Asgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/pkwAUmQ0zKp_tS2w1MYNwxKCvR4>
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: Sat, 27 Jan 2018 01:48:42 -0000

Typo's ... SID -> SIR


From: dmm <dmm-bounces@ietf.org<mailto:dmm-bounces@ietf.org>> on behalf of Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Date: Friday, January 26, 2018 at 5:35 PM
To: Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, "ila@ietf.org<mailto:ila@ietf.org>" <ila@ietf.org<mailto:ila@ietf.org>>
Subject: Re: [DMM] Questions about SRv6 mobile user-plane

Hi Tom,

> I am working on a comparison between ILA and SRv6 for the mobile user-plane.

This is a good effort. I was wondering, about the key parameters that you will use for this comparison between ILA/ILNP/LISP/HICN etc. For example, ILA router the entries at the ILA router ( ID - L OC  - SIR Prefix), vs at the LISP mapping system. How do you compare the two, a cache/MAP query cost, vs a translation cost + local memory state for keeping that entry.

On a different note, just curious if SID prefix can ever have topological relevance and can be used for routing. In other words, can you ever route a packet without translating  the SIR prefix of the destination address with the locator? Can SID prefix be used as a locator in some special cases?

Sri





From: dmm <dmm-bounces@ietf.org<mailto:dmm-bounces@ietf.org>> on behalf of Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, "ila@ietf.org<mailto:ila@ietf.org>" <ila@ietf.org<mailto: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