Re: [spring] [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane)

Satoru Matsushima <satoru.matsushima@gmail.com> Tue, 29 August 2017 01:44 UTC

Return-Path: <satoru.matsushima@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BD1321AC; Mon, 28 Aug 2017 18:44:20 -0700 (PDT)
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 T6_fzWVIv0Vr; Mon, 28 Aug 2017 18:44:18 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 7E927126BF3; Mon, 28 Aug 2017 18:44:18 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id j7so6053243vke.0; Mon, 28 Aug 2017 18:44:18 -0700 (PDT)
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=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=uCgk7lhh1FFj9GTulKDOzT4C7AY3UwEp7bdZzsHm+PbNDgUaqP0ayPwuzACT9YSltx PWLt04yI9FOJy89ZiHtq0NlNs3HaIwx+XQHM0rflwfcrU1NwhYICoVjgIhx+t/CDupk8 XJXl1M9aMDkaGzqgsR1Jf8IUZdEbRqI7lJHRFrEZuJiGK+uEflnJh/Qn13cr0uCUm6id C/+HRra3OwLaRxXSCxGMuiWZFMeY4Sh/6htxogd+RF9VBkmY9ho8lMEX4zBhckfnPbFm RtOSJEr98LwEIH1yp2QgaidGCL79r1Wjaf1i2bazSLTjUWtdQa2YZZ+3YgM4d7yW4jmx gGqA==
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=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=rhJyk1zcCFzM6xiYi+B+8TQkznNuTuB5HQ+InoF7+NnIohXMG4z89fRMDmtpUx/qm9 JDPhDCC6O6+ac1A8Qq9pus3U2ZD2YRi3ZmeedCp2hvUzF4iw+VqyFT7o0HA1gS5Y1IYJ Zl3c4EoBU2CnTbBYr+Gb+JHWG15mKb56eOvCfqFzdGoGW+yMd5UUyZ7KA2dopnJ0cfjL 8SrN1I2hBjqAZwQkDiM+j4eaGv3IdVIAdxJ6CQiaQ6kG2zjopn7iAuzdT5D7YlX+STHf Hg7W1VGdYjFCjV8tDGK/4FXoD+Bmvc5F9IpkLTGCAzmJUQ9WtvAltKHLvbP6bOy2FwwQ drcw==
X-Gm-Message-State: AHYfb5h8dAECQGM07ZPR/REo5ZDz42QAVs8xVzSGDhZqWGH7/CeRaPJ0 6gD54oTy3hpxmWCBMWKTqeDK852K1Q==
X-Received: by 10.31.108.215 with SMTP id j84mr1547083vki.7.1503971057549; Mon, 28 Aug 2017 18:44:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:44:16 -0700 (PDT)
In-Reply-To: <emedf1d248-b431-4377-be6a-728eb11c34a0@ebiken-desktop>
References: <emf443bb9d-b30a-4226-b2ad-a3cd141e4241@ebiken-desktop> <emedf1d248-b431-4377-be6a-728eb11c34a0@ebiken-desktop>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
Date: Tue, 29 Aug 2017 10:44:16 +0900
Message-ID: <CAFwJXX7w4bKDX4MrCy40dygqhi015WpOX6=rpoj0hGvCh8G+Yg@mail.gmail.com>
To: Kentaro Ebisawa <ebiken.g@gmail.com>
Cc: dmm <dmm@ietf.org>, spring@ietf.org, Matsushima Satoru <satoru.matsushima@g.softbank.co.jp>
Content-Type: multipart/alternative; boundary="001a1147a148a347c40557da8ce8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/BAHMkue4RUoJsgL4LO09twlWb5o>
Subject: Re: [spring] [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 01:44:20 -0000

Hi Kentaro,

I've replied to your previous mail that I hope it would answer to your
questions.

On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa <ebiken.g@gmail.com>
wrote:

> Hi,
>
> > Q2) Down Link packet (SRv6 to existing network)
> > > When the endpoint receives packet and the active segment of the
> > > packet indicates the SID, the endpoint pop the SRH of the SID, and
> > ...
> >
> > IPv6 Src: Origin Host
> > IPv6 Dst: SL[n]
> > Segment Left = n
> > SL[m] = Encoded SID
> > SL[m+1] = Segment m+1
> > SL[n] = Segment n
>
> Actually I think this differs for T.Insert case, where MN user packet is
> IPv6.
> # Unless I missed description that Stateless Interworking will always use
> encapsulation mode even if user packet is IPv6.


In DL, Stateless Interworking uses encapsulation for original IPv6 packet
with IPv4 and tunnel header.



>
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left = n
> SL[0] = MN address
> SL[1] = Encoded SID
> SL[n] = Segment n
>
>
As I mentioned in the previous mail, SL indicates SL[1] at the interworking
node.



> And interworking segment should behave like below.
>
> When the endpoint receives packet and the active segment of the
> packet indicates the SID, the endpoint pop the SRH of the SID,
> >> Set IPv6 destination address as SL[0] (MN's address), and
> then the endpoint encaps the payload with the encoded information in
> the SID which are tunnel identifier of tunnel header, source and
> destination IPv4 address of IPv4 header described in Figure 3.
>


Right, it looks more precise description to it. Thanks!



>
> Maybe having example packet headers described for each cases
> (encap/insert, User Packet = IPv4/IPv6) will help this makes more easier to
> understand.
>
>
Absolutely yes, it's helpful to understand. I'll update the I-D with that
example in next revision.

Thanks,
--satoru