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

[Tom Herbert]

On Wed, Jul 18, 2018 at 1:44 PM, Pablo Camarillo (pcamaril)
 wrote:
> Uma,
>
>
>
> Inline. [PC1]
>
> (Thanks for the clear list of points to address. It does help.)
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> From: Uma Chunduri 
> Date: Wednesday, 18 July 2018 at 12:52
> To: "Pablo Camarillo (pcamaril)" , Arashmid Akhavain
> 
> Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)"
> , "spr...@ietf.org" 
> Subject: RE: Comment on SRv6-mobile-userplane
>
>
>
> 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?)
>
>
>
> 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.

> PC1: It might be IP-in-IP as long as the inner header is not Ethernet or
> 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

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

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Pablo Camarillo (pcamaril)]

Uma,

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

Cheers,
Pablo.

From: Uma Chunduri 
Date: Wednesday, 18 July 2018 at 12:52
To: "Pablo Camarillo (pcamaril)" , Arashmid Akhavain 

Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)" 
, "spr...@ietf.org" 
Subject: RE: Comment on SRv6-mobile-userplane

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?)

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


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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Arashmid Akhavain]

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 ; Pablo Camarillo 
(pcamaril) 
Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) ; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

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.



>[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, 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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Tom Herbert]

On Wed, Jul 18, 2018 at 9:31 AM, Uma Chunduri  wrote:
> 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.
>
>
>
>
>
>
>
>>[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.
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Tom,

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


-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: Wednesday, July 18, 2018 12:12 PM
To: Uma Chunduri 
Cc: Arashmid Akhavain ; Pablo Camarillo 
(pcamaril) ; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri  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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

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.



>[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, 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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Pablo Camarillo (pcamaril)]

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 
Date: Wednesday, 18 July 2018 at 11:50
To: Arashmid Akhavain , "Pablo Camarillo 
(pcamaril)" 
Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)" 
, "spr...@ietf.org" 
Subject: RE: Comment on SRv6-mobile-userplane

Arash,


In-line [Uma]:

--
Uma C.

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



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.

[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 transport to convert to SRv6?

[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) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

[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:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
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 

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

[Arashmid Akhavain]

Hi Uma,

Please see my replies inline [Arashmid]

Cheers,
Arashmid

From: Uma Chunduri
Sent: Wednesday, July 18, 2018 11:50 AM
To: Arashmid Akhavain ; Pablo Camarillo 
(pcamaril) 
Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) ; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

Arash,


In-line [Uma]:

--
Uma C.

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

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.

[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)

[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

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

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

[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
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

[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:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
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 

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

[Tom Herbert]

On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri  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.
"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

> --
> Uma C.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Tom Herbert]

On Wed, Jul 18, 2018 at 8:44 AM, Pablo Camarillo (pcamaril)
 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

> Cheers,
> Pablo.
>
> On 18/07/2018, 10:37, "Tom Herbert"  wrote:
>
> 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.
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Arash,


In-line [Uma]:

--
Uma C.

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


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.

[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 transport to convert to SRv6?

[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) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

[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:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
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 

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

[Pablo Camarillo (pcamaril)]

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"  wrote:

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.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Arashmid Akhavain]

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:t...@quantonium.net] 
Sent: Wednesday, July 18, 2018 10:38 AM
To: Arashmid Akhavain 
Cc: Uma Chunduri ; Pablo Camarillo (pcamaril) 
; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain 
 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

>
>
>
> Cheers,
>
> Arash
>
>
>
> From: Uma Chunduri
> Sent: Tuesday, July 17, 2018 3:10 PM
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org; Arashmid Akhavain ; 
> Alberto Rodriguez Natal (natal) ; spr...@ietf.org
> Subject: RE: Comment on SRv6-mobile-userplane
>
>
>
> [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:pcama...@cisco.com]
> Sent: Tuesday, July 17, 2018 11:25 AM
> To: Uma Chunduri 
> Cc: dmm@ietf.org; Arashmid Akhavain ; 
> Alberto Rodriguez Natal (natal) 
> 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#secti
> on-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-p
> lane-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 
> 

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

[Tom Herbert]

On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain
 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

>
>
>
> Cheers,
>
> Arash
>
>
>
> From: Uma Chunduri
> Sent: Tuesday, July 17, 2018 3:10 PM
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto
> Rodriguez Natal (natal) ; spr...@ietf.org
> Subject: RE: Comment on SRv6-mobile-userplane
>
>
>
> [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:pcama...@cisco.com]
> Sent: Tuesday, July 17, 2018 11:25 AM
> To: Uma Chunduri 
> Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto
> Rodriguez Natal (natal) 
> 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, 

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

[Arashmid Akhavain]

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) 
Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto 
Rodriguez Natal (natal) ; spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane

[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:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
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.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm