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:[email protected]]
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 <[email protected]>のメール:
>
> 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:[email protected]] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
