Hi Pablo,
Apology for responding late.
I still have some nit/trouble with some text on End.GTP6.D/Di/E behaviors.
First the nits:
There are two instances of " S04. Push a new IPv6 header with its own SRH
containing B". I think "containing B" should be "contained in B" since B is the
policy.
From RFC 8754:
Segment List[0..n]: 128-bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting
from the last segment of the SR Policy. That is, the first
element of the Segment List (Segment List[0]) contains the last
segment of the SR Policy, the second element contains the
penultimate segment of the SR Policy, and so on.
For clarity, it's better to replace the following in "6.3. End.M.GTP6.D":
S08. Write in the last SID of the SRH the Args.Mob.Session
based on the information of buffer memory
with the following:
S08. Write in SRH[0] the Args.Mob.Session
based on the information of buffer memory
And replace the following in "6.4. End.M.GTP6.D.Di"
S08. Write D to the SRH
with the following:
S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly
The troubles I'm having:
For End.M.GTP6.D:
S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) {
...
Notes: The NH is set based on the SID parameter. There is one
instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
NH is already known in advance. For the IPv4v6 PDU Session Type, in
addition we inspect the first nibble of the PDU to know the NH value.
What are the above "notes" about? The "NH" was first mentioned at step S01 and
it is expected to the UDP.
Oh - perhaps you're referring to the NH in the resulting SRv6 header. Better to
be clear.
However, since the other end has corresponding End.DT2/4/6 behaviors, do we
care about setting NH value at all, and do we really need "one instantiation of
the End.M.GTP6.D SID per PDU Session Type", and more importantly, when the SRGW
gets an incoming GTP packet, how does it know which instantiation should be
used? It seems that only one instantiation should be used, but inside the
policy the NH could be set just like how SRH[0] is modified based on TEIDs (as
in S08)?
The same "notes" appeared for End.M.GTP6.Di, but it is not applicable at all?
An End.M.GTP6.E behavior is at the other end, who does not care about the
payload type at all.
Additionally:
6.4. End.M.GTP6.D.Di
...
Any SID instance of this behavior is associated with an SR Policy B
and an IPv6 Source Address S.
...
S05. Set the outer IPv6 SA to S
...
The prefix of S SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway.
What is the last paragraph about? Should "*an* SR gateway" be "*the* SR
gateway"(existing text may imply it is a different gateway).
In fact, why should it matter what the value is?
Besides, an End.M.GTP6.E SID includes both a prefix and Args.Mob.Session,
right? Therefore "The prefix of S should be an End.M.GTP6.E SID" does not make
sense?
Similar questions/comments about "source address S" in 6.5.
Thanks.
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email protected]>
Sent: Friday, February 18, 2022 1:01 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]>
Cc: [email protected]
Subject: RE: draft-ietf-dmm-srv6-mobile-uplane-16 comments
[External Email. Be cautious of content]
Hi Jeffrey,
I added your comments in rev18.
More inline with [PC].
Thanks!
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[email protected]>
Sent: miércoles, 10 de noviembre de 2021 15:36
To: Pablo Camarillo (pcamaril) <[email protected]>
Cc: [email protected]
Subject: RE: draft-ietf-dmm-srv6-mobile-uplane-16 comments
Hi Pablo,
Sorry for the late response. Please see zzh> below.
-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email protected]>
Sent: Tuesday, October 12, 2021 6:33 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]>
Cc: [email protected]
Subject: RE: draft-ietf-dmm-srv6-mobile-uplane-16 comments
[External Email. Be cautious of content]
Hi Jeffrey,
In 5.3, in the downlink, you want to have a SID at the SRGW. This allows you to
a) have the packet FlexAlgo routed up to the SR GW; b) trigger a particular
SRv6 behavior at the GW. There is no benefit in using PBR in the gateway to
trigger the mapping.
Zzh> As I said below, " You can still put GW in the SRH to steer traffic
through the GW."
Zzh> With regard to whether we need End.M.GTP6.D.Di - I understand that
End.M.GTP6.D.Di is one way to do it, but good to point out End.M.GTP6.D can
also be used.
[PC] Agreed that both can be used.
Regarding your comments:
- On (A,Z) usage being inconsistent: Please specify the page or section. I
don't spot it. Thanks.
Zzh> The following is an example of what I meant:
6.3. End.M.GTP6.D
The "Endpoint behavior with IPv6/GTP decapsulation into SR policy"
behavior (End.M.GTP6.D for short) is used in interworking scenario
for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any
SID instance of this behavior is associated with an SR Policy B and
an IPv6 Source Address A.
When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D SID, N does:
zzh> It would be better to use 'S' for source address, and 'D' for destination
address (vs. 'A' for source and 'S' for destination).
[PC] Updated
- On the 5.3.1 typo, fixed (rev17).
Zzh> I think you missed the following 😊
When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
IPv6 header with all its extension headers) and forwards the packet
toward the data network.
Zzh> (U2::1) should be (U2::T)?
[PC] Updated
[PC] Many thanks for your continuous support on this.
Zzh> Jeffrey
Cheers,
Pablo.
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[email protected]>
Sent: jueves, 26 de agosto de 2021 5:21
To: Pablo Camarillo (pcamaril) <[email protected]>
Cc: [email protected]
Subject: draft-ietf-dmm-srv6-mobile-uplane-16 comments
Hi Pablo,
I have not got a chance to go through -16 closely to correlate to our email
discussions, but I have the following comments.
Previously:
-------------
In 5.3, for uplink traffic, the GW has End.M.GTP6.D for the UPF address B and
the gNB does not need to know the existence of GW. For downlink traffic, the
UPF knows there is a GW and put the GW::TEID in the SRH. Why not make GW
invisible to UPF as well and just use gNB::TEID, and then have gNB/96 as
End.M.GTP6.E on the SRGW? You can still put GW in the SRH to steer traffic
through the GW.
[PC] That is a valid point. I'll think about it and get back to you.
-------------
I think we should get a conclusion on this.
Similarly, even for the drop-in mode, SGA can use (U::TEID, C1; SL=3) for
uplink traffic instead of using (U::1, SGB::TEID, C1; SL=3). Then, on SGB, U/96
can be a End.M.GTP6.E. With that, we don't need End.M.GTP6.D.Di anymore, and
End.M.GTP6.E will be like others - checking for "Segments Left != 0" instead of
" Segments Left != 1" (no need to use SRH[0] as destination address of the GTP
packet).
BTW - 5.4 drop-in mode only talks about uplink traffic. I suppose downlink
traffic is the same - either use End.M.GTP6.D.Di or just use End.M.GTP6.D with
(gNB::TEID, ...).
In fact, drop-in mode is not thing special any more - it's just that there is
an SGB attached to the UPF as well as an SGA attached to the gNB like in 5.3.1.
Please see the following additional comments (more may come when I get a chance
to comb through).
(Z,A) or (Z,A) is used to denote the source/destination address of PDU packet.
Then, for End.M.xxx behaviors, A is used to denote something different. Better
change the A to a different letter in either the PDU packets or in the
End.M.xxx behaviors to avoid confusion.
End.M.GTP6.D has the following operation:
S02. Copy the GTP TEID to buffer memory
...
S08. Write in the last SID of the SRH the Args.Mob.Session
based on the information of buffer memory
With that, the U2::1 should be changed to U2::TEID in the following:
5.3.1.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> End with PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
Thanks.
Jeffrey
Juniper Business Use Only
Juniper Business Use Only
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
