Subject: Re: [spring] Comment on SRv6-mobile-userplane

From: Uma Chunduri <[email-masked]>
Date: Tue, 17 Jul 2018 19:09:59 +0000

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri <[email-masked]>
Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; Alberto Rodriguez Natal (natal) <[email-masked]>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you have raised a comment saying that SRv6 mandates an integration in between the overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions with complete independence from the transport network. No matter whether the transport is MPLS, IPv6 or whatever -without any SR at all-.

[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1

“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable nodes use SIDs to direct user traffic

   between the UPFs.”

If we propose this is a drop-in replacement for GTP-U –  this could force (with the approval of IETF and 3GPP)  every operator to use SRv6; as TEID functionality is basic to any 3GPP procedure (not only for Xn, N2 and whatever mobility case out there, service request, paging and you name it..).
I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it or transitioning to.

On the other hand if it is only for some PDU sessions then this need to be specifically mentioned in the draft as well as the “optimized mobile user plane” response.

Hence, if an operator would like to have integration of the overlay and underlay (for end-to-end network slicing), he can have such integration. If this is not desired, the dmm-srv6-mobile-uplane proposal can work completely independently from the transport, as already documented in the draft.

[Uma]: It would be great if we strive to achieve that independence as much as possible while focusing on the value and feature SRv6 brings it to the table.

I will check with the rest of co-authors of the draft to see whether we should clarify in the draft the independence from the transport network.

[Uma]: Sure, thanks for your consideration.

Cheers,
Pablo.

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 18 Jul 2018 13:18:00 +0000

Hi Uma,

I am not sure if I understand your concern. In traditional mode, we encode the TEID into a SID. This is the mode that draft bogineni refers to as the simplest form of using SRv6 for the N9 interface.
Only the head nodes know that TEID has been encoded into the SID. Tandem nodes treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 in general forces the underlying say MPLS transport to convert to SRv6?

Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; Alberto Rodriguez Natal (natal) <[email-masked]>; [email-masked]
Subject: RE: Comment on SRv6-mobile-userplane

Hi Pablo,

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>; Alberto Rodriguez Natal (natal) <[email-masked]<mailto:[email-masked]>>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

From Section 5.1

   between the UPFs.”

Cheers,
Pablo.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 07:37:48 -0700

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain
<[email-masked]> wrote:
> Hi Uma,
>
>
>
> I am not sure if I understand your concern. In traditional mode, we encode
> the TEID into a SID. This is the mode that draft bogineni refers to as the
> simplest form of using SRv6 for the N9 interface.
>
> Only the head nodes know that TEID has been encoded into the SID. Tandem
> nodes treat the traffic as normal SRv6 traffic. Are you saying that the use
> of SRv6 in general forces the underlying say MPLS transport to convert to
> SRv6?

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. One caveat to that is that some
intermediate nodes may want to do DPI into transport layer to get
ports for ECMP or other reasons, if that is desirable it would be easy
enough to alternatively use a UDP encapsulation-- either continue with
GTP or switch to a more generic one like GUE.

Tom

> Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; Alberto
> Rodriguez Natal (natal) <[email-masked]>; [email-masked]
> Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; Alberto
> Rodriguez Natal (natal) <[email-masked]>
> During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane
> you have raised a comment saying that SRv6 mandates an integration in
> between the overlay and the underlay transport network.
>
>
>
> I would like to clarify that this is NOT true. Please read
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
>
> The Traditional mode is only offering GTP replacement for specific PDU
> sessions with complete independence from the transport network. No matter
> whether the transport is MPLS, IPv6 or whatever -without any SR at all-.
>
>
>
>
>
> I also believe, that way because this is being sent as response to CT4 as a
> replacement alternative to GTP-U with SRv6 underlay in traditional mode.
>
>
>
> If we propose this is a drop-in replacement for GTP-U –  this could force
> (with the approval of IETF and 3GPP)  every operator to use SRv6; as TEID
> functionality is basic to any 3GPP procedure (not only for Xn, N2 and
> whatever mobility case out there, service request, paging and you name
> it..).
>
> On the other hand if it is only for some PDU sessions then this need to be
> specifically mentioned in the draft as well as the “optimized mobile user
> plane” response.
>
>
>
>
>
> Hence, if an operator would like to have integration of the overlay and
> underlay (for end-to-end network slicing), he can have such integration. If
> this is not desired, the dmm-srv6-mobile-uplane proposal can work completely
> independently from the transport, as already documented in the draft.
>
>
>
> [Uma]: It would be great if we strive to achieve that independence as much
> as possible while focusing on the value and feature SRv6 brings it to the
> table.
>
>
>
> I will check with the rest of co-authors of the draft to see whether we
> should clarify in the draft the independence from the transport network.
>
>
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 18 Jul 2018 15:10:22 +0000

Hi Tom,
Thank you for the reply. You are right, the underlay network doesn't care... I think this is also true for scenarios where the extension header is present.

Arashmid

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2018 10:38 AM
To: Arashmid Akhavain <[email-masked]>
Cc: Uma Chunduri <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain <[email-masked]> wrote:
> Hi Uma,
>
>
>
> I am not sure if I understand your concern. In traditional mode, we 
> encode the TEID into a SID. This is the mode that draft bogineni 
> refers to as the simplest form of using SRv6 for the N9 interface.
>
> Only the head nodes know that TEID has been encoded into the SID. 
> Tandem nodes treat the traffic as normal SRv6 traffic. Are you saying 
> that the use of SRv6 in general forces the underlying say MPLS 
> transport to convert to SRv6?

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. One caveat to that is that some intermediate nodes may want to do DPI into transport layer to get ports for ECMP or other reasons, if that is desirable it would be easy enough to alternatively use a UDP encapsulation-- either continue with GTP or switch to a more generic one like GUE.

Tom

> Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; 
> Alberto Rodriguez Natal (natal) <[email-masked]>; [email-masked]
> Cc: [email-masked]; Arashmid Akhavain <[email-masked]>; 
> Alberto Rodriguez Natal (natal) <[email-masked]>
> During the presentation of 
> draft-bogineni-dmm-optimized-mobile-user-plane
> sessions with complete independence from the transport network. No 
> matter whether the transport is MPLS, IPv6 or whatever -without any SR at all-.
>
>
>
>
>
> I also believe, that way because this is being sent as response to CT4 
> as a replacement alternative to GTP-U with SRv6 underlay in traditional mode.
>
>
>
> If we propose this is a drop-in replacement for GTP-U –  this could 
> force (with the approval of IETF and 3GPP)  every operator to use 
> SRv6; as TEID functionality is basic to any 3GPP procedure (not only 
> for Xn, N2 and whatever mobility case out there, service request, 
> paging and you name it..).
>
> On the other hand if it is only for some PDU sessions then this need 
> to be specifically mentioned in the draft as well as the “optimized 
> mobile user plane” response.
>
>
>
>
>
> Hence, if an operator would like to have integration of the overlay 
> and underlay (for end-to-end network slicing), he can have such 
> integration. If this is not desired, the dmm-srv6-mobile-uplane 
> proposal can work completely independently from the transport, as already documented in the draft.
>
>
>
> [Uma]: It would be great if we strive to achieve that independence as 
> much as possible while focusing on the value and feature SRv6 brings 
> it to the table.
>
>
>
> I will check with the rest of co-authors of the draft to see whether 
> we should clarify in the draft the independence from the transport network.
>
>
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 18 Jul 2018 15:44:09 +0000

Tom,

Isn't the IPv6 flow label designed exactly to avoid that? Are you suggesting to use UDP to avoid using the flow label?

Cheers,
Pablo.

On 18/07/2018, 10:37, "Tom Herbert" <[email-masked]> wrote:

    One caveat to that is that some

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Jul 2018 15:49:45 +0000

Arash,

In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain
Sent: Wednesday, July 18, 2018 9:18 AM

Hi Uma,

[Uma]:  2 quick and minor corrections for the above first.

1.      “we encode the TEID into a SID”  ==> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  says “Note that in this mode the TEID is embedded in each SID.” (section 5.1.3 confirms this)

2.      Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 in general forces the underlying say MPLS…

[Uma]:  The problem with removing GTP header and keeping the same in each SRH SIDs make the underlay specific to SRv6.
                 Pablo’s below response says – “The Traditional mode is only offering GTP replacement for specific PDU sessions with complete independence from the transport network.”
            I don’t see the draft text reflects this.

Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>; Alberto Rodriguez Natal (natal) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Comment on SRv6-mobile-userplane

Hi Pablo,

--
Uma C.

Hi Uma,

From Section 5.1

   between the UPFs.”

Cheers,
Pablo.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Jul 2018 15:56:31 +0000

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 08:58:20 -0700

On Wed, Jul 18, 2018 at 8:44 AM, Pablo Camarillo (pcamaril)
<[email-masked]> wrote:
> Tom,
>
> Isn't the IPv6 flow label designed exactly to avoid that?

Yes, that is supposed to handle ECMP. There are might be other
optimizations of packets for UDP and TCP that could be lost in IP/IP
encapsulation.

> Are you suggesting to use UDP to avoid using the flow label?
>
No, I would much prefer that flow label is used for ECMP and
intermediate nodes stop doing DPI. Problem is that there's been
resistence from some operators to enabling the flow label for ECMP
since it might not be persistent for a flow, this can wreak havoc in
deployments that maintain state in the network of need consistent
hashing for load balancing. Discussion on this issue occasionally pops
up on 6man list.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 09:12:16 -0700

>                    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.
"SRv6 encaps" here means IP packets (presumably either IPv4 or IPv6)
are encapsulated in IPv6 using standard IP/IP encpasulation.
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.

Tom

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 18 Jul 2018 16:12:19 +0000

Hi Uma,

Please see my replies inline [Arashmid]

Cheers,
Arashmid

From: Uma Chunduri
Sent: Wednesday, July 18, 2018 11:50 AM
To: Arashmid Akhavain <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Alberto Rodriguez Natal (natal) <[email-masked]>; [email-masked]
Subject: RE: Comment on SRv6-mobile-userplane

Arash,

In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain

Hi Uma,

[Arashmid] Embed vs Encode? Is this issue?

2.      Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9
[Arashmid] Yes, it does, but the focus of draft bogenini is N9

[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and SGW and between SGW and PGW. For example for a UE with both internet access and VoLTE, there are two GTP tunnels between the eNB and the SGW and two other GTP tunnels between the SGW and the PGW. We maintain this in traditional mode.

For example in interworking model when we need to deal with IPv4 GTP tunnels, the SA and DA part of the SID will remain the same, but the TEID will be different. 4 GTP tunnels for the above mentioned UE sessions will produce 4 SIDs which differ by the bits identifying the TEID

Cheers,
Arash

From: Uma Chunduri

Hi Pablo,

--
Uma C.

Hi Uma,

From Section 5.1

   between the UPFs.”

Cheers,
Pablo.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 18 Jul 2018 16:28:31 +0000

Uma,

As I already clarified in my previous email, the proposal of draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes treat the traffic as normal SRv6 traffic.

The proposal of the draft requires that for example the UPFs are SRv6 capable. However, any transport network in between the two SRv6 UPFs does not need to be SRv6 capable. It just needs to forward IPv6 packets. This is defined in RFC8200.
Hence, it does not matter what underlay transport you use. It is independent.

Are you saying that the use of SRv6 in general forces the underlying say MPLS transport to convert to SRv6?

No. Its independent. Underlay can be anything.

As I already said in my previous email, we will clarify this in the next revision of the draft.

Thanks,
Pablo.

From: Uma Chunduri <[email-masked]>
Date: Wednesday, 18 July 2018 at 11:50
To: Arashmid Akhavain <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Alberto Rodriguez Natal (natal)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comment on SRv6-mobile-userplane

Arash,

In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain

Hi Uma,

Cheers,
Arash

From: Uma Chunduri

Hi Pablo,

--
Uma C.

Hi Uma,

From Section 5.1

   between the UPFs.”

Cheers,
Pablo.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Jul 2018 16:31:13 +0000

Hi Arashmid,

>>[Uma]:  2 quick and minor corrections for the above first.“we encode the TEID into a SID”  ==> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  says “Note that in this mode the TEID is embedded in each SID.”
>>(section 5.1.3 confirms this)

     >[Arashmid] Embed vs Encode? Is this issue?

[Uma2:]It’s not embed or encode. It says each SID.

>We maintain this in traditional mode.

[Uma2]: I am not questioning how each bearer get a different TEID or how separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW.  It’s good this being planned to achieve in traditional mode. However, if this is seen as GTP replacement option, by moving TEID of the GTP header encoded into each SRv6 SID, the unintended consequence is we are making 3GPP functionalities that are associated with TEID specific to one transport underlay.
There are various other modes defined in the document, for example https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3 (called Enhanced mode with unchanged gNB GTP behavior)
In that case I see separation maintained and with a possibility of multiple SRv6 features, that can be applied in underlay as needed.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Jul 2018 16:41:14 +0000

Tom,

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

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2018 12:12 PM
To: Uma Chunduri <[email-masked]>
Cc: Arashmid Akhavain <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

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

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Jul 2018 16:51:40 +0000

Hi Pablo,

>As I already clarified in my previous email, the proposal of draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
Great. Thanks.
>As I already said in my previous email, we will clarify this in the next revision of the draft.
Sure.

Btw, you responded to Arash’s comments addressing me.

Some parts of the draft already maintained that independence with SRv6 features in underlay (for example Section 5.3).
In summary if you could address:

1.       Section 5.1 Traditional mode (Tom’s comment on terminology and IP-in-IP with no relation to SR?)

2.       Section 5.2 Enhanced mode. Here SR path steering features are used and not fully described what happens to TEID (as GTP is gone).

3.       And if TEID after GTP removal is encoded in each SID in the SRH or this is only specific to some PDU session as you indicated in your first email.

Thx!
--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 09:58:49 -0700

On Wed, Jul 18, 2018 at 9:31 AM, Uma Chunduri <[email-masked]> wrote:
> Hi Arashmid,
>
>
>
>
>
>>>[Uma]:  2 quick and minor corrections for the above first.“we encode the
>>> TEID into a SID”  è
>>> says “Note that in this mode the TEID is embedded in each SID.”
>
>>[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and
>> SGW and between SGW and PGW. For example for a UE with both internet access
>> and VoLTE, there are two GTP tunnels between the eNB and the SGW and two
>> other GTP tunnels between the SGW and the PGW.
>
>>We maintain this in traditional mode.
>
>
>
> [Uma2]: I am not questioning how each bearer get a different TEID or how
> separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW.
> It’s good this being planned to achieve in traditional mode. However, if
> this is seen as GTP replacement option, by moving TEID of the GTP header
> encoded into each SRv6 SID, is the unintended consequence is we are making 3GPP
> functionalities that are associated with TEID specific to one transport
> underlay.

Uma,

This might another case of nuanced terminology being used in the draft
that obscures what is happening and make things seem more complicated
than they actually are. In the case of traditional mode, there is no
segment routing header in the packet and hence there are not really
any SIDs. There is the destination IP address which presumably takes
the role of one SID in the segment routing architecture, however to
the rest of the world this is just the destination IP address. IP
addresses are quite large, so it's convenient to encode things like
TEIDs, VNIs in network virtualization, and other context for the
overlay in IPv6 addresses. This is a benefit of IP/IP encpasulation
(traditional SRV6 mode) over GTP since the overhead GTP and UDP
headers are eliminated. ILA takes encoding information in IPv6
addresses one step further to completely eliminate the need and
overhead for any encapsulation. It's true that these techniques impose
some requirements on the underlay that it's IPv6 and how addresses
need to be structured, but I don't see this to be significantly more
constraining than using a protocol specfiic UDP encapsulation.

Tom

>
> There are various other modes defined in the document, for example
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3
> (called Enhanced mode with unchanged gNB GTP behavior)
>
> In that case I see separation maintained and with a possibility of multiple
> SRv6 features, that can be applied in underlay as needed.
>
>
>
> --
>
> Uma C.
>
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 18 Jul 2018 18:17:12 +0000

Hi Uma,
You wrote:
“However, if this is seen as GTP replacement option, by moving TEID of the GTP header encoded into each SRv6 SID, the unintended consequence is we are making 3GPP functionalities that are associated with TEID specific to one transport underlay.”

[Arashmid] Let me try a more generalized version of your statement:

“Constructing SIDs based on a specific structure locks the transport underlay to the specific service for which the SID is constructed for.”

The SID although routable but is only local the segment end point. How its construct locks the underlying transport layer to only a single service?

From: Uma Chunduri
Sent: Wednesday, July 18, 2018 12:31 PM
To: Arashmid Akhavain <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Alberto Rodriguez Natal (natal) <[email-masked]>; [email-masked]
Subject: RE: Comment on SRv6-mobile-userplane

Hi Arashmid,

--
Uma C.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 18 Jul 2018 20:44:28 +0000

Uma,

Inline. [PC1]
(Thanks for the clear list of points to address. It does help.)

Cheers,
Pablo.

From: Uma Chunduri <[email-masked]>
Date: Wednesday, 18 July 2018 at 12:52
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, Arashmid Akhavain <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Alberto Rodriguez Natal (natal)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comment on SRv6-mobile-userplane

Hi Pablo,

Great. Thanks.
Sure.

PC1: Tom, please read https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3
PC1: It might be IP-in-IP as long as the inner header is not Ethernet or Unstructured PDUs (3GPP PDU types).
PC1: When its IP-in-IP the destination address is an SRv6 SID and is processed differently at the destination than an interface address. See 4.8-4.12 of draft-filsfils-srv6-network-programming.

2.      Section 5.2 Enhanced mode. Here SR path steering features are used

PC1: The enhanced mode exemplifies the case where a given provider wants to leverage SR for the overlay (as in Traditional mode but with session aggregation -see next note-; but also SP wants to leverage SR for underlay control and service programming.
PC1: In such example, the gNB can steer incoming traffic into an SR policy that contains SID for these three things. The benefit of this use-case is that the provider achieves end-to-end network slicing, spanning N3, N6, N9 as well as the transport network.
PC1: Notice that there might be different cases
1.- Overlay with session aggregation
2.- Overlay with session aggregation and underlay TE
3.- Overlay with session aggregation, underlay TE and service programming
4.- Overlay with session aggregation and service programming

and not fully described what happens to TEID (as GTP is gone).
PC1: Enhanced mode uses PDU session aggregation. There is not a single TEID per PDU Session. Instead, several PDU Sessions are aggregated. The set of sessions aggregated are still identified by the SID (in 5.2.1 corresponds to SID U2::1)
PC1: Each set of aggregated sessions uses a different SRv6 SID.
PC1: This is the main difference in between traditional mode and enhanced mode.
PC1: The aggregation is similar for the other proposals discussed in draft-bogineni-dmm-optimized-mobile-user-plane

PC1: In the traditional mode, the TEID for each PDU Session is encoded as an SRv6 SID. This can be done by two means, either by directly encoding the TEID in the SRv6 SID, or by using a unique SRv6 SID for each TEID (one-to-one mapping in between SRv6 SID and TEID). (feedback is welcome on preferred option)
PC1: In the enhanced mode, several PDU sessions are aggregated. All the set of aggregated sessions share the same SRv6 SID. A different set of aggregated sessions uses a different SRv6 SID.

Thx!
--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 15:57:36 -0700

On Wed, Jul 18, 2018 at 1:44 PM, Pablo Camarillo (pcamaril)
<[email-masked]> wrote:
> Cc: "[email-masked]" <[email-masked]>, "Alberto Rodriguez Natal (natal)"
> <[email-masked]>, "[email-masked]" <[email-masked]>
>>As I already clarified in my previous email, the proposal of
>> draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
>
> Great. Thanks.
>
> Some parts of the draft already maintained that independence with SRv6
> features in underlay (for example Section 5.3).
>
> PC1: Tom, please read
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3
>
Pablo,

I'm not sure that's relevant to discussion on an encapsulation
dataplane. SIDs are 128 bit values that are in the IPv6 address space,
and if a SID is place in a destination IPv6 address then it must be
routable to a node in the network. Wrt encapsulation, if it's any more
complex than that, then I'm missing something fundamental about
segment routing.

> Unstructured PDUs (3GPP PDU types).

If it's not IP-IP, then what is it? The draft states that in traditional mode:

"gNB only adds an outer IPv6 header with IPv6 DA U1::1."

This implies that foo over IP can be used if there is a protocol
number for it (e.g. IPv[46]/IPv6, GRE/IPv6, MPLS/IPv6, etc.). But what
does this mean in the case of unstructured PDUs? How are those
encapsulated?

Please clarify, or provide the reference to the exact format of
encapsulation protocols being used with SR.

> PC1: When its IP-in-IP the destination address is an SRv6 SID and is
> processed differently at the destination than an interface address. See
> 4.8-4.12 of draft-filsfils-srv6-network-programming.
>
Okay, but I don't see how the protocol is processed changes the fact
(at least that I think is a fact) that the solution is using IP-IP, or
maybe foo-over-IP in some cases as above, as the encapsulation and
that is the on-the-wire protocol in use.

Tom

> PC1: The enhanced mode exemplifies the case where a given provider wants to
> leverage SR for the overlay (as in Traditional mode but with session
> aggregation -see next note-; but also SP wants to leverage SR for underlay
> control and service programming.
>
> PC1: In such example, the gNB can steer incoming traffic into an SR policy
> that contains SID for these three things. The benefit of this use-case is
> that the provider achieves end-to-end network slicing, spanning N3, N6, N9
> as well as the transport network.
>
> PC1: Enhanced mode uses PDU session aggregation. There is not a single TEID
> per PDU Session. Instead, several PDU Sessions are aggregated. The set of
> sessions aggregated are still identified by the SID (in 5.2.1 corresponds to
> SID U2::1)
>
> PC1: The aggregation is similar for the other proposals discussed in
> 3.      And if TEID after GTP removal is encoded in each SID in the SRH or
> this is only specific to some PDU session as you indicated in your first
> email.
>
>
>
> PC1: In the traditional mode, the TEID for each PDU Session is encoded as an
> SRv6 SID. This can be done by two means, either by directly encoding the
> TEID in the SRv6 SID, or by using a unique SRv6 SID for each TEID
> (one-to-one mapping in between SRv6 SID and TEID). (feedback is welcome on
> preferred option)
>
> PC1: In the enhanced mode, several PDU sessions are aggregated. All the set
> of aggregated sessions share the same SRv6 SID. A different set of
> aggregated sessions uses a different SRv6 SID.
>
>
>
> Thx!
>
> --
>
> Uma C.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 20 Jul 2018 16:23:47 +0000

Tom, inline. [PC2]

Thanks,

Pablo.

On 18/07/2018, 18:57, "Tom Herbert" <[email-masked]> wrote:

    >1.      Section 5.1 Traditional mode (Tom’s comment on terminology and

    >IP-in-IP with no relation to SR?)

    Pablo,

    dataplane.

PC2:

A node may receive a packet with an SRv6 SID in the DA without an

   SRH.  In such case the packet should still be processed by the

   Segment Routing engine.

PC2: This is relevant understanding how the encapsulation dataplane operates IMO.

                      SIDs are 128 bit values that are in the IPv6 address space,

    segment routing.

    >PC1: It might be IP-in-IP as long as the inner header is not Ethernet or

    >Unstructured PDUs (3GPP PDU types).

PC2: If it is Ethernet or Unstructured, I strongly believe this is not IP-in-IP.

    encapsulated?

PC2: Unstructured PDUs uses T.Encaps.L2 and End.DX2 functions. IPv6/SRH(if more than one SID)/byte_stream. If its traditional mode -one SID- then IPv6/byte_stream.

PC2: The encapsulation protocol being used with SRv6 is defined in draft-ietf-6man-segment-routing-header which of course requires RFC8200.

PC2: The encapsulation/decapsulation procedures used in dmm-srv6-mobile-uplane are defined in draft-filsfils-srv6-network-programming.

PC2: It depends how you understand what is an encapsulation. To me this is the on-the-wire byte-codification and its processing.

PC2: In this particular case of Traditional mode with IP PDUs and encapsulation, the on-the-wire codification is IPinIP, since the SRH is not needed, while the processing is SRv6. If the UPF does not support SRv6, then it will not be able to work. Because of this, referring to it as IPinIP is misleading.

PC2: Let me try to give you an analogy. A external packet arrives to an ILA network. The original IPv6 DA is translated as per ILA. What is the packet? Is it an IP packet or is it an ILA packet? To me this is an ILA packet, because if the source and destination UPFs are not ILA capable the overlay does not work.

PC2: For this reason, I would not call the above SRv6 example IPinIP. It needs SRv6 on the UPFs, hence calling it IPinIP does not reflect the requirement of running SRv6 on the destination UPF -which in my opinion is considerable to highlight-.

    Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Jul 2018 10:13:29 -0700

> PC2: Let me try to give you an analogy. A external packet arrives to an ILA
> network. The original IPv6 DA is translated as per ILA. What is the packet?
> Is it an IP packet or is it an ILA packet? To me this is an ILA packet,
> because if the source and destination UPFs are not ILA capable the overlay
> does not work.
>
Pablo,

It is an IPv6 packet that has a destination address that is
interpreted with ILA semantics and the destination node. The format of
the packet is IPv6, the Ethertype is 0x86dd, and the packet is
compliant with the IPv6 protocol standard. Every intermediate device
in the path sees a plain IPv6 packet. The property that a packet with
an ILA address is indistinguishable on the wire from other IPv6 packet
is critical to ILA.

> PC2: For this reason, I would not call the above SRv6 example IPinIP. It
> needs SRv6 on the UPFs, hence calling it IPinIP does not reflect the
> requirement of running SRv6 on the destination UPF -which in my opinion is
> considerable to highlight-.

It's still not clear to me exactly what the wire format is of SRv6
traditional mode is. 5.5 of
draft-filsfils-spring-srv6-network-programming describes the
encapsulation operation as:

 1. push an IPv6 header with its own SRH (S3, S2; SL=2)
 2.   set outer IPv6 SA = T and outer IPv6 DA = S1
 3.   set outer payload length, traffic class and flow label     ;; Ref1
 4.   update the Next-Header value                               ;; Ref1
 5.   decrement inner Hop Limit or TTL                           ;; Ref1
 6.   forward along the shortest path to S1

Step #4 is ambiguous. It doesn't indicate what the Next-Header value
needs to be updated to. Also, it's not really clear which Next-Header
field is being updated (there could be an inner value and an outer
value). I infer that it is the Next-Header value in the outer IPv6
header and that it is set to either 0x04 or 0x29 if the inner packet
is IPv4 or IPv6 respectively. Assuming that all other fields are set
normally for IPv6, then the derived packet has the format of a simple
IP-in-IPv6 encapsulation and that's that how it will be seen on the
wire by intermediate nodes (which similar to case of ILA I think is a
good property to have).

Is my inference correct?

Tom