Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Hello Tom,

Thank you for your feedback.

> ...snip...

> - Pick a handful of representative formats, maybe something like five,
> and do an an equivalent comparison. For instance, it should be easy to
> deduce the equivalent packet formats for traditional mode in SR that
> are needed for GTP and ILA.

I want to do. But I’d keep them until it is clear those are truly not deployed 
in rest of world.
When it’s clear I remove them.


> - Don't count the outer Ethernet header as overhead. It's always there
> and not counted against MTU.

When it comes to overhead, it affects not only for MTU size, but also consumed 
bandwidth.
In that perspective, I’d keep Ethernet header in it. Or, do you want to resume 
the discussion of ‘killing ethernet’ thread in ietf at ietf list?


> - Don't use colors to highlight differences. The use of 'red' in the
> spreadsheet is subjective and also confusing in itself. For instance,
> I don't understand why 'No SRH' (line 1) is black but basic GTP over
> IPv4 (line 5) is red when they are both reported to have 58 bytes of
> overhead.

This is comparison of overhead size against SRv6 Mobile User Plane so that SRv6 
is base and no need to be colored.
I can change red to other color.


> - Is the math is off? For instance, in line 1 the overhead is an IPv6
> header and and Ethernet header, shouldn't that be 40+14=54 instead of
> 58?

FCS counted.

Cheers,
--satoru


> 
> Tom
> 
> 
> 
> 
> 
>> 
>>> 
>>> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced 
>>> mode)? In GTPU the QFI/RQI markings are carried in a GTPU extension header, 
>>> defined as a container. Please refer the following documents for details
>> 
>> Thank you for those latest references! Actually I was seeking them from last 
>> CT4 meeting folder. ;-)
>> 
>> And yes, we still leave it at this time since defining 3GPP specific 
>> extension headers and messages should be up to 3GPP decision.
>> We don’t want to violate that responsibility. Nevertheless, in case that 
>> those GTP-U extension header and messages are carried as its encoding, TLV 
>> in SRH would work to do that with just one or few code points to 3GPP which 
>> looks not big deal. If you are interested, it would be nice if we can write 
>> a draft with that idea with you and John.
>> 
>> Cheers,
>> --satoru
>> 
>>> 
>>> Incoming LS from RAN3 to CT4: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip
>>> 
>>> Corresponding agreed CR in CT4: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip
>>> 
>>> LS out from CT4 to RAN3: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
>>> 
>>> Thanks
>>> Sridhar
>>> 
>>> -Original Message-
>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>>> Sent: Tuesday, March 13, 2018 6:55 AM
>>> To: John Kaippallimalil <john.kaippallima...@huawei.com>
>>> Cc: dmm <dmm@ietf.org>
>>> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>> 
>>> John,
>>> 
>>>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
>>>> 
>>>> A few questions for clarification:
>>>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>>>> an SRH..."
>>>> In this case the outer IPv6 address representing a SID would contain a 
>>>> TEID.
>>>> So for 1000 PDU sessions - would there be as many IPv6 addresses
>>>> (representing SIDs/TEID in the outer header)
>>> 
>>> Right. It is not limited but in a typical case given that a /64 per node 
>>> for the SID space which allows each node allocate a SID per session basis.
>>> 
>>> 
>>>> 
>>>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on
>>>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other 
>>>> fns - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to 
>>>> chain functions along the path to UPF1,
>>>> or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>>>> upto the anchor UPF2.
>>> 
>>> Please see the section 5.2.1 of packet flow on uplink.
>>> We assume that there’s no UPF1 along the path in the diagram.
>>> 
>>> 
>>>> 
>>

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[John Kaippallimalil]

Satoru,
Thanks for the responses.

In the Enhanced mode - section 5.2, it is still not clear (if or) how multiple 
UPFs on path would be programmed. 
23.501, 5.6.4 discusses about a single PDU session with multiple PDU Session 
anchors. 
What would the SR path look like:  gNB --> UPF1 --> UPF2 (2 segments), or would 
UPF1 fns (ULCL/branching point) be somehow programmed at the source (gNB/UPF2):
- how would filters at ULCL UPF be programmed to steer traffic to local DN. 
- similarly branching point UPF for traffic measurement, charging, LI, 
multi-homing.

Would be good to address it in the draft.

John



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, March 13, 2018 10:09 AM
To: Satoru Matsushima <satoru.matsush...@gmail.com>
Cc: dmm <dmm@ietf.org>
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

