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:24 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 12AB11321A4; Mon, 28 Aug 2017 18:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 kMgxXlqgjzLz; Mon, 28 Aug 2017 18:24:54 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 95765126BF3; Mon, 28 Aug 2017 18:24:54 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id l132so5910400vke.5; Mon, 28 Aug 2017 18:24:54 -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=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=uW733BZcfBVi9yBPfR/goFrRLuIk+Y2Alg9RU4ojnodp0FT9H9l8hTgOnD8SMAtcC4 JRgAYuZOgNCnMOax9Ofny+IAiEdsSm1WHPyf9yKCrHhm8Am+mWl8SMmHYZY831C9q8DG zTS1fv0V0s6z3c3TyeziJuZiVdFZUF90V22CRCcQnnyDGTGWbZeSyCIXhufjp4hbVi8t 5qAELfRdgXrC/YVY6CG/oxCYDNO7nyhzbLefEuyckV8JqPOh4J/yunlxTDhqtqFoZpHc v5+yQrwVC1njagqj9uLYrPQt7MQ9lF0dzBqVVdpOjlpEVAN3tMTU/fNW9Dp2hA1iF41s dXyw==
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=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=ZOgajTZMxv1R+U1F40lV0IiqqcCQYWExpt9DAhNBU1jf982d1x85YiY0oALlNxjdPI /9VfRm4VhXcy6amPtkgMF/6JM0RtKsG6X31wClIwprxW3txIJcvsPj5FKucyOD6ShGgz zEGJIX0rrF1RbzQtpc4V2g/UwkHB8Qjt+mmUk1CZP3znZorWsby9HBW/Q1rhDmTZP5SV gWrpG5xdq2Wu1xHdDTkD4AnOFUE0aWs/qJ/ximcYekQhBRtxfHlmOfjFVaHTB11Bk8P1 pegB5CUDiyo6NYGmww6sCGRNbigH+/j4u1D3+nvRl4zZ/AawZN1VjiFSqJz2GJYHmOG2 FGVg==
X-Gm-Message-State: AHYfb5ixkA0c1l3qn/+tIuevn7qjhgpWe3xk0vkYp8qsBRmSY3U2Zan2 cXGzA1c2CjhzeFTN8lsDW+AUthD50f6U
X-Received: by 10.31.62.8 with SMTP id l8mr1646279vka.185.1503969893617; Mon, 28 Aug 2017 18:24:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:24:53 -0700 (PDT)
In-Reply-To: <emf443bb9d-b30a-4226-b2ad-a3cd141e4241@ebiken-desktop>
References: <emf443bb9d-b30a-4226-b2ad-a3cd141e4241@ebiken-desktop>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
Date: Tue, 29 Aug 2017 10:24:53 +0900
Message-ID: <CAFwJXX6aTonzK6HPS0xrp99jSx=_azhWiu4DABxxqvZTWc=pWA@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="001a1144776e4316c70557da47ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rgdgI-M45qZfNTXmUkkhiiHH61Q>
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:24:58 -0000

Hi Kentaro,


On Mon, Aug 28, 2017 at 11:52 PM, Kentaro Ebisawa <ebiken.g@gmail.com>
wrote:

> Hi,
>
> I have a few questions about how Encoded SID should be placed in Segment
> List and IPv6 Dst Address in Mobile User-Plane use case.
>
> # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01.
> # I tried to check Slides from IETF 99 but link seems to be missing.
> # https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobi
> le-user-plane/


That looks weird. It's not only for that document.
All ietf99 meeting materials are mis-linked from "
https://datatracker.ietf.org/meeting/99/agenda" page.



>
> Q1) Up Link packet (existing network to SRv6)
>
> > outer IPv4 and tunnel header. And then the endpoint does T.Insert
> > process with the SID which consists of the allocated domain-wise SID
> > prefix, source and destination addresses, and tunnel identifier as
> > described in Figure 3. Then the endpoint send out the packet to the
> > SRv6 network along with its routing policy.
>


In above text, we assumed that the payload encapsulated in the IPv4 tunnel
is an IPv6 packet.
So the source address of the packet should be an MN's address.


> How would IPv6 src/dst addr and Segment List look like for this Up Link
> packet? (existing network to SRv6)
> My understanding is usually source address of the T.Insert node is not
> included in Segment List.
> But from above description, it looks like you intend to require Encoded
> SID (Fig 3) to be included in the Segment List of UL packet.
>
> For example, is below packet structure what you intended in case you have
> n segments to traverse in SRv6 nework?
>
> IPv6 Src: Encoded SID or T.Insert node ??
> IPv6 Dst: SL[n]
> Segment Left = n
> SL[0] = Segment 0
> SL[n] = Segment n
> SL[n+1] = Encoded SID
>
>
SL[0] must be original destination address of the IPv6 packet which the MN
sends out.
The SID which consists of the existing network tunnel info would be placed
at SL[1]. In case of that it means that the endpoint which the SID
indicates is egress of the SRv6 domain. If any other endpoints exist in the
segment list, that SID would be placed at SL[n] where n >=2.



> 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
>
> On the other hand, are there any reason that description in page 7 does
> not mandate m to be zero while requiring to pop the SRH?
>

As similar with UL, SL[0] must be original destination address. In DL
direction the interworking node must be egress of the SRv6 domain so that
the tunnel info encoded SID should be placed in SL[1].

Best regards,
--satoru



> My understanding of DL packet (SRv6 to existing network) is as below.
>
> 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
>
>
> Regards,
> --
> Ponto Networks, Inc.
> Kentaro Ebisawa <ebiken.g@gmail.com>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>