Subject: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Apr 2021 17:35:09 +0000

Working Group:

As we discussed in the last IETF meeting, we are issuing WGLC on draft-ietf-dmm-srv6-mobile-uplane-11.
The document went through several revisions and there were good amount of reviews on this document. I am very pleased with the quality of this document. The authors have addressed all the comments and there are no open issues that we are tracking at this time. We believe the document is ready for IESG reviews and like to confirm the same from the working group.

The following message commences a two week WGLC for all feedback.

Document Link:
https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt

Please post any comments/concerns on this document.

Thanks!
Sri

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 7 Apr 2021 14:27:16 -0400

As I believe I said earlier, I consider this work to be inappropriate 
for the IETF and the working group.

Developing SRv6 is an IETF activity. We have done and are doing that.
Developing any needed extensions to address 3GPP requirements should be 
done in conjunction with 3GPP based on their requirements.  3GPP has not 
expressed any such requirements.
When other standards bodies have redefined the architecture of our 
protocols, we (the IETF) have objected.   And for good reasons.

Therefore, we owe other standards bodies the same respect.  We should 
not produce standards (this is a standards track document) that modify 
other bodies architectures.

Yours,
Joel

On 4/7/2021 1:35 PM, Sri Gundavelli (sgundave) wrote:
> Working Group:
> 
> As we discussed in the last IETF meeting, we are issuingWGLCon 
> draft-ietf-dmm-srv6-mobile-uplane-11.
> 
> The document went through several revisions and there were good amount 
> of reviews on this document. I am very pleased with the quality of this 
> document. The authors have addressed all the comments and there are no 
> open issues that we are tracking at this time. We believe the document 
> is ready for IESG reviews and like to confirm the same from the working 
> group.
> 
> The following message commences a two weekWGLCfor all feedback.
> 
> Document Link:
> 
> <https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt>
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 7 Apr 2021 19:47:35 +0000

Hi Joel,

Thank you for your feedback.  I understand your concern / objection is not technical, but more a procedural one, and so I thought I should respond to this.

The document was reviewed in IETF, and was adopted based on the WG feedback and after establishing consensus.  Lot of work and efforts went into this document over the last 2+ years from the working group.  IMO, the document went through a proper IETF document development process.

Now, Regarding the comments related to 3GPP inputs, the document was presented in 3GPP and is documented in 3GPP TR 29.892. So, I am reasonably certain, a RFC publication of this document is not going to spring a surprise to 3GPP. 

On the comment we should work based on explicit inputs, I personally do not agree with that view. IMO, we at IETF need to make efforts to publish new tools that are applicable to 3GPP, 802.11 or any other access.  That effort should not be conditional to 3GPP or other SDO approving that work. That will not do good to IETF goals, of building a better internet. IETF is not an extension to 3GPP body, and their endorsement is not needed for every document that we publish. 3GPP can absolutely choose to keep GTP-U for another 20 years and that is their prerogative. Publication of this spec is not altering that order. FWIW, we should invest in the right technologies, some will make it and some won’t. 

At this time I am marking your objection on procedural grounds. We will discuss this input with our AD, as part of review of other WG feedback.

Thanks
Sri 
(DMM WG Chair)

On 4/7/21, 11:27 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,
    Joel

---

From: Erik Kline <[email-masked]>
Date: Wed, 7 Apr 2021 20:59:18 -0700

Spring folk,

Per request from spring chairs, I wanted to drop a note that a
document discussing using SRv6 in a 3GPP carrier network is in dmm
WGLC.  If this is of interest to you, please feel free to read and
review (please direct comments to dmm@).

Thanks,
-Erik

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 15 Apr 2021 15:08:05 +0200

Hi,

I reviewed a previous version of this document and I think it does
interesting work. I support it moving forward.

Thanks,

Carlos

On Wed, Apr 7, 2021 at 7:35 PM Sri Gundavelli (sgundave) <sgundave=
[email-masked]> wrote:

> The document went through several revisions and there were good amount of
> reviews on this document. I am very pleased with the quality of this
> document. The authors have addressed all the comments and there are no open
> issues that we are tracking at this time. We believe the document is ready
> for IESG reviews and like to confirm the same from the working group.
>
>
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 15 Apr 2021 13:52:03 +0000