On Mon, Mar 12, 2018 at 10:57 PM, Satoru Matsushima 
<satoru.matsush...@gmail.com> wrote:
> Dear Sridhar,
>
> It’s nice to see you in DMM list as well. :-)
>
>> [...snip...]
>
>
>> 1. Section 5.2.2 of the draft says,
>>
>> UPF2_in : (Z,A)  -> UPF2 maps the flow w/
>>SID list <C1,S1, gNB>
>>
>> When the packet arrives to the UPF2, the UPF2 will map that
>>   particular flow into a UE session.
>>
>> Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
>> after each mobility, the information regarding current gNB is signaled / 
>> programmed till the UPF2 (which could be the PDU session anchor UPF)?
>
> Right. It’s equivalent with GTP-U case where there’s no N9 along the path.
> One significant difference between GTP-U and enhanced mode is that the 
> packets of PDU sessions which belong to a same SR policy will use same set of 
> SIDs in the header.
>
>
>>
>> 2. For traditional mode (basic mode), could you please elaborate on the MTU 
>> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer 
>> IPv4 header + 8 octets UDP header + 12 octets GTPU header + Extension header 
>> for QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying 
>> QFI (this part is not clear - see my next question). In your blog 
>> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
>>  I noticed in Fig.1 the MPLS / TE headers included in calculation. So does 
>> the MTU overhead saving talked about for SRv6 assume that underlay TE 
>> technologies are replaced? It is not clear from the draft. If there are any 
>> other drafts that provide a clear calculation on the MTU savings, could you 
>> please point to them?
>
> I hope that the following spreadsheet helps for that purpose. I’ve updated it 
> align to the latest draft after I shared it in last month.
>
> https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0
> VZbmwzZJNVh0g/edit?usp=sharing
>
> As the draft says that traditional mode is as same as existing user plane 
> protocol, it is also equivalent in terms of overhead size.
> You can find that both GTP-U and traditional mode of SRv6 cost 58 bytes as 
> the overhead.
>
Satoru,

This spreadsheet is really confusing and way too much information. For 
instance, there's a 135 variants of GTP-U! I sincerely doubt all of those 
variants are equally relevant and used. Similarly, I don't understand why 
there's 67 variants of ILA that would be needed. IMO, this is making those 
protocols look much more complicated than they actually are.

It would be nice to have a good summary and fair comparison of the overheads of 
these various protocols. Here are some suggestions to clean this up:

- Pick a handful of representative formats, maybe something like five, and do 
an an equivalent comparison. For instance, it should be easy to deduce the 
equivalent packet formats for traditional mode in SR that are needed for GTP 
and ILA.
- Don't count the outer Ethernet header as overhead. It's always there and not 
counted against MTU.
- Don't use colors to highlight differences. The use of 'red' in the 
spreadsheet is subjective and also confusing in itself. For instance, I don't 
understand why 'No SRH' (line 1) is black but basic GTP over
IPv4 (line 5) is red when they are both reported to have 58 bytes of overhead.
- Is the math is off? For instance, in line 1 the overhead is an IPv6 header 
and and Ethernet header, shouldn't that be 40+14=54 instead of 58?

Tom





>
>>
>> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced 
>> mode)? In GTPU the QFI/RQI markings are carried in a GTPU extension 
>> header, defined as a container. Please refer the following documents 
>>

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Tom Herbert]

4/TSGCT4_83_Montreal/Docs/C4-182246.zip
>>
>> LS out from CT4 to RAN3: 
>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
>>
>> Thanks
>> Sridhar
>>
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>> Sent: Tuesday, March 13, 2018 6:55 AM
>> To: John Kaippallimalil <john.kaippallima...@huawei.com>
>> Cc: dmm <dmm@ietf.org>
>> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>
>> John,
>>
>>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
>>>
>>> A few questions for clarification:
>>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>>> an SRH..."
>>> In this case the outer IPv6 address representing a SID would contain a TEID.
>>> So for 1000 PDU sessions - would there be as many IPv6 addresses
>>> (representing SIDs/TEID in the outer header)
>>
>> Right. It is not limited but in a typical case given that a /64 per node for 
>> the SID space which allows each node allocate a SID per session basis.
>>
>>
>>>
>>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on
>>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns 
>>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to 
>>> chain functions along the path to UPF1,
>>>  or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>>> upto the anchor UPF2.
>>
>> Please see the section 5.2.1 of packet flow on uplink.
>> We assume that there’s no UPF1 along the path in the diagram.
>>
>>
>>>
>>> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering 
>>> and service chaining ..."
>>> 3GPP service chaining is at N6 interface, but in this case, is the policy 
>>> for traffic steering implemented at the N3  interface.
>>> Would PCF/SMF provision this at gNB.
>>
>> When it comes to enhanced mode for control-plane side, it may literally be 
>> enhanced.
>> But at this revision of the draft, it is assumed that gNB is capable to 
>> resolve SR policy from remote endpoint address of tunnel to SIDs list while 
>> N2 is unchanged and kept as it is.
>>
>> Cheers,
>> --satoru
>>
>>
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> -Original Message-
>>> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
>>> Sent: Mittwoch, 7. März 2018 12:23
>>> To: Marco Liebsch
>>> Cc: dmm
>>> Subject: Re: [DMM] Fwd: I-D Action:
>>> draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>>
>>> Marco,
>>>
>>>> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
>>>>
>>>> Satoru,
>>>>
>>>> since I read this at different places, let me ask one clarifying question 
>>>> about the stateless motivation:
>>>>
>>>> I see that for SRv6 you may not need a state at the egress (at least
>>>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need
>>>> a state at both edges of the communication since the DL egress serves as 
>>>> uplink ingress, correct?
>>>
>>> 2x unidirectional tunnels to form bidirectional paths require 4 states in 
>>> total at both the ingress and egress.
>>> In SR case it requires just 2 states at the ingresses for both directions.
>>>
>>> Cheers,
>>> --satoru
>>>
>>>
>>>
>>>>
>>>> marco
>>>>
>>>>
>>>> -Original Message-
>>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru
>>>> Matsushima
>>>> Sent: Dienstag, 6. März 2018 17:23
>>>> To: Tom Herbert
>>>> Cc: dmm
>>>> Subject: Re: [DMM] Fwd: I-D Action:
>>>> draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>>>
>>>> Hello Tom,
>>>>
>>>>>> A Big progress is that the draft supports interworking with GTP
>>>>>> over
>>>>>> IPv6 in addition to GTP over IPv4.
>>>>>> And we have made change SRv6 function to IPv6 encapsulation with
>>>>>> SRH instead of SRH insertion by default.
>>>>>>
>>>>>
>>

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Dear Sridhar,

It’s nice to see you in DMM list as well. :-)

