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

[Tom Herbert]

> 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




>
>
>
> Tom
>
>
>
>

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

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

[Pablo Camarillo (pcamaril)]

Tom, inline. [PC2]



Thanks,

Pablo.



On 18/07/2018, 18:57, "Tom Herbert"  wrote:



>

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



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,

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:



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



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



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.



Please clarify, or provide the reference to the exact format of

encapsulation protocols being used with SR.



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.



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



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




___
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 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 i

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

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

[Uma Chunduri]

[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, thanks for your consideration.

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

[DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

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

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.

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.

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