IETF Logo Mail Archive

Re: [DMM] Comment on SRv6-mobile-userplane

Uma Chunduri <uma.chunduri@huawei.com> Wed, 18 July 2018 16:41 UTC

Return-Path: <uma.chunduri@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17A81311AC; Wed, 18 Jul 2018 09:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 S-sYXxp1lH_c; Wed, 18 Jul 2018 09:41:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437D8124C04; Wed, 18 Jul 2018 09:41:26 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DE884A30D16B; Wed, 18 Jul 2018 17:41:20 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 18 Jul 2018 17:41:22 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.200]) with mapi id 14.03.0399.000; Wed, 18 Jul 2018 09:41:14 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Tom Herbert <tom@quantonium.net>
CC: Arashmid Akhavain <arashmid.akhavain@huawei.com>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] Comment on SRv6-mobile-userplane
Thread-Index: AQHUHeJOMGoNa5lPFEy09z+eeet+kqSTwP+wgAE0FzCAAI5JAP//ntEwgAB7lAD//5C58A==
Date: Wed, 18 Jul 2018 16:41:14 +0000
Message-ID: <25B4902B1192E84696414485F5726854135F57D8@sjceml521-mbx.china.huawei.com>
References: <A673876A-FCBD-4C06-902D-F0DB31D0C1EB@cisco.com> <25B4902B1192E84696414485F5726854135F43A7@sjceml521-mbx.china.huawei.com> <D57109449177B54F8B9C093953AC5BCD74BEC4DE@YYZEML701-CHM.china.huawei.com> <CAPDqMer=GDkGMfOp4Nfxbv+is_fBJhhQk7yZKg+7ZxeRReYE0w@mail.gmail.com> <25B4902B1192E84696414485F5726854135F5751@sjceml521-mbx.china.huawei.com> <CAPDqMeor45W5FJTqFc7awg67UFo-oCBJA0Fpo_f8U+MG1r9NvQ@mail.gmail.com>
In-Reply-To: <CAPDqMeor45W5FJTqFc7awg67UFo-oCBJA0Fpo_f8U+MG1r9NvQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.124.182.159]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/g-M9MPm89yGfa4BR4dKegoojuWg>
Subject: Re: [DMM] Comment on SRv6-mobile-userplane
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 16:41:29 -0000

Tom,

In-line [Uma]:
--
Uma C.


-----Original Message-----
From: Tom Herbert [mailto:tom@quantonium.net] 
Sent: Wednesday, July 18, 2018 12:12 PM
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Arashmid Akhavain <arashmid.akhavain@huawei.com>; Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; spring@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri <uma.chunduri@huawei.com> wrote:
> Tom,
>
>         >I think the terminology being used in the draft might be making this seem complicated than it actually is. AFAICT, SRv6 traditional mode is nothing more than IP in IP encapsulation, so the requirement of the underlay is that it
>                 >forwards IPv6 and intermediate nodes treat the traffic as "normal IPv6 traffic". There is no segment routing involved, no extension headers needed, and the only upgrade for the network is to support IPv6.
>
> I am not sure that is the case. Please re-read Section 5.1 (and 5.1.3)
>         " This 1-for-1 mapping is
>                    replicated here to replace the GTP encaps with the SRv6 encaps, while
>                    not changing anything else."
>
Uma,

Right, there is where the terminology of the draft is confusing. SRv6 defines a routing extension header not an encapsulation protocol.

[Uma]: Agree.


"SRv6 encaps" here means IP packets (presumably either IPv4 or IPv6) are encapsulated in IPv6 using standard IP/IP encpasulation.

[Uma]: Sure. But, I think, I would see  https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01  folks speak.  As of now, one should go by what's there in this draft.


Concurrent with that encapsulation, a segment routing header or other extension headers may be added to the outer IP header (this is consistent with RFC8200 requirement that only source nodes can set extension headers). So there is really no such thing as SRv6 encapsulation, and in the text above replacing SRv6 with IP-in-IP would be much clearer as to how the protocol works.

[Uma]: If we just replace SRv6 with IP-in-IP (IPv6) - I am not sure what's being achieved and how that encapsulation is relevant  to this draft? 


Tom

> --
> Uma C.

v2.23.0 | Report a Bug | By Email