> [...snip...]


> 1. Section 5.2.2 of the draft says,
> 
> UPF2_in : (Z,A)  -> UPF2 maps the flow w/
>SID list <C1,S1, gNB> 
> 
> When the packet arrives to the UPF2, the UPF2 will map that
>   particular flow into a UE session.
> 
> Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
> after each mobility, the information regarding current gNB is signaled / 
> programmed till the UPF2 (which could be the PDU session anchor UPF)?

Right. It’s equivalent with GTP-U case where there’s no N9 along the path.
One significant difference between GTP-U and enhanced mode is that the packets 
of PDU sessions which belong to a same SR policy will use same set of SIDs in 
the header.


> 
> 2. For traditional mode (basic mode), could you please elaborate on the MTU 
> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
> header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
> QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
> (this part is not clear - see my next question). In your blog 
> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
>  I noticed in Fig.1 the MPLS / TE headers included in calculation. So does 
> the MTU overhead saving talked about for SRv6 assume that underlay TE 
> technologies are replaced? It is not clear from the draft. If there are any 
> other drafts that provide a clear calculation on the MTU savings, could you 
> please point to them?

I hope that the following spreadsheet helps for that purpose. I’ve updated it 
align to the latest draft after I shared it in last month. 

https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing

As the draft says that traditional mode is as same as existing user plane 
protocol, it is also equivalent in terms of overhead size.
You can find that both GTP-U and traditional mode of SRv6 cost 58 bytes as the 
overhead.


> 
> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? 
> In GTPU the QFI/RQI markings are carried in a GTPU extension header, defined 
> as a container. Please refer the following documents for details

Thank you for those latest references! Actually I was seeking them from last 
CT4 meeting folder. ;-)

And yes, we still leave it at this time since defining 3GPP specific extension 
headers and messages should be up to 3GPP decision. 
We don’t want to violate that responsibility. Nevertheless, in case that those 
GTP-U extension header and messages are carried as its encoding, TLV in SRH 
would work to do that with just one or few code points to 3GPP which looks not 
big deal. If you are interested, it would be nice if we can write a draft with 
that idea with you and John.

Cheers,
--satoru

> 
> Incoming LS from RAN3 to CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip
> 
> Corresponding agreed CR in CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip
> 
> LS out from CT4 to RAN3: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
> 
> Thanks
> Sridhar
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, March 13, 2018 6:55 AM
> To: John Kaippallimalil <john.kaippallima...@huawei.com>
> Cc: dmm <dmm@ietf.org>
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> John,
> 
>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
>> 
>> A few questions for clarification:
>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>> an SRH..."
>> In this case the outer IPv6 address representing a SID would contain a TEID.
>> So for 1000 PDU sessions - would there be as many IPv6 addresses 
>> (representing SIDs/TEID in the outer header)
> 
> Right. It is not limited but in a typical case given that a /64 per node for 
> the SID space which allows each node allocate a SID per session basis.
> 
> 
>> 
>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on 
>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns 
>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain 
>> functions along the path to UPF1,
>>  or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>> upto the anchor UPF2. 
> 
> Please see the section 5.2.1 of packet f

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Sridhar Bhaskaran]

Dear Satoru,

I am Sridhar Bhaskaran - 3GPP CT4 delegate. In addition to John's questions, I 
have few more questions for clarification.

1. Section 5.2.2 of the draft says,

UPF2_in : (Z,A)  -> UPF2 maps the flow w/
SID list <C1,S1, gNB> 

When the packet arrives to the UPF2, the UPF2 will map that
   particular flow into a UE session.

Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
after each mobility, the information regarding current gNB is signaled / 
programmed till the UPF2 (which could be the PDU session anchor UPF)?

2. For traditional mode (basic mode), could you please elaborate on the MTU 
overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
(this part is not clear - see my next question). In your blog 
https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
 I noticed in Fig.1 the MPLS / TE headers included in calculation. So does the 
