Re: [DMM] draft-ietf-dmm-srv6-mobile-uplane-18 comments

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Hi Jeffrey,

Many thanks. Inline with PC (-rev19 posted).

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]> 
Sent: domingo, 20 de marzo de 2022 18:05
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: [e-mail]
Subject: draft-ietf-dmm-srv6-mobile-uplane-18 comments

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.
[PC] The SRH is encoded with information from the SR policy. The SR policy does not contain any SRH. Hence, I disagree with your correction. (note I'm not a native speaker)

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

[PC] Changed as per your suggestion.


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
[PC] Changed as per your suggestion.

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.
[PC] The Next Header pushed as part of the instruction S07.
Oh - perhaps you're referring to the NH in the resulting SRv6 header. Better to be clear.
[PC] Clarified in the note.
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",
[PC] We need to set the NH value, as mandated per RFC8200/RFC2473. We need one SID so that each PDU session is associated with a particular type of traffic, and hence NH is known.
 and more importantly, when the SRGW gets an incoming GTP packet, how does it know which instantiation should be used? 
[PC] The IPv6 DA field in the GTP packet contains a SID in the IPv6 DA. That is the SID that is 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.
[PC] Regardless of whether you care of not about the payload, we need to set the NH field of the packet.

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).
[PC] Indeed, corrected.
In fact, why should it matter what the value is?
[PC] For return traffic.
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?
[PC] Removed the prefix.
Similar questions/comments about "source address S" in 6.5.

Thanks.
Jeffrey


Juniper Business Use Only

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]> 
Sent: Friday, February 18, 2022 1:01 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]
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 <zzhang=[e-mail]>
Sent: miércoles, 10 de noviembre de 2021 15:36
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: [e-mail]
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) <pcamaril=[e-mail]>
Sent: Tuesday, October 12, 2021 6:33 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]
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 <[e-mail]>
Sent: jueves, 26 de agosto de 2021 5:21
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: [e-mail]
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