Please accept this email as my support of this work and the document.

Best regards,
Arashmid Akhavain

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 07 April 2021 13:35
To: [email-masked]
Subject: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Working Group:

Document Link:

Thanks!
Sri

---

From: Stefano Salsano <[email-masked]>
Date: Fri, 16 Apr 2021 02:52:39 +0200

Hi,

I support the publication of this document.

I'm involved in the Linux SRv6 implementation and I'm planning to extend 
it to support the new behaviors and features described in the document.

Ciao,
Stefano

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: Kentaro Ebisawa <[email-masked]>
Date: Fri, 16 Apr 2021 10:19:02 +0900

Hi,

I have P4 implementation of SRv6 Mobile Uplane based on earlier draft which was used during several hackathon and POC, and planning to extend it once this is published.

-- 
Kentaro Ebisawa | Mainling List: <[email-masked]> | Work: <[email-masked]>

On 2021/04/08 2:35, Sri Gundavelli (sgundave) wrote:
>
> Working Group:
>
> As we discussed in the last IETF meeting, we are issuingWGLCon draft-ietf-dmm-srv6-mobile-uplane-11.
>
> https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt <https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt>
>

---

From: Tetsuya Murakami <[email-masked]>
Date: Sun, 18 Apr 2021 21:22:40 -0700

Hi DMM chairs,

+1

I fully support this draft since this draft has been already mature. Also, we have already had the implementations for SRv6 mobile.

Thanks,
Tetsuya

> 4/7/21 午前10:35、Sri Gundavelli (sgundave) <sgundave=[email-masked]>のメール:
> 
> 
> Working Group:
>

---

From: <[email-masked]>
Date: Tue, 20 Apr 2021 15:30:20 +0000

Dear all,
I would like to thank all authors for providing the effort to do implementations and draft the document.
I think it is a useful document which should be progressed.

During review I think I found some nits including a missing reference and undefined entity (S’ was defined in v06 but is missing in the latest one) and suggest to add perhaps more details e.g., on some acronyms …
Please see attached diff sheet for your convenience.
Thanks!

Best Regards
Dirk

On Wed, Apr 7, 2021 at 7:35 PM Sri Gundavelli (sgundave) <sgundave=[email-masked]<mailto:[email-masked]>> wrote:
Working Group:

Document Link:

Thanks!
Sri

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 21 Apr 2021 04:48:48 +0000

Hi,

I noticed this late and just did a rushed review of the document, so pardon if my questions and comments do not make sense.

End.Map seems to be rather generic and not specific to DMM. Should it be extracted out to a spring document?

It seems that there is no real difference between traditional mode and enhanced mode - it's just whether an SRH is used for TE purpose or not. Is there a need to define these two modes? For example, section "5.3.  Enhanced mode with unchanged gNB GTP behavior" should work with traditional mode as well.

5.2 does talk about "scalability" and "service programming", but the they're not elaborated by the example. I think it's important to elaborate since you introduced the two modes.

In fact, I see the following later:

   Even though we have presented these methods as an extension to the
   "Enhanced mode", it is straightforward in its applicability to the
   "Traditional mode".

So I wonder why you need to define two modes.

In 5.2:

   ... Note that both S1 and C1 are not
   required to have an N4 interface.

Do you mean "neither S1 nor C1 is required to have an N4 interface"?

Any reason why Figure 3 omitted UPF1?

5.3, which is about enhanced mode, has the following:

   In the interworking scenarios as illustrated in Figure 4, the gNB
   does not support SRv6.

It later says in 5.3.1:

   o  When a packet from the UE leaves the gNB, it is SR-routed.

Is that "SR-routed" conflicting with "gNB does not support SRv6"? Or does it really mean that gNB is still using GTP though it does support SRv6?

In 5.3:
   To achieve interworking, a SR Gateway (SRGW-UPF1) entity is
   added.  The SRGW maps the GTP traffic into SRv6.

It seems that it's more accurate to say "UPF1 acts as a SRGW":

   To achieve interworking, UPF1 acts as a SRGW and maps the
   GTP traffic into SRv6.

Is it true that this only works if there is this intermediate UPF1? What if there is no I-UPF (UPF1) for some scenarios? Would UPF2 need to handle both GTP and SRv6?