MTU overhead saving talked about for SRv6 assume that underlay TE technologies 
are replaced? It is not clear from the draft. If there are any other drafts 
that provide a clear calculation on the MTU savings, could you please point to 
them?

3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? In 
GTPU the QFI/RQI markings are carried in a GTPU extension header, defined as a 
container. Please refer the following documents for details

Incoming LS from RAN3 to CT4: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip

Corresponding agreed CR in CT4: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip

LS out from CT4 to RAN3: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
 
Thanks
Sridhar

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Tuesday, March 13, 2018 6:55 AM
To: John Kaippallimalil <john.kaippallima...@huawei.com>
Cc: dmm <dmm@ietf.org>
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

John,

> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
> 
> A few questions for clarification:
> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
> SRH..."
> In this case the outer IPv6 address representing a SID would contain a TEID.
> So for 1000 PDU sessions - would there be as many IPv6 addresses 
> (representing SIDs/TEID in the outer header)

Right. It is not limited but in a typical case given that a /64 per node for 
the SID space which allows each node allocate a SID per session basis.


> 
> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on 
> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - 
> S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain 
> functions along the path to UPF1,
>   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
> upto the anchor UPF2. 

Please see the section 5.2.1 of packet flow on uplink.
We assume that there’s no UPF1 along the path in the diagram.


> 
> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
> service chaining ..."
> 3GPP service chaining is at N6 interface, but in this case, is the policy for 
> traffic steering implemented at the N3  interface.
> Would PCF/SMF provision this at gNB.

When it comes to enhanced mode for control-plane side, it may literally be 
enhanced.
But at this revision of the draft, it is assumed that gNB is capable to resolve 
SR policy from remote endpoint address of tunnel to SIDs list while N2 is 
unchanged and kept as it is.

Cheers,
--satoru


