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

From: "Kentaro Ebisawa" <[email-masked]>
Date: Mon, 28 Aug 2017 14:52:44 +0000

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-mobile-user-plane/

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.

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

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?
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 <[email-masked]>

---

From: "Kentaro Ebisawa" <[email-masked]>
Date: Mon, 28 Aug 2017 15:44:05 +0000

Hi,

 > ...

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.

IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left = n
SL[0] = MN address
SL[1] = Encoded SID
SL[n] = Segment n

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.

Maybe having example packet headers described for each cases 
(encap/insert, User Packet = IPv4/IPv6) will help this makes more easier 
to understand.

Thanks,

------ Original Message ------
From: "Kentaro Ebisawa" <[email-masked]>
To: [email-masked]; [email-masked]
Cc: "Matsushima Satoru" <[email-masked]>
Sent: 2017/08/28 23:52:44
Subject: How Encoded SID should be placed in SL (SRv6-mobile-uplane)

>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.
>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 29 Aug 2017 10:24:53 +0900

Hi Kentaro,

On Mon, Aug 28, 2017 at 11:52 PM, Kentaro Ebisawa <[email-masked]>
wrote:

> # 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.

> > 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.

> For example, is below packet structure what you intended in case you have
> n segments to traverse in SRv6 nework?
>
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.

> 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

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 29 Aug 2017 10:44:16 +0900

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 <[email-masked]>
wrote:

> # 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.

> SL[n] = Segment n
As I mentioned in the previous mail, SL indicates SL[1] at the interworking
node.

> destination IPv4 address of IPv4 header described in Figure 3.

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

> (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

---

From: "Kentaro Ebisawa" <[email-masked]>
Date: Wed, 30 Aug 2017 12:35:30 +0000

Hi Satoru,

Thank you for the email replies and taking time for offline discussion.

Your explanation in the emails clarified my questions, and leaving a few 
notes below to share clarification made during the offline chat for 
others on the list.

* In the draft, SRv6-mobile-uplane, IPv4 client packets will use Encap 
and IPv6 packets will use Insert while traversing SRv6 network.
* For UL, Encoded SID will be SL[1]
     * Exist side of SRv6 and not on the interworking node in DL.
     * SL[0] is an end host on external network who MN is communicating 
with.
* "Locater of interwork" differes for UL and DL. (as mentioned in the 
draft)

Regards,

------ Original Message ------
From: "Satoru Matsushima" <[email-masked]>
To: "Kentaro Ebisawa" <[email-masked]>
Cc: "dmm" <[email-masked]>; [email-masked]; "Matsushima Satoru" 
<[email-masked]>
Sent: 2017/08/29 10:44:16
Subject: Re: [DMM] How Encoded SID should be placed in SL 
(SRv6-mobile-uplane)

>>Actually I think this differs for T.Insert case, where MN 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.
>
>
>>(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
>