5.3.1 says:

   o  The gNB is unchanged (control-plane or user-plane) and
      encapsulates into GTP (N3 interface is not modified).
   o  The 5G Control-Plane (N2 interface) is unmodified; one IPv6
      address is needed (i.e. a BSID at the SRGW).

It seems that N4 needs to be changed so that SMF can tell UPF1 and UPF2 to use SRv6 instead of GTP. Or is that N4 still assuming GTP but UPF1 and UPF2 are configured to turn to GTP parameters into SRv6 stuff? That should be made clear here.

In the following:

5.3.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A)                            -> UPF2 maps flow with SID
                                               <C1, S1,SRGW::SA:DA:TEID>
   UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
   C1_out  : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
   S1_out  : (U2::1, SRGW::SA:DA:TEID)(Z,A)
   SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A)       -> End.M.GTP4.E
   gNB_out : (Z,A)

I assume (SA, DA) are the addresses of UPF1 and gNB respectively? How does UPF2 know the address of the gNB? In IPv6 case (5.3.1) the UPF1 knows the gNB address from the N4 signaling but shouldn't IPv4 case be the same?

For the following:

5.3.2.3.  Scalability

Is it the same as IPv6 case? If so it's better to just state so instead of repeating.

In the following:

5.3.3.  Extensions to the interworking mechanisms

   In this section we presented three mechanisms for interworking with
   gNBs and UPFs that do not support SRv6.  These mechanisms are used to
   support GTP over IPv4 and IPv6.

   Furthermore, although these mechanisms are designed for interworking
   with legacy RAN at the N3 interface, these methods could also be
   applied for interworking with a non-SRv6 capable UPF at the N9
   interface (e.g.  L3-anchor is SRv6 capable but L2-anchor is not).

What's the third mechanism? I only counted two (5.3.1 and 5.3.2).
What is a L3-anchor vs. L2-anchor?

For 5.4 and Figure 7:

   When a packet destined to Z to the gNB, which is unmodified, it
   performs encapsulation into a new IP, UDP and GTP headers.  The IPv6
   DA, U::1, and the GTP TEID are the ones received at the N2 interface.

What does "which is unmodified" mean?
U1b::TEID only appeared once and I could not figure out what it is - should it be SGB::TEID?
U2b:: appeared twice but I could not figure out what it is. Could it be U::1?
UPF2b appeared twice but I could not find it in the figure.

For 6.4, how is the SGB::TEID written into the SRH? If it's via "S04.    Push a new IPv6 header with its own SRH containing B", does that mean we need one policy for each TEID?

Should the following be added to 6.5.  End.M.GTP6.E, like in 6.4?
   Any SID instance of this behavior is associated with an SR Policy B
   and an IPv6 Source Address A.

For the following rules in 6.5:

   S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
   S02.    Copy SRH[0] to buffer memory
   ...
   S08.    Set the GTP TEID (from buffer memory)

Does SRH[0] corresponds to U::1 or SGB::TEID in the 5.4 example as quoted below?

 C1_out  : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
 GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z)            ->U1b::TEID is an
                                                         End.M.GTP6.E
                                                         SID at SRGW-B

Thanks.
Jeffrey

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Erik Kline
Sent: Wednesday, April 7, 2021 11:59 PM
To: SPRING WG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [spring] note: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]

Spring folk,

Thanks,
-Erik

On Wed, Apr 7, 2021 at 10:35 AM Sri Gundavelli (sgundave)
<sgundave=[email-masked]> wrote:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgRDc4fJS$
>
>
>
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgY0wXO9D$

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgQZXTemu$

Juniper Business Use Only

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 26 Apr 2021 18:52:12 +0000

The WGLC is now closed. Thanks for all the feedback. We believe, there is general consensus to move the document forward. There were also few concerns expressed and that we will discuss with our AD, and make sure they are reflected in the shepherd notes. Thanks for all the feedback.

Authors: Please respond and resolve all the comments that were posted as part of this LC. Once the comments are resolved, we will move this for AD review.

Sri

From: Sri Gundavelli <[email-masked]>
Date: Wednesday, April 7, 2021 at 10:35 AM
To: "[email-masked]" <[email-masked]>
Subject: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Working Group:

Document Link:

Thanks!
Sri