> 
> Thanks,
> John
> 
> 
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Mittwoch, 7. März 2018 12:23
> To: Marco Liebsch
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: 
> draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Marco,
> 
>> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
>> 
>> Satoru,
>> 
>> since I read this at different places, let me ask one clarifying question 
>> about the stateless motivation: 
>> 
>> I see that for SRv6 you may not need a state at the egress (at least 
>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need 
>> a state at both edges of the communication since the DL egress serves as 
>> uplink ingress, correct?
> 
> 2x unidirectional tunnels to form bidirectional paths 

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

John,

> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
> 
> A few questions for clarification:
> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
> SRH..."
> In this case the outer IPv6 address representing a SID would contain a TEID.
> So for 1000 PDU sessions - would there be as many IPv6 addresses 
> (representing SIDs/TEID in the outer header)

Right. It is not limited but in a typical case given that a /64 per node for 
the SID space which allows each node allocate a SID per session basis.


> 
> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on path (gNB 
> --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - S1, C1)
> Would the SR path at gNB (uplink) be (a) the list of SIDs to chain functions 
> along the path to UPF1,
>   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
> upto the anchor UPF2. 

Please see the section 5.2.1 of packet flow on uplink.
We assume that there’s no UPF1 along the path in the diagram.


> 
> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
> service chaining ..."
> 3GPP service chaining is at N6 interface, but in this case, is the policy for 
> traffic steering implemented at the N3  interface.
> Would PCF/SMF provision this at gNB.

When it comes to enhanced mode for control-plane side, it may literally be 
enhanced.
But at this revision of the draft, it is assumed that gNB is capable to resolve 
SR policy from remote endpoint address of tunnel to SIDs list while N2 is 
unchanged and kept as it is.

Cheers,
--satoru


> 
> Thanks,
> John
> 
> 
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Mittwoch, 7. März 2018 12:23
> To: Marco Liebsch
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Marco,
> 
>> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
>> 
>> Satoru,
>> 
>> since I read this at different places, let me ask one clarifying question 
>> about the stateless motivation: 
>> 
>> I see that for SRv6 you may not need a state at the egress (at least 
>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
>> state at both edges of the communication since the DL egress serves as 
>> uplink ingress, correct?
> 
> 2x unidirectional tunnels to form bidirectional paths require 4 states in 
> total at both the ingress and egress.
> In SR case it requires just 2 states at the ingresses for both directions.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 
>> marco
>> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>> Sent: Dienstag, 6. März 2018 17:23
>> To: Tom Herbert
>> Cc: dmm
>> Subject: Re: [DMM] Fwd: I-D Action: 
>> draft-ietf-dmm-srv6-mobile-uplane-01.txt
>> 
>> Hello Tom,
>> 
>>>> A Big progress is that the draft supports interworking with GTP over
>>>> IPv6 in addition to GTP over IPv4.
>>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>>> instead of SRH insertion by default.
>>>> 
>>> 
>>> Hi Satoru,
>>> 
>>> If there are no intermediate hops od SIDs being set when 
>>> encapsulating would a SR header still be needed or could this just be 
>>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>>> that ILA might then be used to completely eliminate the encapsulation 
>>> overhead.
>> 
>> I think you’re right. You would find that case in the draft as ‘Traditional 
>> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
>> is also equivalent with that mode. In addition, this draft introduces 
>> ‘Enhance Mode’ to cover more advanced cases.
>> 
>> IMO SR is designed not to maintain path states except at an ingress node. So 
>> the packet need to preserve original DA in the header that keep the egress 
>> node in stateless. It would be great if ILA is designed in the similar 
>> concept as well.
>> 
>> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
>> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
>> choose which one need to be prioritized would depend on each deployment case 
>> in operators IMO.
>> 
>> Cheers,
>> --satoru
>> ___
>> 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

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

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[John Kaippallimalil]

A few questions for clarification:
1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
SRH..."
In this case the outer IPv6 address representing a SID would contain a TEID.
So for 1000 PDU sessions - would there be as many IPv6 addresses (representing 
SIDs/TEID in the outer header)

2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on path (gNB 
--> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - S1, C1)
Would the SR path at gNB (uplink) be (a) the list of SIDs to chain functions 
along the path to UPF1,
   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
upto the anchor UPF2. 

3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
service chaining ..."
3GPP service chaining is at N6 interface, but in this case, is the policy for 
traffic steering implemented at the N3  interface.
 Would PCF/SMF provision this at gNB.

Thanks,
John



-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Mittwoch, 7. März 2018 12:23
To: Marco Liebsch
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Marco,

> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
> 
> Satoru,
> 
> since I read this at different places, let me ask one clarifying question 
> about the stateless motivation: 
> 
> I see that for SRv6 you may not need a state at the egress (at least 
> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
> state at both edges of the communication since the DL egress serves as uplink 
> ingress, correct?

2x unidirectional tunnels to form bidirectional paths require 4 states in total 
at both the ingress and egress.
In SR case it requires just 2 states at the ingresses for both directions.

Cheers,
--satoru



> 
> marco
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Dienstag, 6. März 2018 17:23
> To: Tom Herbert
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: 
> draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Hello Tom,
> 
>>> A Big progress is that the draft supports interworking with GTP over
>>> IPv6 in addition to GTP over IPv4.
>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>> instead of SRH insertion by default.
>>> 
>> 
>> Hi Satoru,
>> 
>> If there are no intermediate hops od SIDs being set when 
>> encapsulating would a SR header still be needed or could this just be 
>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>> that ILA might then be used to completely eliminate the encapsulation 
>> overhead.
> 
> I think you’re right. You would find that case in the draft as ‘Traditional 
> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
> is also equivalent with that mode. In addition, this draft introduces 
> ‘Enhance Mode’ to cover more advanced cases.
> 
> IMO SR is designed not to maintain path states except at an ingress node. So 
> the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
> 
> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
> choose which one need to be prioritized would depend on each deployment case 
> in operators IMO.
> 
> Cheers,
> --satoru
> ___
> 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
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Tom Herbert]

On Wed, Mar 7, 2018 at 10:13 AM, Pablo Camarillo (pcamaril)
 wrote:
> Tom,
>
> Your understanding is correct: in the traditional mode there is no pushed SRH
> •   Less MTU overhead than GTP in traditional mode.
> •   In enhanced mode with underlay TE with SLA bandwidth with stateless 
> service chaining we use the SRH.
>
Hi Pablo,

I see. So in traditional mode this would just use simple IPIP
encapsulation in path towards a mobile node. Conceptually, ILA could
be applied int his case to eliminate the encapsulation overhead. That
is an interesting possibility, although since SR is not involved in
traditional mode the association with SR in the name might be a bit
confusing to the reader ;-).

I haven't completely thought through possibility of using ILA in
enhanced mode, but it conceivable that ILA could be used on
segments.For instance, the SIDs themselves might be virtual nodes, and
ILA could be used to map them in to real devices at each hop.

> Any solution other than SRv6 requires an independent layer for underlay TE(1) 
> and service chaining(2)
> •   Do you contemplate combining ILA with RSVP for 1 and NSH for 2 
> causing explosion of state in the underlay??

Intent is that ILA can work with NSH, network, slices or other L2
mechanisms. ILA is confined to networks, so it doesn't make any
requirements of lower layers, but is hould be able to work with them.

The state we are concerned with in ILA is the number of
identifier/locator mappings in the network. I believe that is a common
problem across most proposals.

> •   What is the overhead in ILA when supporting IPv4 or Ethernet PDU 
> sessions? It must be greater, right?
>
Yes, it is greater. It requires a protocol translation where 20 bytes
is expanded to 40 bytes. In itself it might just be as easy to
encapsulate, however in the virtualization use case there are cases
where protocol translation is quite valuable since it allows us to
create a globally routable address for a node in a tenant network that
may be using private IPv4 address (e.g. RFC1918).

Tom

> Thanks,
> Pablo.
>
> On 06/03/2018, 17:23, "dmm on behalf of Satoru Matsushima" 
>  wrote:
>
> Hello Tom,
>
> >> A Big progress is that the draft supports interworking with GTP over 
> IPv6 in
> >> addition to GTP over IPv4.
> >> And we have made change SRv6 function to IPv6 encapsulation with SRH 
> instead
> >> of SRH insertion by default.
> >>
> >
> > Hi Satoru,
> >
> > If there are no intermediate hops od SIDs being set when encapsulating
> > would a SR header still be needed or could this just be simple IP in
> > IP encpasulation?  If is no SR header then it's possible that ILA
> > might then be used to completely eliminate the encapsulation overhead.
>
> I think you’re right. You would find that case in the draft as 
> ‘Traditional Mode’ which is equivalent with traditional GTP-U case. You seem 
> you say ILA is also equivalent with that mode. In addition, this draft 
> introduces ‘Enhance Mode’ to cover more advanced cases.
>
> IMO SR is designed not to maintain path states except at an ingress node. 
> So the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
>
> If it’s not, it looks a kind of tradeoff, between reducing the overhead 
> and keeping the statelessness. It’s not apple-to-apple comparison. To decide 
> to choose which one need to be prioritized would depend on each deployment 
> case in operators IMO.
>
> Cheers,
> --satoru
> ___
> 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Marco Liebsch]

That matches my view, Satoru. Still both edges require states hence the 
associated node has to have an
interface to the control plane. But I agree that in total fewer states are 
required because egress
does not need a host state for decap/re-write and removing the SRv6 header at 
egress is standard behavior. 

marco


-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Mittwoch, 7. März 2018 12:23
To: Marco Liebsch
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Marco,

> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
> 
> Satoru,
> 
> since I read this at different places, let me ask one clarifying question 
> about the stateless motivation: 
> 
> I see that for SRv6 you may not need a state at the egress (at least 
> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
> state at both edges of the communication since the DL egress serves as uplink 
> ingress, correct?

2x unidirectional tunnels to form bidirectional paths require 4 states in total 
at both the ingress and egress.
In SR case it requires just 2 states at the ingresses for both directions.

Cheers,
--satoru



> 
> marco
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Dienstag, 6. März 2018 17:23
> To: Tom Herbert
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: 
> draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Hello Tom,
> 
>>> A Big progress is that the draft supports interworking with GTP over
>>> IPv6 in addition to GTP over IPv4.
>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>> instead of SRH insertion by default.
>>> 
>> 
>> Hi Satoru,
>> 
>> If there are no intermediate hops od SIDs being set when 
>> encapsulating would a SR header still be needed or could this just be 
>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>> that ILA might then be used to completely eliminate the encapsulation 
>> overhead.
> 
> I think you’re right. You would find that case in the draft as ‘Traditional 
> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
> is also equivalent with that mode. In addition, this draft introduces 
> ‘Enhance Mode’ to cover more advanced cases.
> 
> IMO SR is designed not to maintain path states except at an ingress node. So 
> the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
> 
> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
> choose which one need to be prioritized would depend on each deployment case 
> in operators IMO.
> 
> Cheers,
> --satoru
> ___
> 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Marco,

> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
> 
> Satoru,
> 
> since I read this at different places, let me ask one clarifying question 
> about the stateless motivation: 
> 
> I see that for SRv6 you may not need a state at the egress (at least not for 
> traffic forwarding) but for
> Uplink/Downlink (UL/DL) you need a state at both edges of the communication 
> since the DL egress
> serves as uplink ingress, correct?

2x unidirectional tunnels to form bidirectional paths require 4 states in total 
at both the ingress and egress.
In SR case it requires just 2 states at the ingresses for both directions.

Cheers,
--satoru



> 
> marco
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Dienstag, 6. März 2018 17:23
> To: Tom Herbert
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Hello Tom,
> 
>>> A Big progress is that the draft supports interworking with GTP over 
>>> IPv6 in addition to GTP over IPv4.
>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>> instead of SRH insertion by default.
>>> 
>> 
>> Hi Satoru,
>> 
>> If there are no intermediate hops od SIDs being set when encapsulating 
>> would a SR header still be needed or could this just be simple IP in 
>> IP encpasulation?  If is no SR header then it's possible that ILA 
>> might then be used to completely eliminate the encapsulation overhead.
> 
> I think you’re right. You would find that case in the draft as ‘Traditional 
> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
> is also equivalent with that mode. In addition, this draft introduces 
> ‘Enhance Mode’ to cover more advanced cases.
> 
> IMO SR is designed not to maintain path states except at an ingress node. So 
> the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
> 
> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
> choose which one need to be prioritized would depend on each deployment case 
> in operators IMO.
> 
> Cheers,
> --satoru
> ___
> 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Marco Liebsch]

Satoru,

since I read this at different places, let me ask one clarifying question about 
the stateless motivation: 

I see that for SRv6 you may not need a state at the egress (at least not for 
traffic forwarding) but for
Uplink/Downlink (UL/DL) you need a state at both edges of the communication 
since the DL egress
serves as uplink ingress, correct?

marco


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Dienstag, 6. März 2018 17:23
To: Tom Herbert
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Hello Tom,

>> A Big progress is that the draft supports interworking with GTP over 
>> IPv6 in addition to GTP over IPv4.
>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>> instead of SRH insertion by default.
>> 
> 
> Hi Satoru,
> 
> If there are no intermediate hops od SIDs being set when encapsulating 
> would a SR header still be needed or could this just be simple IP in 
> IP encpasulation?  If is no SR header then it's possible that ILA 
> might then be used to completely eliminate the encapsulation overhead.

I think you’re right. You would find that case in the draft as ‘Traditional 
Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA is 
also equivalent with that mode. In addition, this draft introduces ‘Enhance 
Mode’ to cover more advanced cases.

IMO SR is designed not to maintain path states except at an ingress node. So 
the packet need to preserve original DA in the header that keep the egress node 
in stateless. It would be great if ILA is designed in the similar concept as 
well.

If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
choose which one need to be prioritized would depend on each deployment case in 
operators IMO.

Cheers,
--satoru
___
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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Tom Herbert]

On Tue, Mar 6, 2018 at 11:29 AM, Pablo Camarillo (pcamaril)
<pcama...@cisco.com> wrote:
> Tom,
>
>
>
> Re: your comment on EH insertion.
>
>
>
> This point is not applicable; a new version of srv6-mobile-uplane
> (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01) is
>
> published making SRv6 encapsulation the default.
>
Yes, thank you for addressing the issue!

Tom

>
>
> Thanks,
>
> Pablo
>
>
>
> From: dmm <dmm-boun...@ietf.org> on behalf of Satoru Matsushima
> <satoru.matsush...@gmail.com>
> Date: Tuesday, 6 March 2018 at 01:34
> To: dmm <dmm@ietf.org>
> Subject: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>
>
>
> Dear folks,
>
>
>
> A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.
>
>
>
> I’d present brief summary of the updates, but the agenda seems already full
> so that it is uncertain I can do that.
>
>
>
> So let me share the summary of update on the -01 version here.
>
>
>
> A Big progress is that the draft supports interworking with GTP over IPv6 in
> addition to GTP over IPv4.
>
> And we have made change SRv6 function to IPv6 encapsulation with SRH instead
> of SRH insertion by default.
>
>
>
> Another changes have been made. 5G architecture in 3GPP is shown as a
> reference architecture, as the discussion on the list many people ask SRv6
> applicability for 5G. As the result, many terminologies are aligned based on
> the reference.
>
>
>
> You can see many improvements in terms of readability, especially on packet
> flow explanations. I hope that many of us understand how SRv6 works for the
> deployment cases described in the draft.
>
>
>
> Pablo has contributed those significant part of progresses and improvements.
> He's now onboard as a co-author of the draft.
>
>
>
> Best regards,
>
> --satoru
>
>
>
> 転送されたメッセージ:
>
>
>
> 差出人: internet-dra...@ietf.org
>
> 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>
> 日付: 2018年3月6日 7:42:01 JST
>
> 宛先: <i-d-annou...@ietf.org>
>
> CC: dmm@ietf.org
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
>Title   : Segment Routing IPv6 for Mobile User Plane
>Authors : Satoru Matsushima
>  Clarence Filsfils
>  Miya Kohno
>  Pablo Camarillo
>  Daniel Voyer
>  Charles E. Perkins
> Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> Pages   : 23
> Date: 2018-03-05
>
> Abstract:
>   This document discusses the applicability of SRv6 (Segment Routing
>   IPv6) to user-plane of mobile networks.  The source routing
>   capability and the network programming nature of SRv6, accomplish
>   mobile user-plane functions in a simple manner.  The statelessness
>   and the ability to control underlying layer will be even more
>   beneficial to the mobile user-plane, in terms of providing
>   flexibility and SLA control for various applications.  It also
>   simplifies the network architecture by eliminating the necessity of
>   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
>   and so on.  In addition, Segment Routing provides an enhanced method
>   for network slicing, which is briefly introduced by this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Pablo Camarillo (pcamaril)]

Tom,

Re: your comment on EH insertion.

This point is not applicable; a new version of srv6-mobile-uplane 
(https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01) is
published making SRv6 encapsulation the default.

Thanks,
Pablo

From: dmm <dmm-boun...@ietf.org> on behalf of Satoru Matsushima 
<satoru.matsush...@gmail.com>
Date: Tuesday, 6 March 2018 at 01:34
To: dmm <dmm@ietf.org>
Subject: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Dear folks,

A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.

I’d present brief summary of the updates, but the agenda seems already full so 
that it is uncertain I can do that.

So let me share the summary of update on the -01 version here.

A Big progress is that the draft supports interworking with GTP over IPv6 in 
addition to GTP over IPv4.
And we have made change SRv6 function to IPv6 encapsulation with SRH instead of 
SRH insertion by default.

Another changes have been made. 5G architecture in 3GPP is shown as a reference 
architecture, as the discussion on the list many people ask SRv6 applicability 
for 5G. As the result, many terminologies are aligned based on the reference.

You can see many improvements in terms of readability, especially on packet 
flow explanations. I hope that many of us understand how SRv6 works for the 
deployment cases described in the draft.

Pablo has contributed those significant part of progresses and improvements. 
He's now onboard as a co-author of the draft.

Best regards,
--satoru


転送されたメッセージ:

差出人: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
日付: 2018年3月6日 7:42:01 JST
宛先: <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
CC: dmm@ietf.org<mailto:dmm@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Distributed Mobility Management WG of the IETF.

   Title   : Segment Routing IPv6 for Mobile User Plane
   Authors : Satoru Matsushima
 Clarence Filsfils
 Miya Kohno
 Pablo Camarillo
 Daniel Voyer
 Charles E. Perkins
Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
Pages   : 23
Date: 2018-03-05

Abstract:
  This document discusses the applicability of SRv6 (Segment Routing
  IPv6) to user-plane of mobile networks.  The source routing
  capability and the network programming nature of SRv6, accomplish
  mobile user-plane functions in a simple manner.  The statelessness
  and the ability to control underlying layer will be even more
  beneficial to the mobile user-plane, in terms of providing
  flexibility and SLA control for various applications.  It also
  simplifies the network architecture by eliminating the necessity of
  tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
  and so on.  In addition, Segment Routing provides an enhanced method
  for network slicing, which is briefly introduced by this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Hello Tom,

>> A Big progress is that the draft supports interworking with GTP over IPv6 in
>> addition to GTP over IPv4.
>> And we have made change SRv6 function to IPv6 encapsulation with SRH instead
>> of SRH insertion by default.
>> 
> 
> Hi Satoru,
> 
> If there are no intermediate hops od SIDs being set when encapsulating
> would a SR header still be needed or could this just be simple IP in
> IP encpasulation?  If is no SR header then it's possible that ILA
> might then be used to completely eliminate the encapsulation overhead.

I think you’re right. You would find that case in the draft as ‘Traditional 
Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA is 
also equivalent with that mode. In addition, this draft introduces ‘Enhance 
Mode’ to cover more advanced cases.

IMO SR is designed not to maintain path states except at an ingress node. So 
the packet need to preserve original DA in the header that keep the egress node 
in stateless. It would be great if ILA is designed in the similar concept as 
well.

If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
choose which one need to be prioritized would depend on each deployment case in 
operators IMO.

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

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Uma Chunduri]

>A Big progress is that the draft supports interworking with GTP over IPv6 in 
>addition to GTP over IPv4.
>And we have made change SRv6 function to IPv6 encapsulation with SRH instead 
>of SRH insertion by default.

Good to see this and this addresses the RFC 8200 issue – but yes, little bit 
more overhead if you include encapsulating  IPv6 address and SRH with all the 
IPv6 SIDs.
We have just published LSR-WG individual draft which significantly reduce the 
SRH overhead at least with NSPF-ID=4 (v6 SRH data plane). Check this out.


https://www.ietf.org/internet-drafts/draft-ct-isis-nspfid-for-sr-paths-00.txt


This would be presented in IS-IS (LSR) WG and/or SPRING.


--
Uma C.


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

[DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Dear folks,

A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.

I’d present brief summary of the updates, but the agenda seems already full so 
that it is uncertain I can do that.

So let me share the summary of update on the -01 version here.

A Big progress is that the draft supports interworking with GTP over IPv6 in 
addition to GTP over IPv4.
And we have made change SRv6 function to IPv6 encapsulation with SRH instead of 
SRH insertion by default. 

Another changes have been made. 5G architecture in 3GPP is shown as a reference 
architecture, as the discussion on the list many people ask SRv6 applicability 
for 5G. As the result, many terminologies are aligned based on the reference.

You can see many improvements in terms of readability, especially on packet 
flow explanations. I hope that many of us understand how SRv6 works for the 
deployment cases described in the draft. 

Pablo has contributed those significant part of progresses and improvements. 
He's now onboard as a co-author of the draft.

Best regards,
--satoru

> 転送されたメッセージ:
> 
> 差出人: internet-dra...@ietf.org
> 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 日付: 2018年3月6日 7:42:01 JST
> 宛先: 
> CC: dmm@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the 
> IETF.
> 
>Title   : Segment Routing IPv6 for Mobile User Plane
>Authors : Satoru Matsushima
>  Clarence Filsfils
>  Miya Kohno
>  Pablo Camarillo
>  Daniel Voyer
>  Charles E. Perkins
>   Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>   Pages   : 23
>   Date: 2018-03-05
> 
> Abstract:
>   This document discusses the applicability of SRv6 (Segment Routing
>   IPv6) to user-plane of mobile networks.  The source routing
>   capability and the network programming nature of SRv6, accomplish
>   mobile user-plane functions in a simple manner.  The statelessness
>   and the ability to control underlying layer will be even more
>   beneficial to the mobile user-plane, in terms of providing
>   flexibility and SLA control for various applications.  It also
>   simplifies the network architecture by eliminating the necessity of
>   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
>   and so on.  In addition, Segment Routing provides an enhanced method
>   for network slicing, which is briefly introduced by this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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