Re: [DMM] DMM WG Adoption Poll (1) for "Architecture Discussion on SRv6 Mobile User plane" - draft-kohno-dmm-srv6mob-arch-07

[Pablo Camarillo (pcamaril)]

I support the adoption of this draft.

Thanks!

From: Satoru Matsushima 
Sent: jueves, 19 de octubre de 2023 11:41
To: dmm 
Cc: draft-kohno-dmm-srv6mob-a...@ietf.org
Subject: DMM WG Adoption Poll (1) for "Architecture Discussion on SRv6 Mobile 
User plane" - draft-kohno-dmm-srv6mob-arch-07

Dear DMMers,

This email starts a two-weeks DMM WG adoption poll (1) for "Architecture 
Discussion on SRv6 Mobile User plane" - draft-kohno-dmm-srv6mob-arch-07.

https://datatracker.ietf.org/doc/draft-kohno-dmm-srv6mob-arch/

Please review the draft and post any comments on this mail thread prior to 
Friday, November 3rd, 2023.

Regards,
Sri, Satoru


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

Re: [DMM] Roman Danyliw's No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

[Pablo Camarillo (pcamaril)]

Hi Roman,

Many thanks for your review. Please see inline with [PC]. Note that I've posted 
rev24 of the document.

Cheers,
Pablo.

-Original Message-
From: Roman Danyliw via Datatracker  
Sent: sábado, 31 de diciembre de 2022 2:23
To: The IESG 
Cc: draft-ietf-dmm-srv6-mobile-upl...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Sri Gundavelli (sgundave) ; Sri Gundavelli 
(sgundave) 
Subject: Roman Danyliw's No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: 
(with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-dmm-srv6-mobile-uplane-23: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/



--
COMMENT:
--

Thank you to Stephen Farrell for the SECDIR review.

** I am puzzled by the characterization of this document in the abstract text
and in the Introduction (Section 1) as “specif[ying] the applicability of SRv6
(Segment Routing IPv6) to mobile networks.”  This seems inaccurate. If this
document was focused on applicability, I would have expected it to describe
_existing_ protocol behavior being applied to the mobile network use case. 
However, Section 6 is defining new SR behavior in support of a mobility
solution.

[PC] I've updated the abstract in rev24.

** I also don’t understand the 3GPP coordination described in the shepherd
report resulting in this document being moved from PS to Informational status. 
Is this new behavior requested by 3GPP?

[PC] Please see the shepherd report as well as the subsequent reply to this 
ballot by Erik Kline.

** Section 3.  Editorial.
   ... on the other-hand, there are new use-cases like distributed
   NFVi that are also challenging network operations.

Is it “NFVi” or NFVI”?  The RFC Editor acronym list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt) uses all caps.

[PC] Expanded term.

** Section 3.
   In the meantime, applications have shifted to use IPv6, and network
   operators have started adopting IPv6 as their IP transport.

Is there citations that can be provided to substantiate these motivating trends?

[PC] I don't have any reference regarding to the shift of applications to IPv6. 
If you have any I can add it.
[PC] Regarding the adoption of IPv6 in operator's IP transport, I believe the 
reference to I-D.matsushima-spring-srv6-deployment-status is sufficient, as all 
the networks deployed with SRv6 have an IPv6 transport.

** Section 3.
   SRv6 has been
   deployed in dozens of networks
   [I-D.matsushima-spring-srv6-deployment-status].

Is there a non-expired draft that can be referenced?

[PC] I believe the authors of I-D.matsushima-spring-srv6-deployment-status are 
working on an update.

** Section 3.  Typo. s/architetural/architectural/

[PC] Fixed. Thanks.

** Section 5.2

   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.

Please rephrase this text so that that normative “MAY” does not suggest a list
of protocol that are immediately said to be out of scope in the next sentence.

[PC] Removed the normative MAY, as its incorrect. Also removed the list of 
potential mechanisms (as per Eric V review)

** Section 5.3.  What is a “SR Gateway”?  I can’t find a reference to it in
other SPRING documents.  The only text I can find here is that it “maps the
GTP-U traffic to SRv6.” -- What does that mapping activity entail? -- Is the
gateway the boundary of the SR domain? Yes?

[PC] Added a couple of sentences to clarify it. It maps SRv6 to GTP-U, and it 
is the domain boundary.

** Section 8.  If I was an implementer, I would have trouble understanding the
purpose of this section.  It appears to be a list of annotated references.  Is
their implementation suggested for this mobility use case?

[PC] The section provides an informative list of IETF docs that define how to 
build a network slice in the context of SR. Slices is quite common in the 
context of mobile networks, and hence we believe that this section is useful.

** Section 8
   A mobile network may be required to implement "network slices", which
   logically separate network resources.  User-plane behaviors
   represented as SRv6 segments would be part of a slice.

Are different “network slices” also different SR domains?

[PC] Same domain. Nonetheless, I have removed the sentence "User-plane 

Re: [DMM] Zaheduzzaman Sarker's No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

[Pablo Camarillo (pcamaril)]

Hi Zahed,

Many thanks for your review. Please see inline with [PC].
Rev24 just posted.

-Original Message-
From: Zaheduzzaman Sarker via Datatracker  
Sent: martes, 3 de enero de 2023 14:58
To: The IESG 
Cc: draft-ietf-dmm-srv6-mobile-upl...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Sri Gundavelli (sgundave) ; Sri Gundavelli 
(sgundave) 
Subject: Zaheduzzaman Sarker's No Objection on 
draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-dmm-srv6-mobile-uplane-23: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/



--
COMMENT:
--

Thanks for working on this specification. Thanks also for attending useful
discussion throughout the progress of the document, I think informational
status probably the right thing to do.

I have some comments, those I think when addressed with improve the document
more -

1. Section 4: I see no need to change UE = User equipment to UE = User endpoint.
[PC] Many thanks. My bad, I've kept it consistent to User Equipment.

2. I didn't find scalability as a motivating point in the section 3 in clear
text, however, found the enhanced mode to solve the scalability issue later.
This happens without educating us about the scalability issue that the mobile
network has. I think it would be great if this informational specification also
inform about the existing issues regarding scalability the current network
architecture has.
[PC] Good point. I've added to section 3.

3. hmm, how any modes we are really defining here ? we are defining traditional
and enhanced mode, and then section 5.4 is also defining another one.. this is
confusing. We should clearly say there are three modes in the beginning if we
have 3 modes. However, I actually don't think 5.4 defines another mode, rather
it is a combined arrangement of traditional and enhanced mode, so it should be
call it that way or another mechanism of enhanced inter-working.
[PC] Indeed. I corrected it at the beginning.


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

Re: [DMM] Paul Wouters' No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

[Pablo Camarillo (pcamaril)]

Hi Paul,

Many thanks for the review. See inline with [PC]. I've pushed an updated 
revision of the document (rev-24)

Cheers,
Pablo

-Original Message-
From: Paul Wouters via Datatracker  
Sent: martes, 3 de enero de 2023 23:04
To: The IESG 
Cc: draft-ietf-dmm-srv6-mobile-upl...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Sri Gundavelli (sgundave) ; Sri Gundavelli 
(sgundave) 
Subject: Paul Wouters' No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: 
(with COMMENT)

Paul Wouters has entered the following ballot position for
draft-ietf-dmm-srv6-mobile-uplane-23: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/



--
COMMENT:
--

#1 I would change the order of the Contributions and Acknowledgements sections
- it is sort of customary to say more important things earlier and
"contributions" seem of higher importance than "acknowledgements"
[PC] Changed, indeed.

#2 Appendix A is really an "Implementation Status" section. Those sections are
removed before publication as an RFC, but I see no note to the RFC editor that
this section is to be removed. It should be removed for the same reasons the
"Implementation Status" section is always removed.
[PC] Added a note to RFC Editor to remove it.



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

Re: [DMM] Murray Kucherawy's No Objection on draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

[Pablo Camarillo (pcamaril)]

Hi Murray,

Many thanks for your review. See inline with [PC].
I've posted an updated rev of the draft (-24).

Cheers,
Pablo.

-Original Message-
From: Murray Kucherawy via Datatracker  
Sent: sábado, 31 de diciembre de 2022 5:48
To: The IESG 
Cc: draft-ietf-dmm-srv6-mobile-upl...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Sri Gundavelli (sgundave) 
Subject: Murray Kucherawy's No Objection on 
draft-ietf-dmm-srv6-mobile-uplane-23: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-dmm-srv6-mobile-uplane-23: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/



--
COMMENT:
--

The shepherd writeup avoids the question about current or planned
implementations, and the simple answer "Yes" to #17 seems to be not as
informative as we'd like.
[PC] Please see the Appendix A of the document (Implementations).

Section 11 is missing the "Change controller" column for all values.  I can't
tell why that column is present in the registry, actually, since it wasn't
present in RFC 8986 which created it, so it seems like there's something to be
cleaned up here with IANA.
[PC] I've added the Change Controller column (obviously with value= IETF). 



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

Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm-srv6-mobile-uplane-23: (with DISCUSS and COMMENT)

[Pablo Camarillo (pcamaril)]

Hi Eric,

Many thanks for the review. Please see inline with [PC].
I've posted revision -24 of the draft.

Cheers,
Pablo.

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: jueves, 5 de enero de 2023 12:44
To: The IESG 
Cc: draft-ietf-dmm-srv6-mobile-upl...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Sri Gundavelli (sgundave) ; Sri Gundavelli 
(sgundave) 
Subject: Éric Vyncke's Discuss on draft-ietf-dmm-srv6-mobile-uplane-23: (with 
DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-dmm-srv6-mobile-uplane-23: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/



--
DISCUSS:
--


# Éric Vyncke, INT AD, comments for draft-ietf-dmm-srv6-mobile-uplane-23
CC @evyncke

Thank you for the work put into this document. I always like the use of
innovative technologies.

Please find below two blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Sri Gundavelli for the shepherd's detailed write-up including
the very descriptive WG consensus ***but*** the justification of the intended
status is plain wrong as it is about the original intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Intended status

The shepherd's write-up is about a standard track intended status, but this
document text & meta-data say informal. I know the sad history of the intended
status as well as that the IETF Last Call was done a 2nd time for
'informational', but I am afraid that the shepherd's write-up must be updated.

### Section 2.2

What is "gNB" ? (I know the term, but a reference and definition should be
given)
[PC] Added to terminology list.

Unsure how to parse the bullet list as `SRH[n]: A shorter ` appears in the
middle of apparently a single list. Or is it two lists ? Then what is the
relationship with the 2nd list ? (possibly just a formatting issue).
[PC] Clarified sentence, added proper formatting. Thanks.


--
COMMENT:
--


## COMMENTS

### Abstract

The tone of the abstract looks more like a promotional rather than a factual
description. Please consider rewriting it in a more factual way.

Also add text about the non-normative nature of this I-D.

[PC] done some slight rewording and added extra sentence. Feel free to let me 
know if this is better.

### Section 1

This section contains the 'instruction' term, which is seems to me more related
to network programming (RFC 8986). The following sections are also about
network programming. So, let's be clear and refer to both SRH and network
programming.
[PC] added both references.

### Section 2.1

Please explain what a 'DN' is.
[PC] Added DN to the acronym list.

Also, usually the terminology section is not only about acronym expansion but
also about *explanations* or *descriptions* of the terms.

### Section 3

What is "NFVi" ?
[PC] Expand text to NFV infrastructure as it is the only appearance in the 
document.

### Section 4

About the "a reference architecture" is it the 3GPP architecture (per figure 1)
or the architecture defined in this I-D ? I suspect the former, but then let's
be clear in the text and in the section title.
[PC] Clarified in the text.

`The 5G packet core architecture as shown is based on the latest 3GPP standards
at the time of writing this draft` I could be wrong and will be happy to stand
corrected, but it seems to me that 5G is already deployed, hence the `at the
time of writing this draft` is not really relevant.
[PC] I removed the text.

`A UE gets its IP address from the DHCP block of its UPF.` is this sentence
also applicable for IPv6 ? I had in mind (again happy to stand corrected) that
for IPv6 a /64 was assigned per UE, i.e., not an "IP address".
[PC] You are right. Corrected. :-)

### Section 5

Suggest s/In order to simplify the adoption of SRv6, we present/This document
presents/
[PC] Thanks. Suggestion taken.

The rest of the section also uses "we", which is not the usual way to write an
IETF document.
[PC] And not only this section, but several places 

Re: [DMM] Secdir last call review of draft-ietf-dmm-srv6-mobile-uplane-21

[Pablo Camarillo (pcamaril)]

Thanks for the review, Stephen. I've removed the example as you suggested. 
(Already posted in rev22)

Cheers,
Pablo.

-Original Message-
From: Stephen Farrell via Datatracker  
Sent: sábado, 5 de noviembre de 2022 18:47
To: sec...@ietf.org
Cc: dmm@ietf.org; draft-ietf-dmm-srv6-mobile-uplane@ietf.org; 
last-c...@ietf.org
Subject: Secdir last call review of draft-ietf-dmm-srv6-mobile-uplane-21

Reviewer: Stephen Farrell
Review result: Has Issues

This is a relatively minor issue, but worth fixing. This draft is aiming for 
standards-track. RFC2804 says that we won't standardise lawful intercept 
mechanisms, yet the draft specifies in 6.1 that Args.Mob.Session can be used 
for that. I'd say best is to just drop that example usage to avoid having to 
worry about this.

Otherwise, if one believes the basic security claim of SRv6 (that traffic can 
be kept within a "trusted" local n/w) then the security considerations here are 
correct that this doesn't add anything new.


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

Re: [DMM] Second WGLC on draft-ietf-dmm-srv6-mobile-uplane

[Pablo Camarillo (pcamaril)]

Hi all,

We have just posted revision 20 of the draft.
It addresses two comments from Jeffrey that have been addressed thanks to his 
suggested text (thanks!).

Cheers,
Pablo.

From: dmm  On Behalf Of Sri Gundavelli (sgundave)
Sent: sábado, 9 de abril de 2022 5:08
To: Sri Gundavelli (sgundave) ; 
dmm@ietf.org
Subject: Re: [DMM] Second WGLC on draft-ietf-dmm-srv6-mobile-uplane

The WGLC is now closed. Based on the feedback received from the first and 
second last calls, we believe there is rough consensus to move the document 
forward.

There have been few objections raised during the first WGLC, primarily the 
concern that the document attempts to redefine 3GPP standard in an IETF 
document and that is not acceptable. The authors have worked with the reviewers 
and based on the WG chair feedback have updated the document. Many of the 
sections are now marked as informative sections. The feedback from the second 
LC did not reflect any such major concerns, except from one WG member who still 
believes this issue is not resolved.

We will review this feedback, discuss with our AD, and see how we can address 
this concern. It is not our intent to redefine SDO standards in an IETF 
specification, but it is rather about the broader applicability and use of open 
IETF protocols in various architectures in an informative manner. No part of 
this specification should redefine any of the SDO interfaces. An implementation 
is not required to implement any part of this specification for it to be 
compliant to the SDO defined standards. We will work with our AD and review 
this feedback carefully and work out the proposed changes, if any.

Thanks for all the feedback.

Authors – Please post a revised document with any additional changes/edits/ 
based on the LC feedback.

Sri








From: dmm mailto:dmm-boun...@ietf.org>> on behalf of "Sri 
Gundavelli (sgundave)" 
mailto:sgundave=40cisco@dmarc.ietf.org>>
Date: Friday, April 1, 2022 at 8:13 AM
To: "dmm@ietf.org" mailto:dmm@ietf.org>>
Subject: [DMM] Second WGLC on draft-ietf-dmm-srv6-mobile-uplane

Folks:

We have issued a WGLC on draft-ietf-dmm-srv6-mobile-uplane in April of last 
year. Based on the feedback and the comments from the WG, we chose to hold the 
document so the authors can resolve the identified issues from that LC. The 
authors have worked with the reviewers and have revised the document. They 
believe that there are no open issues. We are issuing a second last call. This 
message commences a one-week WGLC for all feedback.  Please provide any 
additional feedback you may have.

https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-19


Sri
Chair DMM WG




From: Sri Gundavelli mailto:sgund...@cisco.com>>
Date: Wednesday, April 7, 2021 at 10:35 AM
To: "dmm@ietf.org" mailto:dmm@ietf.org>>
Subject: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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



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

Re: [DMM] Second WGLC on draft-ietf-dmm-srv6-mobile-uplane

[Pablo Camarillo (pcamaril)]

Hi Joel,

Could you please confirm which sub-sections of the draft do your comment 
apply-to? Thank you.

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Joel M. Halpern
Sent: viernes, 1 de abril de 2022 17:28
To: Sri Gundavelli (sgundave) ; 
dmm@ietf.org
Subject: Re: [DMM] Second WGLC on draft-ietf-dmm-srv6-mobile-uplane

As far as I can tell, this document still attempts to redefine 3GPP standards 
in an IETF standards track document.  That is in my view unacceptable.

Yes, those sections are labelled "informational".  But they are still the same 
content, presented the same way.  Pretending they are informational in a 
standards track document is simply not sufficient. 
If they are really informational, pull them out to a separate informational 
document.  And we can then debate the value of publishing those non-standard 
approaches.  (Personally, I do not see the value.)

Yours,
Joel

On 4/1/2022 11:13 AM, Sri Gundavelli (sgundave) wrote:
> Folks:
> 
> We have issued a WGLC on draft-ietf-dmm-srv6-mobile-uplane in April of 
> last year. Based on the feedback and the comments from the WG, we 
> chose to hold the document so the authors can resolve the identified 
> issues from that LC. The authors have worked with the reviewers and 
> have revised the document. They believe that there are no open issues. 
> We are issuing a second last call. This message commences a one-week 
> WGLC for all feedback.  Please provide any additional feedback you may have.
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplan
> e-19 
>  ne-19>
> 
> Sri
> 
> Chair DMM WG
> 
> *From: *Sri Gundavelli 
> *Date: *Wednesday, April 7, 2021 at 10:35 AM
> *To: *"dmm@ietf.org" 
> *Subject: *WGLC on draft-ietf-dmm-srv6-mobile-uplane-11
> 
> 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.t
> xt 
>  txt>
> 
> Please post any comments/concerns on this document.
> 
> Thanks!
> 
> Sri
> 
> 
> ___
> 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] draft-ietf-dmm-srv6-mobile-uplane-18 comments

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

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

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: domingo, 20 de marzo de 2022 18:05
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
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)  
Sent: Friday, February 18, 2022 1:01 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
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 
Sent: miércoles, 10 de noviembre de 2021 15:36
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: draft-ietf-dmm-srv6-mobile-uplane-16 comments

Hi Pablo,

Sorry for the late 

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

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

I added your comments in rev18. 
More inline with [PC].

Thanks!

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: miércoles, 10 de noviembre de 2021 15:36
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
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) 
Sent: Tuesday, October 12, 2021 6:33 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
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 
Sent: jueves, 26 de agosto de 2021 5:21
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
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)
  

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

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with PC. New version of the draft posted (rev17).

Thanks,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: viernes, 27 de agosto de 2021 1:01
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Additional draft-ietf-dmm-srv6-mobile-uplane-16 comments

Hi Pablo,

Some editorial/nit comments and some more substantial questions/comments below.

   In mobile networks, mobility management systems provide connectivity
   over a wireless link to stationary and non-stationary nodes.  The
   user-plane establishes a tunnel between the mobile node and its
   anchor node over IP-based backhaul and core networks.

A nit question - why "management" systems? That sounds like user plane is not 
involved.
[PC] "Management" removed.

   This document shows the applicability of SRv6 (Segment Routing IPv6)
   to mobile networks.

This document is not just "showing" the applicability. It actually specifies 
how it is done, right?
[PC] s/shows/specifies

   Segment Routing [RFC8402] is a source routing architecture: a node
   steers a packet through an ordered list of instructions called
   "segments".  A segment can represent any instruction, topological or
   service based.

   SRv6 applied to mobile networks enables a source-routing based mobile
   architecture, where operators can explicitly indicate a route for the
   packets to and from the mobile node.  The SRv6 Endpoint nodes serve
   as mobile user-plane anchors.

The last sentence is not exactly true. The SRv6 endpoint nodes could be GWs.
[PC] Feel free to propose a different text. In the traditional and enhanced 
mode the SRv6 endpoints are the mobility user-plane anchors.

   The second mode is the "Enhanced mode".  This is an evolution from
   the "Traditional mode".  In this mode the N3, N9 or N6 interfaces
   have intermediate waypoints -SIDs- that are used for Traffic
   Engineering or VNF purposes.  This results in optimal end-to-end
   policies across the mobile network with transport and services
   awareness.

s/purposes/purposes transparent to 3GPP functionalities/
[PC] Changed.

5.1.  Traditional mode

   In the traditional mode, the existing mobile UPFs remain unchanged
   with the sole exception of the use of SRv6 as the data plane instead
   of GTP-U.  There is no impact to the rest of the mobile system.

   In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is mirrored
   here to replace GTP encapsulation with the SRv6 encapsulation, while
   not changing anything else.  There will be a unique SRv6 SID
   associated with each PDU Session, and the SID list only contains a
   single SID.

Does "a unique SRv6 SID associated with each PDU Session" mean that gNB/UPF 
will have those individual unique SIDs installed in the forwarding plane"?
[PC] Yes... in the same way today they need to have the GTP-U tunnel parameters 
installed in the forwarding plane. Not sure I get your point.

   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground.

   The gNB/UPF control-plane (N2/N4 interface) is unchanged,
   specifically a single IPv6 address is provided to the gNB.  The same
   control plane signalling is used, and the gNB/UPF decides to use SRv6
   based on signaled GTP-U parameters per local policy.  The only
   information from the GTP-U parameters used for the SRv6 policy is the
   TEID and the IPv6 Destination Address.

Also QFI?
[PC] Added.

   Our example topology is shown in Figure 2.  In traditional mode the
   gNB and the UPFs are SR-aware.  

Strike "In traditional mode"?
[PC] Removed.

5.1.1.  Packet flow - Uplink

   The uplink packet flow is as follows:

 UE_out  : (A,Z)
 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 
 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
 UPF2_out: (A,Z)  -> End.DT4 or End.DT6

   When the UE packet arrives at the gNB, the gNB performs a
   H.Encaps.Red operation.  Since there is only one SID, there is no
   need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
   U1::1.  U1::1 represents an anchoring SID specific for that session
   at UPF1. gNB obtains the SID U1::1 from the existing control plane
   (N2 interface).

The last sentence is misleading. SID U1::1 is constructed by gNB and it should 
really be U1::TEID where U1 is the "single IPv6 address is provided to the gNB".
[PC] Reverted the order of those two last sentences which I believe improves 
readability.

   When the packet arrives at UPF1, the SID U1::1 is associated with the
   End.MAP SRv6 Endpoint Behavior.  End.MAP replaces U1::1 by U2::1,
   that belongs to the next UPF (U2).

U::1 should be U1::TEID1, and U2::1 should be U2::TEID2?
[PC] As stated in the draft &quo

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

[Pablo Camarillo (pcamaril)]

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.

Regarding your comments:
- On (A,Z) usage being inconsistent: Please specify the page or section. I 
don't spot it. Thanks.
- On the 5.3.1 typo, fixed (rev17).

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: jueves, 26 de agosto de 2021 5:21
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
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

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

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Thanks for the answer. Inline with PC6, and updated version of the draft posted 
(rev16).

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 5 de agosto de 2021 21:13
To: 'Pablo Camarillo (pcamaril)' 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Coming back to this after IETF111 ...

Please see zzh5> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Thursday, July 22, 2021 1:25 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with PC5.

Thanks,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: miércoles, 21 de julio de 2021 23:34
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh4> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Wednesday, July 21, 2021 1:34 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with PC4.

Thanks!
(and apologize for the delay)

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 15 de junio de 2021 22:16
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh3> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 15, 2021 3:03 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 22:10
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:15 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 
5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the 
SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. 
But TEID is not present.. therefore writing gNB::TEID would be misleading. See 
my point?
Zzh2> I don't mean that TEID is present in a GTP-U header. It is part of the 
IPv6 address (used for DX2/4/6 purpose). Writing it as gNB::TEID emphasize that 
the TEID information is embedded in the address, 

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Resending as there was a typo.

Inline with PC2.

Thanks.

From: Sridhar Bhaskaran 
Sent: miércoles, 28 de julio de 2021 15:34
To: Pablo Camarillo (pcamaril) 
Cc: David Allan I ; dmm@ietf.org
Subject: [SUSPECTED SPAM] Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo / Dave all,

See my additional comment inline marked [SB]

Regards
Sridhar

On Wed, Jul 28, 2021 at 12:06 AM Pablo Camarillo (pcamaril) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Dave,

Many thanks for your comments. Inline with PC.

Cheers,
Pablo.

-Original Message-
From: dmm mailto:dmm-boun...@ietf.org>> On Behalf Of 
David Allan I
Sent: viernes, 23 de julio de 2021 19:51
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi:

Looking over this draft it strikes me that IF you are discussing a GTP 
replacement, there are a few unaddressed gaps...or at least I see no mention of 
them.

-  adding X2 to the list of interfaces to be supported
[PC] Do you think there is any new mechanism to be added to the currently 
defined ones?
[SB] If we are including X2 then F1U also needs to be considered. Both X2 and 
F1U also have GTPU flow control mechanism defined in TS 38.425. I am not sure 
if a corresponding feedback mechanism exists in SRv6 for flow control.
[PC2] The user plane message encoding, or Flow control, is out of the scope of 
this draft; but covered in draft-murakami-dmm-user-plane-message-encoding.
Speaking as a co-author of draft-murakami: up to now we did not consider F1U, 
but if the working group believes there is value, then we could add it. Thanks.


-  support for end-marker for handoff stream synchronization (probably could 
fit the unused bit in Args.Mob.Session but frankly I have not studied this in 
detail)
[PC] User Plane Message encoding is out of the scope of this draft. However, 
draft-murakami-dmm-user-plane-message-encoding-03 proposes a mechanism to 
encode the Echo Request, Echo Reply, Error Indication, and End Marker.

-  support for QMP (quality measurement protocol), which I believe needs to 
also extend across the radio interface so is not simply local to the GTP domain 
and can be "stunt doubled"
[PC] Excellent point. Seems we missed this one in draft-murakami! We can add in 
there the QoS Monitoring Packet indicator, as well as the encoding for the 
timestamps and average DL/UL delays.

-  support for paging policy presence/indication
[PC] Same as previous. Many thanks.

[PC], By the way, I've posted an updated revision as the reference to 
draft-murakami was missing.

If this has come up elsewhere, let me know

Cheers
Dave


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

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


--
 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)

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

Re: [DMM] [SUSPECTED SPAM] Re: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Sridhar,

Inline with PC2.

Thanks!

From: Sridhar Bhaskaran 
Sent: miércoles, 28 de julio de 2021 15:34
To: Pablo Camarillo (pcamaril) 
Cc: David Allan I ; dmm@ietf.org
Subject: [SUSPECTED SPAM] Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo / Dave all,

See my additional comment inline marked [SB]

Regards
Sridhar

On Wed, Jul 28, 2021 at 12:06 AM Pablo Camarillo (pcamaril) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Dave,

Many thanks for your comments. Inline with PC.

Cheers,
Pablo.

-Original Message-
From: dmm mailto:dmm-boun...@ietf.org>> On Behalf Of 
David Allan I
Sent: viernes, 23 de julio de 2021 19:51
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi:

Looking over this draft it strikes me that IF you are discussing a GTP 
replacement, there are a few unaddressed gaps...or at least I see no mention of 
them.

-  adding X2 to the list of interfaces to be supported
[PC] Do you think there is any new mechanism to be added to the currently 
defined ones?
[SB] If we are including X2 then F1U also needs to be considered. Both X2 and 
F1U also have GTPU flow control mechanism defined in TS 38.425. I am not sure 
if a corresponding feedback mechanism exists in SRv6 for flow control.
[PC2] The user plane message encoding, or Flow control, is out of the scope of 
this draft; but covered in draft-murakami-dmm-user-plane-message-encoding.
Speaking as a co-author of draft-murakami: up to now we did not consider X2, 
but if the working group believes there is value then we could add it. Thanks.

-  support for end-marker for handoff stream synchronization (probably could 
fit the unused bit in Args.Mob.Session but frankly I have not studied this in 
detail)
[PC] User Plane Message encoding is out of the scope of this draft. However, 
draft-murakami-dmm-user-plane-message-encoding-03 proposes a mechanism to 
encode the Echo Request, Echo Reply, Error Indication, and End Marker.

-  support for QMP (quality measurement protocol), which I believe needs to 
also extend across the radio interface so is not simply local to the GTP domain 
and can be "stunt doubled"
[PC] Excellent point. Seems we missed this one in draft-murakami! We can add in 
there the QoS Monitoring Packet indicator, as well as the encoding for the 
timestamps and average DL/UL delays.

-  support for paging policy presence/indication
[PC] Same as previous. Many thanks.

[PC], By the way, I've posted an updated revision as the reference to 
draft-murakami was missing.

If this has come up elsewhere, let me know

Cheers
Dave


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

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


--
 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)

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

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Dave,

Many thanks for your comments. Inline with PC.

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of David Allan I
Sent: viernes, 23 de julio de 2021 19:51
To: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi:

Looking over this draft it strikes me that IF you are discussing a GTP 
replacement, there are a few unaddressed gaps...or at least I see no mention of 
them.

-  adding X2 to the list of interfaces to be supported
[PC] Do you think there is any new mechanism to be added to the currently 
defined ones?

-  support for end-marker for handoff stream synchronization (probably could 
fit the unused bit in Args.Mob.Session but frankly I have not studied this in 
detail)
[PC] User Plane Message encoding is out of the scope of this draft. However, 
draft-murakami-dmm-user-plane-message-encoding-03 proposes a mechanism to 
encode the Echo Request, Echo Reply, Error Indication, and End Marker.

-  support for QMP (quality measurement protocol), which I believe needs to 
also extend across the radio interface so is not simply local to the GTP domain 
and can be "stunt doubled"
[PC] Excellent point. Seems we missed this one in draft-murakami! We can add in 
there the QoS Monitoring Packet indicator, as well as the encoding for the 
timestamps and average DL/UL delays.

-  support for paging policy presence/indication
[PC] Same as previous. Many thanks. 

[PC], By the way, I've posted an updated revision as the reference to 
draft-murakami was missing.

If this has come up elsewhere, let me know

Cheers
Dave


___
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] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey, 

Inline with PC2.

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 22 de julio de 2021 16:36
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: Sri Gundavelli (sgundave) ; dmm@ietf.org
Subject: RE: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Many thanks for the summary of the open items.
See inline with [PC].

Cheers,
Pablo.

> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: miércoles, 14 de julio de 2021 21:56
> To: Sri Gundavelli (sgundave) ; Pablo Camarillo
> (pcamaril) 
> Cc: dmm@ietf.org
> Subject: RE: [DMM] Additional questions/comments on 
> draft-ietf-dmm-srv6-
> mobile-uplane-13
>
> Hi,
>
> Here is my summary.
>
> General comments:
>
> 1. There were some architecture discussions about 
> SRv6-transporting-GTPu vs SRv6-replacing-GTPu. I understand that this 
> document is about SRv6-replacing- GTPu and the other is out of scope. That's 
> ok - but the draft should omit "3.
> Motivation" and just have an informational reference to 
> draft-kohno-dmm- srv6mob-arch. In other words, defer the motivation 
> discussion to the separate draft and just focus on technical details 
> in this spec. BTW - I want to clarify here that when I said "the only 
> advantage of SRv6-replacing-GTPu is MTU savings" is *in comparison* to 
> SRv6-transporting-GTPu.

[PC] I have mixed feelings about removing the Section 3(Motivation).
[PC] Stating a couple of paragraphs of motivation is useful to the reader, 
while -if they want details- then they could jump to the draft-kohno for the 
specifics.
[PC] That said, I also see the point that a Standards Track document should 
only focus on the technical details and do not discuss such things.
[PC] I'm fine either way (remove or keep). I don't have any preference. I'm the 
document editor: I'll edit the document to whatever the WG prefers.

> 2. I don't think it is good to categorize into "traditional mode" and 
> "enhanced mode" (note that I am not saying that an operator does not 
> have a choice in what it wants to deploy - it's just that the 
> categorization itself is strange), though that's not technically critical.

[PC] As the I-D states
"   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground."
[PC] Since 2017 the wg guidance/consensus was to have these two modes for that 
reason above.

> 3. draft-murakami-dmm-user-plane-message-encoding should be a 
> normative reference.

[PC] I believe it's fine as an informative reference. One could implement this 
draft without draft-murakami. (While I agree with you that it will be common to 
implement both)

Zzh> Let me take one step back.
Zzh> This spec includes an option where SRv6 encapsulation/decapsulation based 
on N2/N4-signaled GTP-U parameters, 
so I thought there must be a spec about how the GTP-U header fields are encoded 
in SRv6. If draft-murakami is that draft, then it must be a normative 
reference. If draft-murakami is not that draft, then either all details need to 
be spelled out in this document, or some other document should be referenced 
(normatively).
Zzh> It seems that you're saying draft-murakmi is a separate/parallel thing. If 
so, which spec talks about how the GTP extension headers, sequence number, 
N-PDU number are encoded? If those are not expected to be used/supported, it 
needs to be pointed out.
[PC2] None of those additional GTP-U parameters are included in the SRv6 
encapsulation defined in this document. The N2/N4-signaled GTP-U parameters are 
combined with a local policy to steer on a SID list. If you want to encode the 
additional parameters, then this is out of the scope of this document. 
Informative reference to draft-murakami provides one possible encoding. 

+   0-2 3   4   5   6   7   8-1516-23   24-31
0   Version Protocol type   ReservedExtension Header Flag   
Sequence Number FlagN-PDU Number Flag   Message TypeMessage length
32  TEID
64  Sequence number N-PDU numberNext extension header type

>
> Specific outstanding technical comments:
>
> 4. 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 
> 

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Joel,

What this draft is doing is defining the building blocks for a mobility 
architecture with SRv6. The building blocks are the new SRv6 behaviors for the 
dataplane.
IETF is providing the tool. If 3GPP wishes to adopt it in their specifications, 
it is up to them to do it. But this document does not change any 3GPP 
architecture.

Cheers,
Pablo.

-Original Message-
From: Joel M. Halpern  
Sent: miércoles, 21 de julio de 2021 19:40
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

You asserted that certain needs can not be met without the changes to the 3GPP 
architecture this draft calls for.

Clearly, 3GPP does not agree as they have declined to make the changes you are 
asking for.

Equally, the IETF appears not to agree, as we have some approaches that appear 
to work without these changes, and are developing others.  (I admit this is an 
individual judgment, but then so is the problem kohno draft you are pointing 
at.)

More importantly, the IETF has no business changing the 3GPP architecture.  We 
object (have in the past, and expect would in the
future) when people change IETF architecturse externally to the IETF. 
We owe other SDOs the same respect.

Yours,
Joel

On 7/21/2021 1:34 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Joel,
> 
> I believe the TEAS slicing framework is orthogonal and complementary to this. 
> This draft, and many other technologies around IETF, will benefit from the 
> slicing framework of TEAS.
> Nonetheless, the text below is one of the key motivations, but not the 
> only one. More details on the other key points in here: 
> draft-kohno-dmm-srv6mob-arch-04
> 
> Many thanks,
> Pablo.
> 
> -Original Message-
> From: Joel M. Halpern 
> Sent: miércoles, 16 de junio de 2021 0:03
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org
> Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Actually, assuming that the IETF TEAS network slicing definitions / framework 
> and follow-on work is successful, it should be quite possible to deliver 
> appropriate services (network sliced service based on IETF network slices) to 
> 3GPPP GTP encapsulated 5G traffic while using the GTP-U encapsulation.  SRv6 
> is likely to be one of several transport mechanisms available to do so.
> 
> So if the inability to do so is the premise of your document, it appears to 
> me that there is no need for the document.
> 
> Yours,
> Joel
> 
> PS: In fact, it is pretty clear that the needed services can be delivered 
> even now in conjunction with GTP.  The TEAS work will make managing and 
> coordinating that delivery interoperably easier.
> 
> On 6/15/2021 3:01 PM, Pablo Camarillo (pcamaril) wrote:
>> Hi Jeffrey,
>>
>> I've already provided one of the key motivations in my previous email. There 
>> is an operational challenge in the current mobility networks: there are no 
>> means to have a fine-granular SLA across both the mobile and the transport 
>> network. SRv6 is bridging this gap by integrating the underlay and the 
>> overlay control from the source node (either the gNB or the UPF).
>> I am not aware of any standardized solution that solves this problem.
>> Therefore, I disagree on your statement "the only benefit of 
>> SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints".
>>
>> Cheers,
>> Pablo.
>>
>> -Original Message-
>> From: Jeffrey (Zhaohui) Zhang 
>> Sent: lunes, 14 de junio de 2021 22:19
>> To: Pablo Camarillo (pcamaril) 
>> Cc: dmm@ietf.org
>> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
>>
>> Hi Pablo,
>>
>> As you have alluded to, we're not converging but that's ok.
>>
>> My point is not to write a draft about SRv6-transported-GTP-U (there is no 
>> need for such draft, just like we don't need another draft about 
>> "transporting foo" with SRv6). My point is that the only benefit of 
>> SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints.
>>
>> There are other details that need to be taken care of in the draft, which we 
>> have been discussing.
>>
>> Jeffrey
>>
>> -Original Message-
>> From: Pablo Camarillo (pcamaril) 
>> 
>> Sent: Monday, June 14, 2021 3:47 PM
>> To: Jeffrey (Zhaohui) Zhang 
>> Cc: dmm@ietf.org
>> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Jeffrey,
>>
>> Inline with [PC6]. Many thanks for your explicit answers.
>>
>> Cheers,
>> Pablo.
>>
>> -Original Message

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with PC5.

Thanks,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: miércoles, 21 de julio de 2021 23:34
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh4> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Wednesday, July 21, 2021 1:34 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with PC4.

Thanks!
(and apologize for the delay)

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 15 de junio de 2021 22:16
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh3> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 15, 2021 3:03 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 22:10
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:15 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 
5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the 
SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. 
But TEID is not present.. therefore writing gNB::TEID would be misleading. See 
my point?
Zzh2> I don't mean that TEID is present in a GTP-U header. It is part of the 
IPv6 address (used for DX2/4/6 purpose). Writing it as gNB::TEID emphasize that 
the TEID information is embedded in the address, just like why you use 
SRGW::TEID in some examples.
[PC3] The TEID is not present on the IPv6 address used for the End.DX2, DX4, 
DX6 SIDs.
Zzh3> Could you elaborate how DX2/4/6 is done if TEID (or its mapped value) is 
not in the IPv6 address? For example, how does the gNB know if a packet is for 
UE1 vs. UE2? The gNB does not look up the inner (UE) IP address when forwarding 
(that's whole point of DX2/4/6).
[PC4] The TEID value 1234 could be associated with the SID 
2001:db8:abcd:abcd::beef. But 1234 is not present. 1234 (and therefore 
2001:db8:abcd:abcd::beef may be shared) in the enhanced mode.
Zzh4> Let's say TEID 1234 is assigned to UE1 and TEID 2345 is assigned to UE2. 
I suppose two different associa

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Many thanks for the summary of the open items. 
See inline with [PC].

Cheers,
Pablo.

> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: miércoles, 14 de julio de 2021 21:56
> To: Sri Gundavelli (sgundave) ; Pablo Camarillo
> (pcamaril) 
> Cc: dmm@ietf.org
> Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-
> mobile-uplane-13
> 
> Hi,
> 
> Here is my summary.
> 
> General comments:
> 
> 1. There were some architecture discussions about SRv6-transporting-GTPu vs
> SRv6-replacing-GTPu. I understand that this document is about SRv6-replacing-
> GTPu and the other is out of scope. That's ok - but the draft should omit "3.
> Motivation" and just have an informational reference to draft-kohno-dmm-
> srv6mob-arch. In other words, defer the motivation discussion to the separate
> draft and just focus on technical details in this spec. BTW - I want to 
> clarify
> here that when I said "the only advantage of SRv6-replacing-GTPu is MTU
> savings" is *in comparison* to SRv6-transporting-GTPu.

[PC] I have mixed feelings about removing the Section 3(Motivation).
[PC] Stating a couple of paragraphs of motivation is useful to the reader, 
while -if they want details- then they could jump to the draft-kohno for the 
specifics.
[PC] That said, I also see the point that a Standards Track document should 
only focus on the technical details and do not discuss such things.
[PC] I'm fine either way (remove or keep). I don't have any preference. I'm the 
document editor: I'll edit the document to whatever the WG prefers.

> 2. I don't think it is good to categorize into "traditional mode" and 
> "enhanced
> mode" (note that I am not saying that an operator does not have a choice in
> what it wants to deploy - it's just that the categorization itself is 
> strange),
> though that's not technically critical.

[PC] As the I-D states
"   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground."
[PC] Since 2017 the wg guidance/consensus was to have these two modes for that 
reason above.

> 3. draft-murakami-dmm-user-plane-message-encoding should be a normative
> reference.

[PC] I believe it's fine as an informative reference. One could implement this 
draft without draft-murakami. (While I agree with you that it will be common to 
implement both)

> 
> Specific outstanding technical comments:
> 
> 4. 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] Replied in the other thread.

> 5. In 5.2.2, because of the END.DX2/4/6 behavior on gNB, the SID list and
> S1_out can't just simply use gNB. It must be gNB:TEID.

[PC] Replied in the other thread. TEID is not present. It is a specific SID 
instance.

> 6. I still don't agree with the aggregation statement in 5.2.3. Per 5.2.2 
> (and see
> #5 above), the gNB does END.DX2/4/6 so per-UE SID (based on N2/4-signaled
> TEID) is needed. Otherwise, gNB needs to forward traffic based on inner
> header (UE address), which is different from both 5.2.2 and normal gNB
> behavior.

[PC] I don't follow your point. You have stated in previous emails that 
aggregation can be done, hence I don't understand which part of the statement 
you disagree with.
"Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 
replacing GTP-U."
https://mailarchive.ietf.org/arch/msg/dmm/Fv98rJ_PLyg5PNrQdnOa8g-1-EQ/

> 7. (this is new) 5.2.2 says " gNB's  control plane associates that session 
> from the
> UE(A) with the IPv6 address B.  gNB's control plane does a lookup on B to find
> the related SID list  ... When the packet arrives at UPF2, the
> active segment (U2::1) is an End.DT4/End.DT6/End.DT2U". End.DT4/6/2U
> requires specific tables for lookup (to go to different DNs in this case) and 
> the
> text is not clear on how that table is determined. Different UEs could be
> associated with different DNs but the N2 signaling can give the same IPv6
> address B. In GTP-U case, the UPF is able to associate different UEs to 
> different
> DNs based on TEID but for SRv6 different mechanism is needed (and missing
> for now). It could be that the control plane will give out different address 
> B for
> different DNs but that needs to be spelled out.
> 
> There may be other minor points/nits. For example, 5.1 says N2/N4 is
>

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Joel,

I believe the TEAS slicing framework is orthogonal and complementary to this. 
This draft, and many other technologies around IETF, will benefit from the 
slicing framework of TEAS.
Nonetheless, the text below is one of the key motivations, but not the only 
one. More details on the other key points in here: 
draft-kohno-dmm-srv6mob-arch-04

Many thanks,
Pablo.

-Original Message-
From: Joel M. Halpern  
Sent: miércoles, 16 de junio de 2021 0:03
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Actually, assuming that the IETF TEAS network slicing definitions / framework 
and follow-on work is successful, it should be quite possible to deliver 
appropriate services (network sliced service based on IETF network slices) to 
3GPPP GTP encapsulated 5G traffic while using the GTP-U encapsulation.  SRv6 is 
likely to be one of several transport mechanisms available to do so.

So if the inability to do so is the premise of your document, it appears to me 
that there is no need for the document.

Yours,
Joel

PS: In fact, it is pretty clear that the needed services can be delivered even 
now in conjunction with GTP.  The TEAS work will make managing and coordinating 
that delivery interoperably easier.

On 6/15/2021 3:01 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Jeffrey,
> 
> I've already provided one of the key motivations in my previous email. There 
> is an operational challenge in the current mobility networks: there are no 
> means to have a fine-granular SLA across both the mobile and the transport 
> network. SRv6 is bridging this gap by integrating the underlay and the 
> overlay control from the source node (either the gNB or the UPF).
> I am not aware of any standardized solution that solves this problem.
> Therefore, I disagree on your statement "the only benefit of 
> SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints".
> 
> Cheers,
> Pablo.
> 
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: lunes, 14 de junio de 2021 22:19
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> As you have alluded to, we're not converging but that's ok.
> 
> My point is not to write a draft about SRv6-transported-GTP-U (there is no 
> need for such draft, just like we don't need another draft about 
> "transporting foo" with SRv6). My point is that the only benefit of 
> SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints.
> 
> There are other details that need to be taken care of in the draft, which we 
> have been discussing.
> 
> Jeffrey
> 
> -Original Message-
> From: Pablo Camarillo (pcamaril) 
> Sent: Monday, June 14, 2021 3:47 PM
> To: Jeffrey (Zhaohui) Zhang 
> Cc: dmm@ietf.org
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Jeffrey,
> 
> Inline with [PC6]. Many thanks for your explicit answers.
> 
> Cheers,
> Pablo.
> 
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: lunes, 14 de junio de 2021 21:01
> To: Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> Let me also copy (zzh2>, zzh3>) and explicitly add (zzh4>) my answers below.
> 
> -Original Message-
> From: Pablo Camarillo (pcamaril) 
> Sent: Monday, June 14, 2021 2:22 PM
> To: Jeffrey (Zhaohui) Zhang 
> Cc: dmm@ietf.org
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Jeffrey,
> Inline with [PC5].
> Cheers,
> Pablo.
> 
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: lunes, 14 de junio de 2021 19:32
> To: Pablo Camarillo (pcamaril) ; 
> Pablo Camarillo (pcamaril) 
> Cc: dmm@ietf.org
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> If we look at the my original points:
> [PC5] Jeffrey, I believe both of your points have been answered. I've copied 
> the relevant answers for your reference here below with PC, PC2 and PC4. 
> Answer does not differ. If any clarification is needed on my previous 
> answers, please let me know. Thanks.
> 
> ---
> 1. Since GTP-U can be transported over SRv6, which can also make use of TE 
> capability and used for service programing (NFS chaining), the only real 
> difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header 
> is no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID 
> becomes part of the IPv6 address). With that,

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with PC4.

Thanks!
(and apologize for the delay)

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 15 de junio de 2021 22:16
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh3> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 15, 2021 3:03 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 22:10
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:15 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 
5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the 
SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. 
But TEID is not present.. therefore writing gNB::TEID would be misleading. See 
my point?
Zzh2> I don't mean that TEID is present in a GTP-U header. It is part of the 
IPv6 address (used for DX2/4/6 purpose). Writing it as gNB::TEID emphasize that 
the TEID information is embedded in the address, just like why you use 
SRGW::TEID in some examples.
[PC3] The TEID is not present on the IPv6 address used for the End.DX2, DX4, 
DX6 SIDs.
Zzh3> Could you elaborate how DX2/4/6 is done if TEID (or its mapped value) is 
not in the IPv6 address? For example, how does the gNB know if a packet is for 
UE1 vs. UE2? The gNB does not look up the inner (UE) IP address when forwarding 
(that's whole point of DX2/4/6).
[PC4] The TEID value 1234 could be associated with the SID 
2001:db8:abcd:abcd::beef. But 1234 is not present. 1234 (and therefore 
2001:db8:abcd:abcd::beef may be shared) in the enhanced mode.

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.

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

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 22:10
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:15 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 
5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the 
SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. 
But TEID is not present.. therefore writing gNB::TEID would be misleading. See 
my point?
Zzh2> I don't mean that TEID is present in a GTP-U header. It is part of the 
IPv6 address (used for DX2/4/6 purpose). Writing it as gNB::TEID emphasize that 
the TEID information is embedded in the address, just like why you use 
SRGW::TEID in some examples.
[PC3] The TEID is not present on the IPv6 address used for the End.DX2, DX4, 
DX6 SIDs. 

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.

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

Shouldn't U2::1 be U2::TEID? Even for the enhanced mode, TEID is still signaled 
and used - just that multiple UEs will share the same TEID.
[PC] I don't see the difference in between U2::1 and U2::TEID. It is a SID 
configured for a set of multiple UEs. Meaning, this is an illustration. So not 
sure I follow your point. Same as previous question. I think 2001:db8:: might 
be helpful in here...
Zzh> The AMF will signal different TEIDs for different UEs. While a local 
policy on SRGW could ignore the TEID, notice the following:
Zzh> 1. The UPF won't be able to distinguish those UEs, yet the use case could 
be that the UPF may need to put those UEs into different VPNs based on the TEID 
and now it can't any more. While the SRGB could have different policies to map 
different  to d

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

I've already provided one of the key motivations in my previous email. There is 
an operational challenge in the current mobility networks: there are no means 
to have a fine-granular SLA across both the mobile and the transport network. 
SRv6 is bridging this gap by integrating the underlay and the overlay control 
from the source node (either the gNB or the UPF).
I am not aware of any standardized solution that solves this problem.
Therefore, I disagree on your statement "the only benefit of 
SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints".

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: lunes, 14 de junio de 2021 22:19
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

As you have alluded to, we're not converging but that's ok.

My point is not to write a draft about SRv6-transported-GTP-U (there is no need 
for such draft, just like we don't need another draft about "transporting foo" 
with SRv6). My point is that the only benefit of SRv6-replacing-GTP-U is the 
MTU saving between SRv6 tunnel endpoints.

There are other details that need to be taken care of in the draft, which we 
have been discussing.

Jeffrey

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Monday, June 14, 2021 3:47 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC6]. Many thanks for your explicit answers.

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 14 de junio de 2021 21:01
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Let me also copy (zzh2>, zzh3>) and explicitly add (zzh4>) my answers below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Monday, June 14, 2021 2:22 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,
Inline with [PC5].
Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 14 de junio de 2021 19:32
To: Pablo Camarillo (pcamaril) ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

If we look at the my original points:
[PC5] Jeffrey, I believe both of your points have been answered. I've copied 
the relevant answers for your reference here below with PC, PC2 and PC4. Answer 
does not differ. If any clarification is needed on my previous answers, please 
let me know. Thanks.

---
1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA.
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ...

Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the 
appropriate SRH like in the SRv6-replacing-GTP-U case?
Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB 
does not get the SRv6 information from the AMF:
   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.
Zzh2> With that, even if you have a separate device to do the mapping, why 
can't that device do the same?
Zzh2> In other words, I still don’t see difference wrt SLA between 
SRv6-transported-GTP-U and SRv6-replacing-GTP-U.
[PC3] If the gNB also adds the SRH as you suggest, then you are changing the 
N3/N9 interface as well.

Zzh3> Wouldn't it be the other way around - SRv6-replacing-GTP-U is "changing 
the N3/N9 interface"? SRv6-transported-GTU-U is still the same N3/N9 interface, 
just that now they have SRH for traffic steering purpose.
[PC4] SRv6-replacing

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Thanks for confirming. I'll use that moving forward in the I-D.

Cheers,
Pablo.

-Original Message-
From: Kaippallimalil John  
Sent: lunes, 14 de junio de 2021 21:30
To: Pablo Camarillo (pcamaril) ; Jeffrey (Zhaohui) Zhang 

Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

L2 adjacency would be ok.
BR,
John

-Original Message-
From: Pablo Camarillo (pcamaril)  
Sent: Monday, June 14, 2021 2:25 PM
To: Kaippallimalil John ; Jeffrey (Zhaohui) 
Zhang 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi John,

Many thanks for detailed your answer.
Do you think it would be fair to use "L2 Adjacency" to refer to it in the draft?

Thanks,
Pablo.

-Original Message-
From: Kaippallimalil John  
Sent: lunes, 14 de junio de 2021 20:57
To: Pablo Camarillo (pcamaril) ; Jeffrey (Zhaohui) Zhang 

Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,
There is no IP adjacency between UE - gNB. 

It is a data link protocol and the user plane stack for adjacency is as in 
figure below (see TS 38.300. 6.6 L2 Data Flow).
IP flow is packaged in SDAP SDU, then in PDCP layer with RoHC, security & RLC 
with seg/ARQ. This RLC SDU is carried in a MAC transport block /multiplexed 
with other RLC SDUs.
Addressing, mapping and (de)multiplexing are handled by these layers and 
related control plane.

   UE  gNB
   [SDAP] <--> [SDAP]
   [PDCP] <--> [PDCP]
[RLC]   <-->   [RLC]
[PHY]  <-->   [PHY]

BR,
John 


-Original Message-
From: Pablo Camarillo (pcamaril)  
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John ; Jeffrey (Zhaohui) 
Zhang 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Indeed, the point was on the downlink, whether there is an IP adjacency in 
between the gNB and the UE. Many thanks for your answer. 
If it is not an IP adjacency, what is the type of the adjacency between the gNB 
and the UE?

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,
If the question is on IP adjacency in 3GPP, it is between the UE and UPF (PSA).

The gNB switches radio bearer (DRB) to IP flow (GTP-U) based on instructions 
from SMF (SMF --> AMF --> gNB).
The first router for the user's IP flow is the UPF.

An easy to read reference is RFC 6459 (refers to 4G, but the concepts in this 
case are similar) MME (instead-of SMF) provisions eNB (i-o gNB) to switch radio 
bearer to GTP-U bearer, and IP adjacency is between UE - PGW (i-o UPF).
Or 3GPP TS 23.501, 5.8 (and other sections) provide more details.

BR,
John
 

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) ; Jeffrey 
(Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

I have to say that we completely disagree on this one. Someone else will have 
to chime in if we want to get a conclusion 

Please see zzh> below.

-Original Message-
From: dmm  On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Jeffrey,

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

The IP adjacency to the UE is from the UPF, not from the gNB.
While gNB is an IP router, it is at the underlay. This is similar to the 
following situation:

Host1  EVPN PE1 - EVPN PE2  Host2

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. 
Host1 and EVPN PE1 are not IP adjacent.
[PC] Your examples assume PDU Session Type is L2. In which case indeed there is 
no IP Adjacency (there is only a L2 adjacency).
[PC] If the PDU Session Type is either IPv4 or IPv6, then I believe the 
interface at the gNB facing towards the UE is IP enabled, and therefore there 
exists an IP adjacency. Similarly, in your example above there would be an IP 
adjacency in between Host1 and PE; as both interfaces (Host1 towards PE1, and 
PE1 from Host1) are IP based.

Zzh> In the UE---gNB---UPF scenario, even for IPv4/6 PDU session, there is no 
IP adjacency between UE and gNB.
Zzh> In the EVPN

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with [PC6]. Many thanks for your explicit answers.

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: lunes, 14 de junio de 2021 21:01
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Let me also copy (zzh2>, zzh3>) and explicitly add (zzh4>) my answers below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Monday, June 14, 2021 2:22 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,
Inline with [PC5].
Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: lunes, 14 de junio de 2021 19:32
To: Pablo Camarillo (pcamaril) ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

If we look at the my original points:
[PC5] Jeffrey, I believe both of your points have been answered. I've copied 
the relevant answers for your reference here below with PC, PC2 and PC4. Answer 
does not differ. If any clarification is needed on my previous answers, please 
let me know. Thanks.

---
1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA.
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ...

Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the 
appropriate SRH like in the SRv6-replacing-GTP-U case?
Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB 
does not get the SRv6 information from the AMF:
   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.
Zzh2> With that, even if you have a separate device to do the mapping, why 
can't that device do the same?
Zzh2> In other words, I still don’t see difference wrt SLA between 
SRv6-transported-GTP-U and SRv6-replacing-GTP-U.
[PC3] If the gNB also adds the SRH as you suggest, then you are changing the 
N3/N9 interface as well.

Zzh3> Wouldn't it be the other way around - SRv6-replacing-GTP-U is "changing 
the N3/N9 interface"? SRv6-transported-GTU-U is still the same N3/N9 interface, 
just that now they have SRH for traffic steering purpose.
[PC4] SRv6-replacing-GTP-U is a change in the N3/N9 interface.

Zzh4> I said in zzh2> that with SRv6-transported-GTP-U, gNB could also add 
traffic steering via SRH - no different from SRv6-replacing-GTP-U. You said 
that's changing N3/N9, and I replied in zzh3> SRv6-replacing-GTP-U is changing 
the N3/N9, which you confirmed in [PC4]. Therefore, you have not really 
countered zzh2> above.
[PC6] There are no means to have fine-grained mapping of transport SLA with the 
mobility SLA. 
[PC6] Any transport protocol that encapsulates the gNB packet in the cell site 
router cannot achieve fine-grained SLA due to scaling limitations and control 
plane complexity.
[PC6] One option to solve this problem is to use SRv6 as a replacement to 
GTP-U, whereas the gNB encodes the SLA in the packet. This is what this draft 
is about.
[PC6] Certainly you write a new I-D to define a new N3/N9 interfaces that 
bundle together the overlay and underlay protocols (e.g. the gNB pushes the 
GTP-U header together with the MPLS label stack of the transport). I don't see 
the benefits of such approach, and this draft is not proposing anything close 
to it.

---
Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 
replacing GTP-U.
[PC4] I'm not aware that 29.281 allows aggregating N3/N9 traffic from different 
TEIDs into the same TEID -despite from any local policy-. That said, this I-D 
is not proposing a change in GTPU. Hence, any discussion on GTPU aggregation or 
change to allow it in GTP-U is out of the scope of this

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi John,

Many thanks for detailed your answer.
Do you think it would be fair to use "L2 Adjacency" to refer to it in the draft?

Thanks,
Pablo.

-Original Message-
From: Kaippallimalil John  
Sent: lunes, 14 de junio de 2021 20:57
To: Pablo Camarillo (pcamaril) ; Jeffrey (Zhaohui) Zhang 

Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,
There is no IP adjacency between UE - gNB. 

It is a data link protocol and the user plane stack for adjacency is as in 
figure below (see TS 38.300. 6.6 L2 Data Flow).
IP flow is packaged in SDAP SDU, then in PDCP layer with RoHC, security & RLC 
with seg/ARQ. This RLC SDU is carried in a MAC transport block /multiplexed 
with other RLC SDUs.
Addressing, mapping and (de)multiplexing are handled by these layers and 
related control plane.

   UE  gNB
   [SDAP] <--> [SDAP]
   [PDCP] <--> [PDCP]
[RLC]   <-->   [RLC]
[PHY]  <-->   [PHY]

BR,
John 


-Original Message-
From: Pablo Camarillo (pcamaril)  
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John ; Jeffrey (Zhaohui) 
Zhang 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Indeed, the point was on the downlink, whether there is an IP adjacency in 
between the gNB and the UE. Many thanks for your answer. 
If it is not an IP adjacency, what is the type of the adjacency between the gNB 
and the UE?

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,
If the question is on IP adjacency in 3GPP, it is between the UE and UPF (PSA).

The gNB switches radio bearer (DRB) to IP flow (GTP-U) based on instructions 
from SMF (SMF --> AMF --> gNB).
The first router for the user's IP flow is the UPF.

An easy to read reference is RFC 6459 (refers to 4G, but the concepts in this 
case are similar) MME (instead-of SMF) provisions eNB (i-o gNB) to switch radio 
bearer to GTP-U bearer, and IP adjacency is between UE - PGW (i-o UPF).
Or 3GPP TS 23.501, 5.8 (and other sections) provide more details.

BR,
John
 

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) ; Jeffrey 
(Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

I have to say that we completely disagree on this one. Someone else will have 
to chime in if we want to get a conclusion 

Please see zzh> below.

-Original Message-
From: dmm  On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Jeffrey,

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

The IP adjacency to the UE is from the UPF, not from the gNB.
While gNB is an IP router, it is at the underlay. This is similar to the 
following situation:

Host1  EVPN PE1 - EVPN PE2  Host2

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. 
Host1 and EVPN PE1 are not IP adjacent.
[PC] Your examples assume PDU Session Type is L2. In which case indeed there is 
no IP Adjacency (there is only a L2 adjacency).
[PC] If the PDU Session Type is either IPv4 or IPv6, then I believe the 
interface at the gNB facing towards the UE is IP enabled, and therefore there 
exists an IP adjacency. Similarly, in your example above there would be an IP 
adjacency in between Host1 and PE; as both interfaces (Host1 towards PE1, and 
PE1 from Host1) are IP based.

Zzh> In the UE---gNB---UPF scenario, even for IPv4/6 PDU session, there is no 
IP adjacency between UE and gNB.
Zzh> In the EVPN scenario above, there is no IP between Host1 and PE1 or 
between Host2 and PE2 either. It's just Ethernet. IP is between Host1 and Host2.

[PC] Also, for IPv4 or IPv6, Host1 and Host2 are not adjacent as per RFC1812, 
since the PE processes/forward the IP packet.
[PC] Please let me know whether you agree. It would be great if you can send me 
some pointer that I could read if you still think Im wrong.

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different 
from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Jeffrey, 
Inline with [PC5].
Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: lunes, 14 de junio de 2021 19:32
To: Pablo Camarillo (pcamaril) ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

If we look at the my original points:
[PC5] Jeffrey, I believe both of your points have been answered. I've copied 
the relevant answers for your reference here below with PC, PC2 and PC4. Answer 
does not differ. If any clarification is needed on my previous answers, please 
let me know. Thanks.

---
1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA.
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ...
---
Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 
replacing GTP-U.
[PC4] I'm not aware that 29.281 allows aggregating N3/N9 traffic from different 
TEIDs into the same TEID -despite from any local policy-. That said, this I-D 
is not proposing a change in GTPU. Hence, any discussion on GTPU aggregation or 
change to allow it in GTP-U is out of the scope of this draft.
---

Our exchanges had some clarifications on details, but I don't think the above 
points have been invalidated.
[PC5] Please let me know whether there is any clarification needed on top of 
the previous answers. 

Jeffrey

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Monday, June 14, 2021 1:16 PM
To: Jeffrey (Zhaohui) Zhang ; Pablo Camarillo (pcamaril) 

Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,
Inline with PC4.
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 18:00
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh3> below. I don't agree with the two [PC3] points.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:17 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 7 de junio de 2021 15:58
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:53 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Inline with PC2.
Many thanks and have a good weekend.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 16:46
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 1, 2021 7:23 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) ; 
dmm@ietf.org
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a 
much better understanding of the draft. Here my further 
observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. 
AMF/SMF/gNB/UPF will still use existing signa

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,
Inline with PC4.
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 18:00
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh3> below. I don't agree with the two [PC3] points.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 11, 2021 10:17 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 7 de junio de 2021 15:58
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:53 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Inline with PC2.
Many thanks and have a good weekend.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 16:46
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 1, 2021 7:23 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) ; 
dmm@ietf.org
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a 
much better understanding of the draft. Here my further 
observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. 
AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF 
will use either SRv6 or GTP-U tunnels based on local policy.
B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and 
two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 
respectively.
C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. 
This is covered in 5.3 using enhanced mode example, but can be applied to 
traditional mode as well.
D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to 
SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is 
covered in 5.4 and referred to as drop-in mode.

[PC] All the observations look good, with a side note on A: Future documents 
may define a new signaling.

Comments:

1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.

Zzh> Can you elaborate how they're achieved w/ SRv6 replacing GTP-U and not 
achieved with SRv6 transported GTP-U?
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA.
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ...
Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the 
appropriate SRH like in the SRv6-replacing-GTP-U case?
Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB 
does not get the SRv6 information from the AMF:
   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.
Zzh2> With that, even if you have a separate device to do the mapping, why 
can't that device do the same?
Zzh2> In other words, I still do

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

John,

Indeed, the point was on the downlink, whether there is an IP adjacency in 
between the gNB and the UE. Many thanks for your answer. 
If it is not an IP adjacency, what is the type of the adjacency between the gNB 
and the UE?

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang ; Pablo 
Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,
If the question is on IP adjacency in 3GPP, it is between the UE and UPF (PSA).

The gNB switches radio bearer (DRB) to IP flow (GTP-U) based on instructions 
from SMF (SMF --> AMF --> gNB).
The first router for the user's IP flow is the UPF.

An easy to read reference is RFC 6459 (refers to 4G, but the concepts in this 
case are similar) MME (instead-of SMF) provisions eNB (i-o gNB) to switch radio 
bearer to GTP-U bearer, and IP adjacency is between UE - PGW (i-o UPF).
Or 3GPP TS 23.501, 5.8 (and other sections) provide more details.

BR,
John
 

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) ; Jeffrey 
(Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

I have to say that we completely disagree on this one. Someone else will have 
to chime in if we want to get a conclusion 

Please see zzh> below.

-Original Message-
From: dmm  On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Jeffrey,

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

The IP adjacency to the UE is from the UPF, not from the gNB.
While gNB is an IP router, it is at the underlay. This is similar to the 
following situation:

Host1  EVPN PE1 - EVPN PE2  Host2

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. 
Host1 and EVPN PE1 are not IP adjacent.
[PC] Your examples assume PDU Session Type is L2. In which case indeed there is 
no IP Adjacency (there is only a L2 adjacency).
[PC] If the PDU Session Type is either IPv4 or IPv6, then I believe the 
interface at the gNB facing towards the UE is IP enabled, and therefore there 
exists an IP adjacency. Similarly, in your example above there would be an IP 
adjacency in between Host1 and PE; as both interfaces (Host1 towards PE1, and 
PE1 from Host1) are IP based.

Zzh> In the UE---gNB---UPF scenario, even for IPv4/6 PDU session, there is no 
IP adjacency between UE and gNB.
Zzh> In the EVPN scenario above, there is no IP between Host1 and PE1 or 
between Host2 and PE2 either. It's just Ethernet. IP is between Host1 and Host2.

[PC] Also, for IPv4 or IPv6, Host1 and Host2 are not adjacent as per RFC1812, 
since the PE processes/forward the IP packet.
[PC] Please let me know whether you agree. It would be great if you can send me 
some pointer that I could read if you still think Im wrong.

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different 
from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet below the IP, but a 
lower layer consisting of one segment being PDCP (3G case at least) and the 
other segment being GTP-U. I could only find a 3G picture here: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Ffigure%2F3GPP-protocol-stack-see-9_fig1_224357167data=04%7C01%7Ckjohn%40futurewei.com%7C456f17a4ee40443db5bb08d92cf40938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637590248940170467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bxnRyzjBodb%2BBYJLGTt6lyznfGugXeU4ywY6ukgNVrQ%3Dreserved=0.
Zzh> Jeffrey

[PC] Many thanks.

Jeffrey

-Original Message-----
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey,

Why do you say there is no IP adjacency from gNB to UE?
In the downlink, the gNB receives an IP packet from the UPF destined to itself. 
The gNB decapsulates such packet, and forwards the inner-exposed packet to the 
UE. Assuming the inner-exposed packet is IPv4, in such case the IPv4 
Destination Address is the one of the UE.

RFC1812: "Adjacent - reachable without going through any IP routers"

As far as I know, there is no IP router in b

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey, 

Inline with [PC3].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 7 de junio de 2021 15:58
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:53 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Inline with PC2.
Many thanks and have a good weekend.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 16:46
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 1, 2021 7:23 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) ; 
dmm@ietf.org
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a 
much better understanding of the draft. Here my further 
observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. 
AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF 
will use either SRv6 or GTP-U tunnels based on local policy.
B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and 
two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 
respectively.
C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. 
This is covered in 5.3 using enhanced mode example, but can be applied to 
traditional mode as well.
D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to 
SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is 
covered in 5.4 and referred to as drop-in mode.

[PC] All the observations look good, with a side note on A: Future documents 
may define a new signaling.

Comments:

1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.

Zzh> Can you elaborate how they're achieved w/ SRv6 replacing GTP-U and not 
achieved with SRv6 transported GTP-U?
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA.
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ...
Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the 
appropriate SRH like in the SRv6-replacing-GTP-U case?
Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB 
does not get the SRv6 information from the AMF:
   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.
Zzh2> With that, even if you have a separate device to do the mapping, why 
can't that device do the same?
Zzh2> In other words, I still don’t see difference wrt SLA between 
SRv6-transported-GTP-U and SRv6-replacing-GTP-U.
[PC3] If the gNB also adds the SRH as you suggest, then you are changing the 
N3/N9 interface as well. 

[PC2] By the way, the limitations of SRv6 transported GTP-U are also present in 
the Drop-in mode of this document.

[PC] Actually you have a lot more of motivation in this document: 
draft-kohno-dmm-srv6mob-arch-04

Zzh> I had similar comments in that thread.

2. Besides the TEID, there are other parameters in the GTP-U header. How those 
are represented in the SRv6 header needs to be defined.
[PC] dra

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Jeffrey,

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

The IP adjacency to the UE is from the UPF, not from the gNB.
While gNB is an IP router, it is at the underlay. This is similar to the 
following situation:

Host1  EVPN PE1 - EVPN PE2  Host2

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. 
Host1 and EVPN PE1 are not IP adjacent.
[PC] Your examples assume PDU Session Type is L2. In which case indeed there is 
no IP Adjacency (there is only a L2 adjacency).
[PC] If the PDU Session Type is either IPv4 or IPv6, then I believe the 
interface at the gNB facing towards the UE is IP enabled, and therefore there 
exists an IP adjacency. Similarly, in your example above there would be an IP 
adjacency in between Host1 and PE; as both interfaces (Host1 towards PE1, and 
PE1 from Host1) are IP based.
[PC] Also, for IPv4 or IPv6, Host1 and Host2 are not adjacent as per RFC1812, 
since the PE processes/forward the IP packet.
[PC] Please let me know whether you agree. It would be great if you can send me 
some pointer that I could read if you still think Im wrong.
[PC] Many thanks.

Jeffrey

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey,

Why do you say there is no IP adjacency from gNB to UE?
In the downlink, the gNB receives an IP packet from the UPF destined to itself. 
The gNB decapsulates such packet, and forwards the inner-exposed packet to the 
UE. Assuming the inner-exposed packet is IPv4, in such case the IPv4 
Destination Address is the one of the UE.

RFC1812: "Adjacent - reachable without going through any IP routers"

As far as I know, there is no IP router in between the gNB and the UE. Can you 
please clarify?

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

---

Zzh4> gNB is certainly an IP device but its IP adjacency is in the "underlay" 
(transport network) not at the "overlay" (towards the UE).
[PC5] The End.DX4 behavior (or the others) are not limited or restricted by 
"underlay" vs "overlay" IP adjacencies. The behavior is the same: remove the 
encaps, forward on a particular IP adjacency (regardless of its type).
Zzh4> In the wireline/IETF VPN case, there is PE-CE IP adjacency. Traffic from 
CE is forwarded based on IP lookup in the VRF, whether the traffic to the CE 
requires IP lookup or not (i.e. whether per-CE or per-VPN label is used, or 
whether END.DT4/6/X is used).
Zzh4> In case of gNB, UE-gNB is not IP adjacency and traffic to/from a UE does 
not have IP lookup (based on the inner IP header) at the gNB.
-

As I pointed out in zzh4>, the point is that there is *no IP adjacency* between 
UE and gNB.
Practically, a device can implement the END.DX4/6 behavior to forward IP 
traffic over non-IP adjacencies. It's just that RFC8986 specifically calls out 
IP adjacencies. You may want to point it out and see if SR folks have any 
concerns.

Jeffrey

Juniper Business Use Only

Juniper Business Use Only

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

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on 
draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 
5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the 
SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. 
But TEID is not present.. therefore writing gNB::TEID would be misleading. See 
my point?

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.

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

Shouldn't U2::1 be U2::TEID? Even for the enhanced mode, TEID is still signaled 
and used - just that multiple UEs will share the same TEID.
[PC] I don't see the difference in between U2::1 and U2::TEID. It is a SID 
configured for a set of multiple UEs. Meaning, this is an illustration. So not 
sure I follow your point. Same as previous question. I think 2001:db8:: might 
be helpful in here...
Zzh> The AMF will signal different TEIDs for different UEs. While a local 
policy on SRGW could ignore the TEID, notice the following:
Zzh> 1. The UPF won't be able to distinguish those UEs, yet the use case could 
be that the UPF may need to put those UEs into different VPNs based on the TEID 
and now it can't any more. While the SRGB could have different policies to map 
different  to different U2::X and the UPF would rely on X to 
distinguish the associated VPNs, that requires lots of management burden to 
configure those policies on the SRGB. It is much simpler to just put the TEID 
in the IPv6 address behind the U2 locator. In the transport underlay you can 
still transport based only on the locator. On the UPF, you may have individual 
TEID specific routes, or you can have routes that aggregate on the TEID part to 
achieve aggregation - that is no worse than having those different policies on 
the SRGB. In summary, it is better to simply put TEID after the U2 locator.
[PC2] The SRGW only aggregates traffic that belongs to the same context. You do 
not aggregate traffic of different tenants. This is not stated explicitly in 
the draft. I think I can add that.
Zzh> 2. This kind of aggregation is actually native to the GTP-U method - the 
packets are transported only based on the UPF address - so it is not an 
advantage that S

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Inline with PC2.
Many thanks and have a good weekend.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: martes, 1 de junio de 2021 16:46
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, June 1, 2021 7:23 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) ; 
dmm@ietf.org
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a 
much better understanding of the draft. Here my further 
observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. 
AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF 
will use either SRv6 or GTP-U tunnels based on local policy.
B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and 
two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 
respectively.
C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. 
This is covered in 5.3 using enhanced mode example, but can be applied to 
traditional mode as well.
D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to 
SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is 
covered in 5.4 and referred to as drop-in mode.

[PC] All the observations look good, with a side note on A: Future documents 
may define a new signaling.

Comments:

1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.

Zzh> Can you elaborate how they're achieved w/ SRv6 replacing GTP-U and not 
achieved with SRv6 transported GTP-U?
[PC2] As documented in 5.2, the SID list imposed by the source node includes 
segments for traffic engineering, NFV, and the overlay creation -all within the 
context of one network slice-. All the intermediate nodes in the fabric are 
stateless, hence you achieve highly scalable SLA. 
[PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. 
Then the cell site router needs to do a mapping of GTP-U sessions to SLA 
policies. This implies that you need some mapping mechanism at the Cell Site 
Router, that needs to have state. The gNB will not have any control of the 
underlay path, ... 
[PC2] By the way, the limitations of SRv6 transported GTP-U are also present in 
the Drop-in mode of this document.

[PC] Actually you have a lot more of motivation in this document: 
draft-kohno-dmm-srv6mob-arch-04

Zzh> I had similar comments in that thread.

2. Besides the TEID, there are other parameters in the GTP-U header. How those 
are represented in the SRv6 header needs to be defined.
[PC] draft-murakami-dmm-user-plane-message-encoding-03

Zzh> That should be a normative reference then.
[PC2] I don't think any of those is required to implement the I-D. I could 
foresee an operator that is interested on this ID to also be interested on that 
one, but I don’t think this is a reason to add the normative reference..

3. I still think there is no need to define the traditional/enhanced mode (see 
my reasoning below).
4. Now it's not clear if the interworking mode (including the drop-in mode) is 
worth the trouble (see my reasoning at the end).
[PC] Answers to 3 and 4 below.

Let me expand on #3 above.

"5.1.  Traditional mode" focuses on the one-to-one mapping among (PDU session, 
GTP-U tunnel, SRv6 tunnel) and casually mentions "SID list only contains a 
single SID".
" 5.2.  Enhanced Mode" talks about two things: SID list for TE and service 
programing/chaining, and scalability improvement via aggregation.

5.2 says:

   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.

That means the use of SID list for TE and service programming is not per the 
mobile architecture, but purely per operator's choice [PC] Indeed. The operator 
is the one that decides whe

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Why do you say there is no IP adjacency from gNB to UE? 
In the downlink, the gNB receives an IP packet from the UPF destined to itself. 
The gNB decapsulates such packet, and forwards the inner-exposed packet to the 
UE. Assuming the inner-exposed packet is IPv4, in such case the IPv4 
Destination Address is the one of the UE. 

RFC1812: "Adjacent - reachable without going through any IP routers"

As far as I know, there is no IP router in between the gNB and the UE. Can you 
please clarify?

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

---

Zzh4> gNB is certainly an IP device but its IP adjacency is in the "underlay" 
(transport network) not at the "overlay" (towards the UE).
[PC5] The End.DX4 behavior (or the others) are not limited or restricted by 
"underlay" vs "overlay" IP adjacencies. The behavior is the same: remove the 
encaps, forward on a particular IP adjacency (regardless of its type).
Zzh4> In the wireline/IETF VPN case, there is PE-CE IP adjacency. Traffic from 
CE is forwarded based on IP lookup in the VRF, whether the traffic to the CE 
requires IP lookup or not (i.e. whether per-CE or per-VPN label is used, or 
whether END.DT4/6/X is used).
Zzh4> In case of gNB, UE-gNB is not IP adjacency and traffic to/from a UE does 
not have IP lookup (based on the inner IP header) at the gNB.
-

As I pointed out in zzh4>, the point is that there is *no IP adjacency* between 
UE and gNB.
Practically, a device can implement the END.DX4/6 behavior to forward IP 
traffic over non-IP adjacencies. It's just that RFC8986 specifically calls out 
IP adjacencies. You may want to point it out and see if SR folks have any 
concerns.

Jeffrey

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

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A) ->UPF2 maps the flow w/
 SID list 
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A) ->End with PSP
   gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just 
simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: 
would help? Because based on this comment and the one below, I can see there 
might be a point of confusion here.

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.

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

Shouldn't U2::1 be U2::TEID? Even for the enhanced mode, TEID is still signaled 
and used - just that multiple UEs will share the same TEID.
[PC] I don't see the difference in between U2::1 and U2::TEID. It is a SID 
configured for a set of multiple UEs. Meaning, this is an illustration. So not 
sure I follow your point. Same as previous question. I think 2001:db8:: might 
be helpful in here...

BTW, since you removed UPF1 in Figure 5, it's better to rename UPF2 to UPF1, 
and change U2 to U1.
[PC] I'm fine either way. Changed.

For 5.3.1.3, why is downlink considered stateless while uplink has some state? 
Aren't the same - just one converts GTP-U to SRv6 while the other does the 
opposite?
[PC] On the downlink, the SLA is provided by the source node UPF that has the 
state. Hence the SRGW is quite straightforward.
[PC] On the uplink, the SLA is provided by the SRGW, which needs to hold all 
the state.

5.3.2.1 has the following:

   When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
   Classifier rule for incoming traffic from the gNB, that steers the
   traffic into an SR policy by using the function H.M.GTP4.D.

The SRGW is not a 5G NF, so the "Uplink Classifier rule" does not have to be 
the following (draft-homma-dmm-5gs-id-loc-coexistence):

Uplink Classifier (ULCL):
   An ULCL is an UPF functionality that aims at diverting Uplink traffic, 
based on filter rules provided by SMF, towards Data Network (DN).

So, instead of ULCL, the SRGW could have an IPv4 route for the UPF address 
which steers the matching traffic to an SR policy with function H.M.GTP4.D. If 
that is done, then the following is not true:

   For the uplink traffic, the state at the SRGW is dedicated on a per
   UE/session basis according to an Uplink Classifier.  There is state
   for steering the different sessions in the form of an SR Policy.
   However, SR policies are shared among several UE/sessions.

Because we don't need per UE/session steering - we can just steer based on 
UPF's address (just like in IPv6 case). 
[PC] If you steer based on UPF address, then you cannot apply a different SLA 
to traffic from different UEs. Hence the need to have per UE/session steering.
[PC] Also, as a correction, the IPv6 case does NOT steer based on the UPF 
address. It leverages a BSID to perform remote steering.
It seems that the only reason ULCL is used here is just that we don't call an 
IPv4 address a SID - but that does not mean we can't use an IPv4 route to steer 
traffic into a policy (isn't it the same thing that we use an IPv6 route for an 
address that we call SID)?

5.3.3.  Extensions to the interworking mechanisms

   In this section we presented two mechanisms for interwor

Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) ; 
dmm@ietf.org
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a 
much better understanding of the draft. Here my further 
observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. 
AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF 
will use either SRv6 or GTP-U tunnels based on local policy.
B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and 
two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 
respectively.
C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. 
This is covered in 5.3 using enhanced mode example, but can be applied to 
traditional mode as well.
D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to 
SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is 
covered in 5.4 and referred to as drop-in mode.

[PC] All the observations look good, with a side note on A: Future documents 
may define a new signaling.

Comments:

1. Since GTP-U can be transported over SRv6, which can also make use of TE 
capability and used for service programing (NFS chaining), the only real 
difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is 
no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes 
part of the IPv6 address). With that, most of " 3.  Motivation" are not really 
applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining 
cannot be achieved with GTP-U.
[PC] Actually you have a lot more of motivation in this document: 
draft-kohno-dmm-srv6mob-arch-04
2. Besides the TEID, there are other parameters in the GTP-U header. How those 
are represented in the SRv6 header needs to be defined.
[PC] draft-murakami-dmm-user-plane-message-encoding-03
3. I still think there is no need to define the traditional/enhanced mode (see 
my reasoning below).
4. Now it's not clear if the interworking mode (including the drop-in mode) is 
worth the trouble (see my reasoning at the end).
[PC] Answers to 3 and 4 below.

Let me expand on #3 above.

"5.1.  Traditional mode" focuses on the one-to-one mapping among (PDU session, 
GTP-U tunnel, SRv6 tunnel) and casually mentions "SID list only contains a 
single SID".
" 5.2.  Enhanced Mode" talks about two things: SID list for TE and service 
programing/chaining, and scalability improvement via aggregation.

5.2 says:

   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.

That means the use of SID list for TE and service programming is not per the 
mobile architecture, but purely per operator's choice
[PC] Indeed. The operator is the one that decides whether traffic needs a 
particular SLA. As in wireline...
, and it can also be used for both traditional mode and SRv6-transported GTP-U 
tunnels - really nothing special to be limited to enhanced mode only. 
It is true that some gNB may not be able to put on an SRH, but that equipment 
limitation should not become a criteria - just like that for general SRv6 
(outside this mobile user plane context) we don't have "basic" vs. 
"advanced/enhanced" modes just because some devices cannot insert SRH.
[PC] The motivation behind traditional mode is:
"   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground."

Defining traditional/enhanced mode based on aggregation is more reasonable. 
However, consider the following aspects:

- Currently only up link traffic can benefit from aggregation, and that's only 
when the AMF provides the same  for multiple PDU sessions
- The same can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 
replacing GTP-U.
[PC] GTP-U does not allow that. Certainly you could go to 3GPP and change the 
specs to allow it, but as per today it is not allowed.

The reason the aggregation is not applicable to downlink traffic is because the 
gNB does not do IP lookup based on inner header. 
[PC] Indeed that is one option. That is new compared to today's mobile 
architecture. I don’t think its complex to implement though. End of the day 
we've done it for quite some time in wireline. Another option is to forward to 
a group of UEs and let the UE drop the packet based on the IPV6 DA.
Rather, downlink traffic forwarding on a gNB is purely based on TEID (whether 
it is in th

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with [PC5]. I believe this last answer with the two updated I-D revs 
addresses all your comments in this email. Let me know if this is not the case.

I will answer your other thread separately.

Many thanks,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: miércoles, 26 de mayo de 2021 14:25
To: Pablo Camarillo (pcamaril) 
Cc: dmm@ietf.org; Joel M. Halpern 
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see  zzh4> below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, May 21, 2021 5:40 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: dmm@ietf.org; Joel M. Halpern 
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey, Joel,
What this draft is doing is defining the building blocks for a mobility system 
with SRv6. The building blocks are the new SRv6 behaviors.
IETF is providing the tool. If 3GPP wishes to adopt it in their specifications, 
it is up to them to do it. But this document does not change any 3GPP 
architecture.

Jeffrey,
I've posted an updated revision (rev13) of this document based on the previous 
comments/feedback.
See answers to the remaining points inline with [PC4].
Many thanks for all your feedback.

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: miércoles, 19 de mayo de 2021 22:04
To: Pablo Camarillo (pcamaril) ; Joel M. Halpern 

Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

One can say "this solutions relies on VLAN which is outside the scope of this 
document", because VLAN is specified somewhere else.
This document relies on changed 3GPP architecture and control plane, yet I 
don't see that 3GPP will adopt those changes anytime soon. You mentioned 
another mobile architecture could adopt this, but I don't know if there is 
another mobile architecture. With that, I don't see how we can put this 
document on standard track at this time.

Of course, if you state that 3GPP architecture/control plane does not change at 
all, and a UPF/gNB uses SRv6 based on signaled GTP-U parameters autonomously 
per local policy, then it's a different situation.

A few zzh3> embedded below.

-Original Message-
From: Joel M. Halpern 
Sent: Wednesday, May 19, 2021 12:49 PM
To: Pablo Camarillo (pcamaril) ; Jeffrey (Zhaohui) Zhang 

Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


It is reasonable to say that control plane changes are out of scope for the 
document.

However, defining a data plane behavior that does not work with the existing 
control plane does require dealing somehow with the fact that this document 
changes the 3GPP architecture and control plane.  Even if it does not specify 
how those changes should be realized.

Yours,
Joel

On 5/19/2021 12:35 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Jeffrey,
>
> Inline with [PC3].
>
> Cheers,
> Pablo.
>
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: lunes, 17 de mayo de 2021 22:22
> To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> Please see zzh2 > below.
>
> -Original Message-
> From: Pablo Camarillo (pcamaril) 
> Sent: Friday, May 14, 2021 4:15 AM
> To: Jeffrey (Zhaohui) Zhang ; dmm@ietf.org
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> [External Email. Be cautious of content]
>
>
> Hi Jeffrey,
>
> Many thanks for your reply. Good to see some of your points are resolved now. 
> Answers to the remaining points below inline with [PC2].
>
> Cheers,
> Pablo.
>
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: miércoles, 5 de mayo de 2021 20:37
> To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
> Cc: 'spr...@ietf.org' 
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> A lot of my questions/confusion came from the fact that in many cases 
> described in this document, the gNB/UPF will use SRv6 in place of GTP-U based 
> on changed N2/N4. That was not clear to me because my understanding is that 
> 3GPP has *not* agreed on using SRv6 in place of GTP-U.
>
> [PC2] As stated in the draft "The user plane described in this document does 
> not depend on any specific architecture."
>
> Zzh2> Because many sections are based on changed N2/N4 interfaces, so this 
> document does depend on a changed architecture not yet approved by 3GPP, with 
> the exception of drop-in mode (which is transparent to 3GPP)?
> [PC3] As stated in the I-D, control plane

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey, Joel,
What this draft is doing is defining the building blocks for a mobility system 
with SRv6. The building blocks are the new SRv6 behaviors.
IETF is providing the tool. If 3GPP wishes to adopt it in their specifications, 
it is up to them to do it. But this document does not change any 3GPP 
architecture.

Jeffrey, 
I've posted an updated revision (rev13) of this document based on the previous 
comments/feedback.
See answers to the remaining points inline with [PC4].
Many thanks for all your feedback.

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: miércoles, 19 de mayo de 2021 22:04
To: Pablo Camarillo (pcamaril) ; Joel M. Halpern 

Cc: dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

One can say "this solutions relies on VLAN which is outside the scope of this 
document", because VLAN is specified somewhere else.
This document relies on changed 3GPP architecture and control plane, yet I 
don't see that 3GPP will adopt those changes anytime soon. You mentioned 
another mobile architecture could adopt this, but I don't know if there is 
another mobile architecture. With that, I don't see how we can put this 
document on standard track at this time.

Of course, if you state that 3GPP architecture/control plane does not change at 
all, and a UPF/gNB uses SRv6 based on signaled GTP-U parameters autonomously 
per local policy, then it's a different situation.

A few zzh3> embedded below.

-Original Message-
From: Joel M. Halpern 
Sent: Wednesday, May 19, 2021 12:49 PM
To: Pablo Camarillo (pcamaril) ; Jeffrey (Zhaohui) Zhang 

Cc: dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


It is reasonable to say that control plane changes are out of scope for the 
document.

However, defining a data plane behavior that does not work with the existing 
control plane does require dealing somehow with the fact that this document 
changes the 3GPP architecture and control plane.  Even if it does not specify 
how those changes should be realized.

Yours,
Joel

On 5/19/2021 12:35 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Jeffrey,
>
> Inline with [PC3].
>
> Cheers,
> Pablo.
>
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: lunes, 17 de mayo de 2021 22:22
> To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
> Subject: RE: [DMM] [spring] note: WGLC on 
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> Please see zzh2 > below.
>
> -Original Message-
> From: Pablo Camarillo (pcamaril) 
> Sent: Friday, May 14, 2021 4:15 AM
> To: Jeffrey (Zhaohui) Zhang ; dmm@ietf.org
> Subject: RE: [DMM] [spring] note: WGLC on 
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> [External Email. Be cautious of content]
>
>
> Hi Jeffrey,
>
> Many thanks for your reply. Good to see some of your points are resolved now. 
> Answers to the remaining points below inline with [PC2].
>
> Cheers,
> Pablo.
>
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> Sent: miércoles, 5 de mayo de 2021 20:37
> To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
> Cc: 'spr...@ietf.org' 
> Subject: RE: [DMM] [spring] note: WGLC on 
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> A lot of my questions/confusion came from the fact that in many cases 
> described in this document, the gNB/UPF will use SRv6 in place of GTP-U based 
> on changed N2/N4. That was not clear to me because my understanding is that 
> 3GPP has *not* agreed on using SRv6 in place of GTP-U.
>
> [PC2] As stated in the draft "The user plane described in this document does 
> not depend on any specific architecture."
>
> Zzh2> Because many sections are based on changed N2/N4 interfaces, so this 
> document does depend on a changed architecture not yet approved by 3GPP, with 
> the exception of drop-in mode (which is transparent to 3GPP)?
> [PC3] As stated in the I-D, control plane specification is out of the scope 
> of this document. So not sure I follow your point on N2/N4 above...
>
> I could be wrong on that, but if the understanding is correct, I do not think 
> IETF/DMM should standardize this. At most an experimental document to show 
> how IETF views SRv6 could be used for mobile user plane. The drop-in mode is 
> fine, but I am curious why bother have GWs messing with the packets, and what 
> are the security implications.
>
> I still need some help understanding the modes better.
>
> Please see zzh> below. I snipped some exchanges to focus remaining 
> questions/comments.
>
> -Original Message-
> From: Pablo Camarillo (pcamaril) 
> Sent: Tuesday, May 4, 2021 6:36 AM
> To: Jeffrey (Zhaohui) Zh

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: lunes, 17 de mayo de 2021 22:22
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh2 > below.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Friday, May 14, 2021 4:15 AM
To: Jeffrey (Zhaohui) Zhang ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey,

Many thanks for your reply. Good to see some of your points are resolved now. 
Answers to the remaining points below inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: miércoles, 5 de mayo de 2021 20:37
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Cc: 'spr...@ietf.org' 
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

A lot of my questions/confusion came from the fact that in many cases described 
in this document, the gNB/UPF will use SRv6 in place of GTP-U based on changed 
N2/N4. That was not clear to me because my understanding is that 3GPP has *not* 
agreed on using SRv6 in place of GTP-U.

[PC2] As stated in the draft "The user plane described in this document does 
not depend on any specific architecture."

Zzh2> Because many sections are based on changed N2/N4 interfaces, so this 
document does depend on a changed architecture not yet approved by 3GPP, with 
the exception of drop-in mode (which is transparent to 3GPP)?
[PC3] As stated in the I-D, control plane specification is out of the scope of 
this document. So not sure I follow your point on N2/N4 above...

I could be wrong on that, but if the understanding is correct, I do not think 
IETF/DMM should standardize this. At most an experimental document to show how 
IETF views SRv6 could be used for mobile user plane. The drop-in mode is fine, 
but I am curious why bother have GWs messing with the packets, and what are the 
security implications.

I still need some help understanding the modes better.

Please see zzh> below. I snipped some exchanges to focus remaining 
questions/comments.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, May 4, 2021 6:36 AM
To: Jeffrey (Zhaohui) Zhang ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey,

Many thanks for your review. We've posted an updated revision of the document 
(rev12). Comments inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: miércoles, 21 de abril de 2021 6:49
To: Erik Kline ; SPRING WG ; dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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.

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.
[PC] The example does talk about service programming (S1 is a VNF). Ack on the 
scalability, which is briefly mentioned but not explained in detail. I've added 
more on it to the document. Thanks.
Zzh> It seems to me that "service programming" and TE are both transparent; 
even for the "traditional" mode, the two functions can be applicable.
[PC2] It is different for the source node, who needs to encode a SID list into 
the packet.

Zzh2> Section 5.1 only talks about "there will be a unique SRv6 SID associated 
with each PDU Session" but does not talk SID list. If SID list is a key 
difference, it should be mentioned in 5.1 as well.
[PC3] Sure, we can mention it explicitly. 
Zzh2> Section 5.2 says:
   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.
Zzh2> I don't understand why the above can't be done for 5.1 as well. That's 
why I was asking why the SID list is a difference between the two modes.
[PC3] You could very well define another mode based on the traditional where 
you also do that.

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
   "Tradi

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Many thanks for your reply. Good to see some of your points are resolved now. 
Answers to the remaining points below inline with [PC2].

Cheers,
Pablo.

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: miércoles, 5 de mayo de 2021 20:37
To: Pablo Camarillo (pcamaril) ; dmm@ietf.org
Cc: 'spr...@ietf.org' 
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

A lot of my questions/confusion came from the fact that in many cases described 
in this document, the gNB/UPF will use SRv6 in place of GTP-U based on changed 
N2/N4. That was not clear to me because my understanding is that 3GPP has *not* 
agreed on using SRv6 in place of GTP-U.

[PC2] As stated in the draft "The user plane described in this document does 
not depend on any specific architecture." 

I could be wrong on that, but if the understanding is correct, I do not think 
IETF/DMM should standardize this. At most an experimental document to show how 
IETF views SRv6 could be used for mobile user plane. The drop-in mode is fine, 
but I am curious why bother have GWs messing with the packets, and what are the 
security implications.

I still need some help understanding the modes better.

Please see zzh> below. I snipped some exchanges to focus remaining 
questions/comments.

-Original Message-
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, May 4, 2021 6:36 AM
To: Jeffrey (Zhaohui) Zhang ; dmm@ietf.org
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]


Hi Jeffrey,

Many thanks for your review. We've posted an updated revision of the document 
(rev12). Comments inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: miércoles, 21 de abril de 2021 6:49
To: Erik Kline ; SPRING WG ; dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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.

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.
[PC] The example does talk about service programming (S1 is a VNF). Ack on the 
scalability, which is briefly mentioned but not explained in detail. I've added 
more on it to the document. Thanks.
Zzh> It seems to me that "service programming" and TE are both transparent; 
even for the "traditional" mode, the two functions can be applicable.
[PC2] It is different for the source node, who needs to encode a SID list into 
the packet. 

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.
[PC] Traditional mode is simply a replacement of GTP-U as overlay protocol by 
SRv6. This minimizes changes to the mobile architecture. The enhanced mode 
allows to have intermediate SIDs for TE and NFV, but also allows to aggregate 
several devices under the same SID -which improves scalability-. The 
differences are covered in Section 5.2.
Section 5.3 presents interworking mechanisms for the case whereas the N3 
interface is unmodified. The interworking mechanisms presented in 5.3 are 
applicable to both Traditional and Enhanced mode.

Zzh> About "This minimizes changes to the mobile architecture", I was assuming 
that it means the N2/N4 interface does not change and traditional  tuple is still  used in the control plane to identify a 
PDU session, but the gNB/UPF will map between the tuple (received on N2/N4) and 
SRv6 SID. Now it seems that N2/N4 are changed and GTP is not used at all. For 
that I don't think "this minimizes the changes to the mobile architecture".
[PC2] On the control plane you send an IPv6 address, which now will be an SRv6 
SID. In enhanced mode you need to pass a SID list of more than one SID, which 
needs modification on N2/N4 to be able to support it.
Zzh> On the other hand, the "drop-in" mode described later in 5.4 really 
"minimizes changes to the mobile architecture". Additionally, whatever mode it 
is (traditional/drop-in, enhanced w/ or w/o interworking), intermediate SIDs 
for TE/NFV should be applicable.
[PC2] Drop-in mode does not have any change on the mobile architecture. Indeed 
the mobile architecture is completely agnost

Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi Jeffrey,

Many thanks for your review. We've posted an updated revision of the document 
(rev12). Comments inline with [PC].

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: miércoles, 21 de abril de 2021 6:49
To: Erik Kline ; SPRING WG ; dmm@ietf.org
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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?
[PC] The only use-case so far for this behavior is DMM. Maybe in the future 
other use-case pops up, in which case the fact that this behavior is defined in 
an RFC coming from DMM doesn't preclude them from using it.

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.
[PC] The example does talk about service programming (S1 is a VNF). Ack on the 
scalability, which is briefly mentioned but not explained in detail. I've added 
more on it to the document. Thanks.

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.
[PC] Traditional mode is simply a replacement of GTP-U as overlay protocol by 
SRv6. This minimizes changes to the mobile architecture. The enhanced mode 
allows to have intermediate SIDs for TE and NFV, but also allows to aggregate 
several devices under the same SID -which improves scalability-. The 
differences are covered in Section 5.2. 
Section 5.3 presents interworking mechanisms for the case whereas the N3 
interface is unmodified. The interworking mechanisms presented in 5.3 are 
applicable to both Traditional and Enhanced mode.

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"?
[PC] Fixed. Thanks.

Any reason why Figure 3 omitted UPF1?
[PC] Two different examples. You do not need to have 2 UPFs always.

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?
[PC] The SR-routed is achieved using FlexAlgo. The gNB -since in this case is a 
legacy device- is not capable of adding an SRH to the packet; but the IPv6 
Destination Address is a binding SID that is steered in the network according 
to FlexAlgo, as explained in the line after the one you quote.

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?
[PC] As described in the beginning of section 5.3, the interworking mechanism 
are based on the introduction of an intermediate SR Gateway that maps GTP to 
SRv6.  The SRGW is not an anchor point. It could simply be a P4 programmable 
switch.

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.
[PC] The UPFs are SRv6 aware (and thus N4 interface as well). The gNB is the 
legacy device that still runs GTPU. This is explained at the beginning of the 
section.

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
   
   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)
  

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

[Pablo Camarillo (pcamaril)]

Hi Dirk,

Many thanks for the support and the very detailed review of the document. I’ve 
updated the document accordingly (rev12).

Note that I have not changed the “a SID list” into “an SID list” (RFC Editor 
criteria in RFC8986).

Many thanks!

Cheers,
Pablo.

From: dmm  On Behalf Of dirk.von-h...@telekom.de
Sent: martes, 20 de abril de 2021 17:30
To: sgundave=40cisco@dmarc.ietf.org
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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



___
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] IPR poll on draft-ietf-dmm-srv6-mobile-uplane-11

[Pablo Camarillo (pcamaril)]

Hi chairs,

I am not aware of any undisclosed IPR related to this document.

Thanks,
Pablo.

From: dmm  On Behalf Of Sri Gundavelli (sgundave)
Sent: miércoles, 7 de abril de 2021 19:59
To: dmm@ietf.org
Subject: [DMM] IPR poll on draft-ietf-dmm-srv6-mobile-uplane-11

Dear Authors,

We are required to ensure compliance with the IPR guidelines of the IETF.

Can each author please confirm that their direct, personal knowledge of any IPR 
related to this document has already been disclosed, in conformance with BCPs 
78 and 79?

Note that an answer is required from all authors of the document. The DMM list 
is added in CC for the sake of transparency.

Thanks
Sri




From: dmm mailto:dmm-boun...@ietf.org>> on behalf of "Sri 
Gundavelli (sgundave)" 
mailto:sgundave=40cisco@dmarc.ietf.org>>
Date: Wednesday, April 7, 2021 at 10:35 AM
To: "dmm@ietf.org" mailto:dmm@ietf.org>>
Subject: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

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



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

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

[Pablo Camarillo (pcamaril)]

Hi all,

We have posted a new revision of draft-ietf-dmm-srv6-mobile-uplane.
We have fixed several typos throughout the document and we have updated the 
SRv6 Endpoint Behavior pseudocodes to reuse the same format as in RFC8754 and 
net-pgm.

Please review and let us know your feedback.

Thanks,
Pablo.

-Original Message-
From: dmm  On Behalf Of internet-dra...@ietf.org
Sent: viernes, 19 de febrero de 2021 12:01
To: i-d-annou...@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-10.txt


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 Garvia
  Daniel Voyer
  Charles E. Perkins
Filename: draft-ietf-dmm-srv6-mobile-uplane-10.txt
Pages   : 32
Date: 2021-02-19

Abstract:
   This document shows the applicability of SRv6 (Segment Routing IPv6)
   to the user-plane of mobile networks.  The network programming nature
   of SRv6 accomplish mobile user-plane functions in a simple manner.
   The statelessness of SRv6 and its ability to control both service
   layer path and underlying transport can be beneficial to the mobile
   user-plane, providing flexibility, end-to-end network slicing and SLA
   control for various applications.  This document describes the SRv6
   mobile user plane.


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-10
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-10

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


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] I-D Action: draft-ietf-dmm-5g-uplane-analysis-04.txt

[Pablo Camarillo (pcamaril)]

Hannu,

> The study listed a number of issues why Srv6 is not considered suitable for 
> the user plane. Please review 3GPP TR 29.892 and take that into account in 
> the analysis.

That is an interesting reading of TR 29.892.

" 8.3 SRv6 user plane protocol (without GTP-U) 
...
The solution supports all the 3GPP architectural requirements for user plane 
specified in Rel-16 
...
CT4 could not reach consensus on the final assessment and conclusion for the 
SRv6 user plane protocol (without GTP-U) solution. A technical vote took place 
during CT4#93 (26-30 August 2019) with the following question and results:
Question: Do you want to standardize SRv6 user plane protocol (w/o GTP-U) as 
described in clause 6.2.2 of TR 29.892?
...
It was therefore concluded to not standardize the SRv6 user plane protocol 
(without GTP-U) solution within the scope of this study (i.e. based on stage 2 
requirements specified in Rel-16)."

Note that the fact that 3GPP voting decided not to standardize SRv6 as a 
replacement to GTP-U for the N9 interface in Release 16 does not imply that 
3GPP cannot standardize it in a later Release.
Also I don't recall any "number of issues why Srv6 is not considered suitable 
for the user plane" in TR29.892.

Thank you,
Pablo.

-Original Message-
From: dmm  On Behalf Of Flinck, Hannu (Nokia - FI/Espoo)
Sent: domingo, 15 de noviembre de 2020 20:33
To: dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-5g-uplane-analysis-04.txt

Hello authors of the draft-ietf-dmm-5g-uplane-analysis-04.txt draft,

As I have said earlier 3GPP CT4 as concluded the user plane study that the 
draft is indirectly referring through the liaison statements in the intro 
section.
The study listed a number of issues why Srv6 is not considered suitable for the 
user plane. Please review 3GPP TR 29.892 and take that into account in the 
analysis.

I also would like to note that the Rel 16 is completed and 3GPP is working on 
Rel 17.

Therefore the sentences like " The study description mentions that the study 
would be based on
   Release 16 requirement while only Release 15 specifications has been
   available now.  However we believe that to provide adequate
   information for 3GPP, we need to clearly understand what the current
   user plane protocol is in Release 15, and architectural requirements
   for the user plane." is very weird considering that you are addressing 
completed Release.

I cannot understand why and what is the benefit of such.

Best regards
Hannu

-Original Message-
From: dmm  On Behalf Of internet-dra...@ietf.org
Sent: Monday, November 2, 2020 5:31 PM
To: i-d-annou...@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-5g-uplane-analysis-04.txt


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   : User Plane Protocol and Architectural Analysis on 
3GPP 5G System
Authors : Shunsuke Homma
  Takuya Miyasaka
  Satoru Matsushima
  Daniel Voyer
Filename: draft-ietf-dmm-5g-uplane-analysis-04.txt
Pages   : 42
Date: 2020-11-02

Abstract:
   This document analyzes the mobile user plane protocol and the
   architecture specified in 3GPP 5G documents.  The analysis work is to
   clarify those specifications, extract protocol and architectural
   requirements and derive evaluation aspects for user plane protocols
   on IETF side.  This work is corresponding to the User Plane Protocol
   Study work on 3GPP side.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-04
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-5g-uplane-analysis-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-5g-uplane-analysis-04


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

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

Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

[Pablo Camarillo (pcamaril)]

Hi Uma et al,

Thank you for all the work on this document.

As described in the abstract this document defines two things:
In section 2 you describe a framework to map slices in mobile systems to slices 
in the transport network; while in section 3 you describe how a new transport 
network underlay routing mechanism, Preferred Path Routing, can be used in 
combination with this framework.

PPR (draft-chunduri-lsr-isis-preferred-path-routing and 
draft-chunduri-lsr-ospf-preferred-path-routing) was last presented in LSR WG at 
IETF102 if I recall correctly.
The WG highlighted issues with regards to the scalability of the proposal. 
https://datatracker.ietf.org/doc/minutes-102-lsr/
Further discussion took place at the LSR mailer and those scalability concerns 
on PPR remain unaddressed.
https://mailarchive.ietf.org/arch/msg/lsr/6TzBBkmq4hQkiqyBeuN7MMOtMs0/

In my opinion it would be good to either address the LSR scalability concerns 
on PPR, or perhaps move all PPR content (Section 3 and related appendix) into a 
separate document.
Given that PPR is unneeded to define the framework -core of the ID-; and both 
sections seem orthogonal, I believe splitting the document would be appropriate.

Thank you,
Pablo.

From: dmm  On Behalf Of Sri Gundavelli (sgundave)
Sent: viernes, 16 de octubre de 2020 20:50
To: Uma Chunduri ; dmm 
Cc: Luis M. Contreras ; Richard Li 
; Jeff Tantsura ; Praveen 
Muley ; Sridhar Bhaskaran 
Subject: Re: [DMM] New Version Notification for 
draft-clt-dmm-tn-aware-mobility-07.txt

WG – Please provide your inputs on this document. Authors have presented this 
earlier and like to get some feedback.

Sri


From: dmm mailto:dmm-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Friday, October 16, 2020 at 11:42 AM
To: dmm mailto:dmm@ietf.org>>
Cc: "Luis M. Contreras" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>,
 Praveen Muley mailto:praveen.mu...@nokia.com>>, Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>, Richard Li 
mailto:richard...@futurewei.com>>, Sridhar Bhaskaran 
mailto:sridh...@altiostar.com>>
Subject: Re: [DMM] New Version Notification for 
draft-clt-dmm-tn-aware-mobility-07.txt

Dear DMM experts,

This version is a refresh but all comments received (offline and during the 
presentation at IETF106) were addressed.

Any further comments/suggestions are most welcome.

--
Uma C.


On Mon, Sep 28, 2020 at 4:44 PM 
mailto:internet-dra...@ietf.org>> wrote:

A new version of I-D, draft-clt-dmm-tn-aware-mobility-07.txt
has been successfully submitted by Uma Chunduri and posted to the
IETF repository.

Name:   draft-clt-dmm-tn-aware-mobility
Revision:   07
Title:  Transport Network aware Mobility for 5G
Document date:  2020-09-28
Group:  Individual Submission
Pages:  28
URL:https://www.ietf.org/id/draft-clt-dmm-tn-aware-mobility-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility
Htmlized:   https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-07

Abstract:
   This document specifies a framework and mapping from slices in 5G
   mobile systems to transport slices in IP and Layer 2 transport
   networks.  Slices in 5G systems are characterized by latency bounds,
   reservation guarantees, jitter, data rates, availability, mobility
   speed, usage density, criticality and priority should be mapped to
   transport slice characteristics that include bandwidth, latency and
   criteria such as isolation, directionality and disjoint routes.
   Mobile slice criteria need to be mapped to the appropriate transport
   slice and capabilities offered in backhaul, midhaul and fronthaul
   connectivity segments between radio side network functions and user
   plane function (gateway).

   This document describes how mobile network functions map its slice
   criteria to identifiers in IP packets that transport segments use to
   grant transport layer services.  This is based on mapping between
   mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment
   Routing).  Applicability of this framework and a new transport
   network underlay routing mechanism, Preferred Path Routing (PPR),
   which brings slice properties and works with any underlying transport
   (L2, IPv4, SR and MPLS) is also discussed.





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.

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

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

[Pablo Camarillo (pcamaril)]

Hello all,

We have published a new revision of draft-ietf-dmm-srv6-mobile-uplane. 
This revision addresses the comments from Carlos. Many thanks Carlos for your 
thorough review!

Please review and comment.

Thank you,
Pablo.

-Original Message-
From: dmm  On Behalf Of internet-dra...@ietf.org
Sent: lunes, 13 de julio de 2020 12:25
To: i-d-annou...@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-09.txt


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 Garvia
  Daniel Voyer
  Charles E. Perkins
Filename: draft-ietf-dmm-srv6-mobile-uplane-09.txt
Pages   : 30
Date: 2020-07-13

Abstract:
   This document shows the applicability of SRv6 (Segment Routing IPv6)
   to the user-plane of mobile networks.  The network programming nature
   of SRv6 accomplish mobile user-plane functions in a simple manner.
   The statelessness of SRv6 and its ability to control both service
   layer path and underlying transport can be beneficial to the mobile
   user-plane, providing flexibility, end-to-end network slicing and SLA
   control for various applications.  This document describes the SRv6
   mobile user plane.


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-09
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-09

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


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

[Pablo Camarillo (pcamaril)]

Dear DMM,

We have just posted an updated revision of draft-ietf-dmm-srv6-mobile-uplane.
This revision removes sections 5.1.3 and 5.2.3 of the draft.

The authors are working on another update that addresses the comments received 
during IETF105. We hope to have this ready in the next few weeks giving the WG 
enough time to review before Singapore.

Many thanks,
Pablo (on behalf of the authors).



-Original Message-
From: dmm  on behalf of "internet-dra...@ietf.org" 

Reply to: "dmm@ietf.org" 
Date: Thursday, 26 September 2019 at 12:04
To: "i-d-annou...@ietf.org" 
Cc: "dmm@ietf.org" 
Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-06.txt


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 Garvia
  Daniel Voyer
  Charles E. Perkins
Filename: draft-ietf-dmm-srv6-mobile-uplane-06.txt
Pages   : 27
Date: 2019-09-26

Abstract:
   This document shows the applicability of SRv6 (Segment Routing IPv6)
   to the user-plane of mobile networks.  The network programming nature
   of SRv6 accomplish mobile user-plane functions in a simple manner.
   The statelessness of SRv6 and its ability to control both service
   layer path and underlying transport can be beneficial to the mobile
   user-plane, providing flexibility, end-to-end network slicing and SLA
   control for various applications.  This document describes the SRv6
   mobile user plane behavior and defines the SID functions for that.


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-06
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-06

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


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: WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

[Pablo Camarillo (pcamaril)]

+1. I support WGLC of this draft. The content simplification makes it easier to 
read.

Cheers,
Pablo.

From: dmm  on behalf of Akbar Rahman 

Date: Tuesday, 15 January 2019 at 15:37
To: "dmm@ietf.org" 
Subject: Re: [DMM] Fwd: WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

+1


I support progressing this draft.


Best Regards,


Akbar

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Daniel Nunes Corujo
Sent: Tuesday, January 15, 2019 6:14 AM
To: dmm@ietf.org
Subject: [DMM] Fwd: WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

Dear all,

I consider that this draft should also move forward.

Com os melhores cumprimentos / Best regards

Daniel Corujo
Instituto de Telecomunicações - Pólo de Aveiro
http://www.it.pt



Watch our VIDEO:
https://youtu.be/lI8DnmBnEtU
Internet Technology Letters Journal is accepting publications:


http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2476-1508



Begin forwarded message:

From: Sri Gundavelli (sgundave) mailto:sgund...@cisco.com>>
Date: Wed, Jan 9, 2019 at 7:43 PM
Subject: [DMM] WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11
To: dmm@ietf.org mailto:dmm@ietf.org>>



Folks – As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
draft-ietf-dmm-distributed-mobility-anchoring-11.

The document went through several revisions and there were good amount of 
reviews on 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/id/draft-ietf-dmm-distributed-mobility-anchoring-11.txt

The target status for this document is “Informational”.

Please post any comments/concerns on the draft.

Thanks!
Dapeng & Sri

___
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] WGLC on draft-ietf-dmm-pmipv6-dlif-03

[Pablo Camarillo (pcamaril)]

+1

I support WGLC for this draft. Experimental track seems to be a good choice as 
well for this draft.

Cheers,
Pablo.

From: dmm  on behalf of Akbar Rahman 

Date: Tuesday, 15 January 2019 at 15:34
To: "dmm@ietf.org" 
Subject: Re: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03

+1

I support progressing this document.  As mentioned by Sri, this document has 
good through several reviews already, and I think it is in good shape
.


Best Regards,


Akbar

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Moses, Danny
Sent: Tuesday, January 15, 2019 6:33 AM
To: dmm@ietf.org
Subject: Re: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03

Hi,

I support WGLC for this draft.

Danny

From: Sri Gundavelli (sgundave) mailto:sgund...@cisco.com>>
Date: Wed, Jan 9, 2019 at 7:43 PM
Subject: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03
To: dmm@ietf.org mailto:dmm@ietf.org>>

Folks – As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
https://www.ietf.org/id/draft-ietf-dmm-pmipv6-dlif-03.txt.

We have also made one key change to the document status, moving it from 
Standards Track to Experimental Track. We the chairs have talked to the authors 
and they are OK with this change. We are dong this as we are not sure about any 
potential vendor implementations and so we chose to keep this on experimental 
track.

The document went through several revisions and there were good amount of 
reviews on 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/id/draft-ietf-dmm-pmipv6-dlif-03.txt

The target status for this document is “Experimental”.

Please post any comments/concerns on the draft.


Thanks!
Dapeng & Sri


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

-
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Pablo Camarillo (pcamaril)]

I support the adoption of this draft as an informational document.
I believe this draft provides very useful information from a broad set of 3GPP 
documents that are not necessarily easy to find. Any future work on new mobile 
related technologies will leverage this. I also believe that IETF is the right 
audience for this draft.

Thanks,
Pablo.

From: dmm  on behalf of "Sri Gundavelli (sgundave)" 

Date: Wednesday, 14 November 2018 at 01:34
To: "dmm@ietf.org" 
Subject: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM 
WG document

Folks:

During IETF 102 and 103, the authors of the document, 
draft-hmm-dmm-5g-uplane-analysis.txt have provided the overview of this 
document. The chairs felt there is good amount of work that went into the 
document and the analysis has value. The document quality is very high. There 
was also generally good feedback and interest for the work from the community. 
We are therefore considering adopting this document as a DMM WG document, to be 
moved on Informational Standards track.

There were also few concerns/comments on the 1.) Relevance of this document to 
3GPP in the immediate time frame 2.) Archival Value of the document 3.) Target 
Audience  - IETF or 3GPP.
On #3, there was also a view that the document should be restructured to make 
it IETF focussed.  With this background, we would like to ask the WG to provide 
some feedback on their interest for this work. Please provide substantial 
comments as why this should be adopted, or why it should not be adopted. If 
there is interest, and if there are no other concerns from AD/IESG/Others, then 
we may take up this work at some point.

Draft Pointer: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-02


The adoption call will end on 4th of December, 2019.

Regards
Dapping & Sri
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] FW: New Version Notification for draft-camarillo-dmm-srv6-mobile-pocs-01.txt

[Pablo Camarillo (pcamaril)]

Hi all,

We have submitted a new revision of this draft with further details on the PoCs.

Thanks,
Pablo.

On 22/10/2018, 22:50, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-camarillo-dmm-srv6-mobile-pocs-01.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the
IETF repository.

Name:   draft-camarillo-dmm-srv6-mobile-pocs
Revision:   01
Title:  Segment Routing IPv6 for mobile user-plane PoCs
Document date:  2018-10-22
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-camarillo-dmm-srv6-mobile-pocs-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-camarillo-dmm-srv6-mobile-pocs/
Htmlized:   
https://tools.ietf.org/html/draft-camarillo-dmm-srv6-mobile-pocs-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-camarillo-dmm-srv6-mobile-pocs
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-camarillo-dmm-srv6-mobile-pocs-01

Abstract:
   This document describes the ongoing proof of concepts of
   [I-D.ietf-dmm-srv6-mobile-uplane] and their progress.


  


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.

The IETF Secretariat



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

Re: [DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

Tom, inline. [PC2]



Thanks,

Pablo.



On 18/07/2018, 18:57, "Tom Herbert"  wrote:



>

>In summary if you could address:

>

>

>

>1.  Section 5.1 Traditional mode (Tom’s comment on terminology and

>IP-in-IP with no relation to SR?)

>

>

>

>PC1: Tom, please read


>https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3

>

Pablo,



I'm not sure that's relevant to discussion on an encapsulation

dataplane.



PC2:

A node may receive a packet with an SRv6 SID in the DA without an

   SRH.  In such case the packet should still be processed by the

   Segment Routing engine.

PC2: This is relevant understanding how the encapsulation dataplane operates 
IMO.



  SIDs are 128 bit values that are in the IPv6 address 
space,

and if a SID is place in a destination IPv6 address then it must be

routable to a node in the network. Wrt encapsulation, if it's any more

complex than that, then I'm missing something fundamental about

segment routing.



>PC1: It might be IP-in-IP as long as the inner header is not Ethernet or

>Unstructured PDUs (3GPP PDU types).

>



If it's not IP-IP, then what is it? The draft states that in traditional 
mode:



PC2: If it is Ethernet or Unstructured, I strongly believe this is not IP-in-IP.



"gNB only adds an outer IPv6 header with IPv6 DA U1::1."



This implies that foo over IP can be used if there is a protocol

number for it (e.g. IPv[46]/IPv6, GRE/IPv6, MPLS/IPv6, etc.). But what

does this mean in the case of unstructured PDUs? How are those

encapsulated?



PC2: Unstructured PDUs uses T.Encaps.L2 and End.DX2 functions. IPv6/SRH(if more 
than one SID)/byte_stream. If its traditional mode -one SID- then 
IPv6/byte_stream.



Please clarify, or provide the reference to the exact format of

encapsulation protocols being used with SR.



PC2: The encapsulation protocol being used with SRv6 is defined in 
draft-ietf-6man-segment-routing-header which of course requires RFC8200.

PC2: The encapsulation/decapsulation procedures used in dmm-srv6-mobile-uplane 
are defined in draft-filsfils-srv6-network-programming.



>PC1: When its IP-in-IP the destination address is an SRv6 SID and is

>processed differently at the destination than an interface address. See

>4.8-4.12 of draft-filsfils-srv6-network-programming.

>

Okay, but I don't see how the protocol is processed changes the fact

(at least that I think is a fact) that the solution is using IP-IP, or

maybe foo-over-IP in some cases as above, as the encapsulation and

that is the on-the-wire protocol in use.



PC2: It depends how you understand what is an encapsulation. To me this is the 
on-the-wire byte-codification and its processing.

PC2: In this particular case of Traditional mode with IP PDUs and 
encapsulation, the on-the-wire codification is IPinIP, since the SRH is not 
needed, while the processing is SRv6. If the UPF does not support SRv6, then it 
will not be able to work. Because of this, referring to it as IPinIP is 
misleading.

PC2: Let me try to give you an analogy. A external packet arrives to an ILA 
network. The original IPv6 DA is translated as per ILA. What is the packet? Is 
it an IP packet or is it an ILA packet? To me this is an ILA packet, because if 
the source and destination UPFs are not ILA capable the overlay does not work.

PC2: For this reason, I would not call the above SRv6 example IPinIP. It needs 
SRv6 on the UPFs, hence calling it IPinIP does not reflect the requirement of 
running SRv6 on the destination UPF -which in my opinion is considerable to 
highlight-.



Tom




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

Re: [DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

Uma,

Inline. [PC1]
(Thanks for the clear list of points to address. It does help.)

Cheers,
Pablo.

From: Uma Chunduri 
Date: Wednesday, 18 July 2018 at 12:52
To: "Pablo Camarillo (pcamaril)" , Arashmid Akhavain 

Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)" 
, "spr...@ietf.org" 
Subject: RE: Comment on SRv6-mobile-userplane

Hi Pablo,

>As I already clarified in my previous email, the proposal of 
>draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
Great. Thanks.
>As I already said in my previous email, we will clarify this in the next 
>revision of the draft.
Sure.

Btw, you responded to Arash’s comments addressing me.

Some parts of the draft already maintained that independence with SRv6 features 
in underlay (for example Section 5.3).
In summary if you could address:


1.  Section 5.1 Traditional mode (Tom’s comment on terminology and IP-in-IP 
with no relation to SR?)

PC1: Tom, please read 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3
PC1: It might be IP-in-IP as long as the inner header is not Ethernet or 
Unstructured PDUs (3GPP PDU types).
PC1: When its IP-in-IP the destination address is an SRv6 SID and is processed 
differently at the destination than an interface address. See 4.8-4.12 of 
draft-filsfils-srv6-network-programming.


2.  Section 5.2 Enhanced mode. Here SR path steering features are used

PC1: The enhanced mode exemplifies the case where a given provider wants to 
leverage SR for the overlay (as in Traditional mode but with session 
aggregation -see next note-; but also SP wants to leverage SR for underlay 
control and service programming.
PC1: In such example, the gNB can steer incoming traffic into an SR policy that 
contains SID for these three things. The benefit of this use-case is that the 
provider achieves end-to-end network slicing, spanning N3, N6, N9 as well as 
the transport network.
PC1: Notice that there might be different cases
1.- Overlay with session aggregation
2.- Overlay with session aggregation and underlay TE
3.- Overlay with session aggregation, underlay TE and service programming
4.- Overlay with session aggregation and service programming

and not fully described what happens to TEID (as GTP is gone).
PC1: Enhanced mode uses PDU session aggregation. There is not a single TEID per 
PDU Session. Instead, several PDU Sessions are aggregated. The set of sessions 
aggregated are still identified by the SID (in 5.2.1 corresponds to SID U2::1)
PC1: Each set of aggregated sessions uses a different SRv6 SID.
PC1: This is the main difference in between traditional mode and enhanced mode.
PC1: The aggregation is similar for the other proposals discussed in 
draft-bogineni-dmm-optimized-mobile-user-plane


3.  And if TEID after GTP removal is encoded in each SID in the SRH or this 
is only specific to some PDU session as you indicated in your first email.

PC1: In the traditional mode, the TEID for each PDU Session is encoded as an 
SRv6 SID. This can be done by two means, either by directly encoding the TEID 
in the SRv6 SID, or by using a unique SRv6 SID for each TEID (one-to-one 
mapping in between SRv6 SID and TEID). (feedback is welcome on preferred option)
PC1: In the enhanced mode, several PDU sessions are aggregated. All the set of 
aggregated sessions share the same SRv6 SID. A different set of aggregated 
sessions uses a different SRv6 SID.

Thx!
--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

Uma,

As I already clarified in my previous email, the proposal of 
draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes 
>treat the traffic as normal SRv6 traffic.

The proposal of the draft requires that for example the UPFs are SRv6 capable. 
However, any transport network in between the two SRv6 UPFs does not need to be 
SRv6 capable. It just needs to forward IPv6 packets. This is defined in RFC8200.
Hence, it does not matter what underlay transport you use. It is independent.

Are you saying that the use of SRv6 in general forces the underlying say MPLS 
transport to convert to SRv6?

No. Its independent. Underlay can be anything.

As I already said in my previous email, we will clarify this in the next 
revision of the draft.

Thanks,
Pablo.

From: Uma Chunduri 
Date: Wednesday, 18 July 2018 at 11:50
To: Arashmid Akhavain , "Pablo Camarillo 
(pcamaril)" 
Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)" 
, "spr...@ietf.org" 
Subject: RE: Comment on SRv6-mobile-userplane

Arash,


In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain
Sent: Wednesday, July 18, 2018 9:18 AM



Hi Uma,
I am not sure if I understand your concern. In traditional mode, we encode the 
TEID into a SID. This is the mode that draft bogineni refers to as the simplest 
form of using SRv6 for the N9 interface.

[Uma]:  2 quick and minor corrections for the above first.

1.  “we encode the TEID into a SID”  ==> 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  
says “Note that in this mode the TEID is embedded in each SID.” (section 5.1.3 
confirms this)

2.  Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes 
>treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 
>in general forces the underlying say MPLS transport to convert to SRv6?

[Uma]:  The problem with removing GTP header and keeping the same in each SRH 
SIDs make the underlay specific to SRv6.
 Pablo’s below response says – “The Traditional mode is only 
offering GTP replacement for specific PDU sessions with complete independence 
from the transport network.”
I don’t see the draft text reflects this.




Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org<mailto:spr...@ietf.org>
Subject: RE: Comment on SRv6-mobile-userplane

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.


[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data 
path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a 
replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1


“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable node

Re: [DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

Tom,

Isn't the IPv6 flow label designed exactly to avoid that? Are you suggesting to 
use UDP to avoid using the flow label?

Cheers,
Pablo.

On 18/07/2018, 10:37, "Tom Herbert"  wrote:

One caveat to that is that some
intermediate nodes may want to do DPI into transport layer to get
ports for ECMP or other reasons, if that is desirable it would be easy
enough to alternatively use a UDP encapsulation-- either continue with
GTP or switch to a more generic one like GUE.

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

[DMM] Comment on SRv6-mobile-userplane

[Pablo Camarillo (pcamaril)]

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.

Hence, if an operator would like to have integration of the overlay and 
underlay (for end-to-end network slicing), he can have such integration. If 
this is not desired, the dmm-srv6-mobile-uplane proposal can work completely 
independently from the transport, as already documented in the draft.

I will check with the rest of co-authors of the draft to see whether we should 
clarify in the draft the independence from the transport network.

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

Re: [DMM] IETF102 - Call for agenda items

[Pablo Camarillo (pcamaril)]

Dear DMM WG chairs,

I would like to request a 10 minute slot for 
draft-camarillo-dmm-srv6-mobile-pocs-00.
This is a new I-D complementary to draft-ietf-dmm-srv6-mobile-uplane covering 
the related PoCs status.

Topic name: SRv6 Mobile UserPlane PoCs
Presenter name: Lyle Bertz
Time: 10min
Draft:  draft-camarillo-dmm-srv6-mobile-pocs-00

Many thanks,
Pablo.

On 06/06/2018, 17:04, "dmm on behalf of Sri Gundavelli (sgundave)" 
 wrote:

Folks - Gentle reminder. Please send your requests for agenda slots for
IETF 102. If you have already done so, you can ignore this. Please include
the following information.


  ---
  Topic Name:
  Presenter Name:
  Time:
  Draft Reference:
---




Sri




>
>-Original Message-
>From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Thursday, May 3, 2018 5:32 PM
>To: dmm@ietf.org
>Subject: [E] [DMM] IETF102 - Call for agenda items
>
>The DMM working group is planning to meet in IETF 102, week of 16th of
>July, 2018 at Montreal. We currently have requested for one meeting,
>which is a 2.5 hour slot.
>
>We realize in IETF101 we had many items with a fully packaged agenda, and
>could not allocate enough time for any of the topics. For this meeting,
>we want to avoid that problem by asking for an additional meeting slot,
>but we want to be sure there are enough items for discussion before we
>lock the resources.
>
>So, if you need a presentation slot, please send your request to the
>chairs (as a response to this email) with the following information. We
>still have time and so its not required that you need a published I-D,
>but do let us know in the next few days if you are planning to make a
>presentation. 
>
>
>  ---
>>Topic Name:
>>Presenter Name:
>>Time:
>>Draft Reference: (Optional)
>>---
>
>Regards
>Dapeng & Sri
>>>
>>
>
>___
>dmm mailing list
>dmm@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiS
>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=3YmCyVAoiC_
>ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY=AHrommWakT2klf1og05nny7we_JVQm8flSZ8ZZ7
>ASgw=

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

[Pablo Camarillo (pcamaril)]

Hello all,

We have just published a minor update to this I-D that clarifies several 
questions that came up on the mailing list.
Also, we have added an annex that covers the current implementations and PoC 
status.

Thanks,
Pablo (on behalf of the co-authors).


On 02/07/2018, 22:12, "dmm on behalf of internet-dra...@ietf.org" 
 wrote:


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 Garvia
  Daniel Voyer
  Charles E. Perkins
Filename: draft-ietf-dmm-srv6-mobile-uplane-02.txt
Pages   : 26
Date: 2018-07-02

Abstract:
   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to user-plane of mobile networks (N3 and N9 interfaces).  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-02
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-02

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


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] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

[Pablo Camarillo (pcamaril)]

Hi Kentaro,

You are right. For each PDU session type you will have a different instance of 
an End.M.GTP6.D SID. We can add a note in the next revision of the draft in 
case this is not clear.

Thank you.

Cheers,
Pablo.

From: dmm  on behalf of Kentaro Ebisawa 

Date: Wednesday, 4 April 2018 at 11:08
To: dmm 
Subject: [DMM] Next Header in End.M.GTP6.D 
(draft-ietf-dmm-srv6-mobile-uplane-01)

Hi,

In "6.2. End.M.GTP6.D", how would SR Gateway know if user packet inside GTP is 
IPv4 or IPv6?
I think this info is required to set newly added SRH.NextHeader field in step 
3~5.

My understanding is that information would be provided by the control plane, 
and if that's correct, should SR Gateway have 2 (or more) SIDs corresponding to 
the type of user packet and also inform gNB to use different SIDs (dstAddr) 
based on user packet type?
One could also have SID per TEID, but I'm not sure if that's a good design 
choice considering the effort to reduce state in network nodes.

Thanks,
--
Kentaro Ebisawa 
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] some test results of different network overlay methods

[Pablo Camarillo (pcamaril)]

Hi Tom,

Inline.

Cheers,
Pablo.
From: Tom Herbert <t...@quantonium.net>
Date: Sunday, 18 March 2018 at 16:28
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
Cc: dmm <dmm@ietf.org>, Uma Chunduri <uma.chund...@huawei.com>
Subject: Re: [DMM] some test results of different network overlay methods


On Sun, Mar 18, 2018, 1:40 PM Pablo Camarillo (pcamaril) 
<pcama...@cisco.com<mailto:pcama...@cisco.com>> wrote:

Hi Tom, Kalyani,



If the SR processing of the two SIDs is done by the end host, then I believe 
the results for SR are obviously not valid.

Pablo,

Why isn't this valid?

What is the use case of an end linux host performing decapsulation or End SID 
processing?  By the time a packet reaches a Linux host terminating TCP it will 
contain only a single IP destination address == the host terminating the TCP 
session.

I expect that the only valuable use case to measure is encapsulation or 
insertion, see the  performance results 
https://irtf.org/anrw/2017/anrw17-final3.pdf for insert and encap on Linux.

If the end host is processing two SIDs, it means that you are doing twice SR 
processing. You will have an extra ‘End’ function processing, which involves 
updating the DA to the next segment, doing an IP lookup and forwarding.
Then you will restart and do again the processing. Overall, you do twice SR 
processing.

For example if I send  10 sids to a destination, all of which terminate on that 
destination, it will have to do SR END function processing 10 times.  This is 
true but there is no practical reason to do this.

In practice when host A sends a packet with 2 SIDs, one will be to host B and 
the next to host C.  Only B will do END function processing, C will simply 
receive the packet.  Therefore while your test is accurate it has no practical 
use.






Also in all the hardware-based routing platforms for which we have done interop 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-interop-00#section-2, we 
have SRv6 running at linecard rate.



Note that I find this performance testing work interesting, and I’m willing to 
help you carry them. However, for next releases I would also consider 
leveraging projects like linux foundation fdio CSIT 
https://wiki.fd.io/view/CSIT/Description, in order to have a more methodical 
and accurate results (ILA has higher throughput than native IPv6 with a lower 
TPS).


To be clear, this is testing a real TCP stack and host terminating 
encapsulation (not just router performance). For this purpose the tests are 
methodical and accurate.
See above

The big difference in performance have a lot to do how well NICs deal with 
different encapsulations and EH in case of SR. The most interesting result, I 
think, is IPIP (and SR/IPIP) with drop in TPS. This indicates that device (in 
this case ixgbe) isn't getting 5-tuple hash for RSS. It's not parsing over 
headers to find ports for hash. Interestingly, it was able to parse into L4 
when just SR header is present. Capabilities for things like this will vary 
between NICs.

Indeed, this is very interesting. Thanks for pointing it out. I believe NICs 
providers will eventually fix this.

Tom




Thanks.



Cheers,

Pablo.


De:Tom Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>
Enviado:viernes, 16 de marzo de 2018 7:58 p. m.
Para:Uma Chunduri
Cc: dmm
Asunto: Re: [DMM] some test results of different network overlay methods

On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri 
<uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>> wrote:
> Great work, Thank you Kalyani & Tom.
>
> 2 quick questions:
>
> 1.  I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the 
> topology used. Do intermediate nodes handle these SIDs, with pointer update 
> in SRH?

Two hosts connected back to back. SR processing done by end host.

> 2.  Also for Geneve  - it's IP4 encap and VNI no TLVs?
>
No TLVs. GUE uses RCO extension. Other than that all the variants
should be out of the box with no options set. Encapsulations are
v4/v4, SRv6 and ILA are all IPv6.

I'll post the all the configuration scripts to github once I have some time.

Tom


> --
> Uma C.
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
> Sent: Friday, March 16, 2018 11:16 AM
> To: dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
> Subject: [DMM] some test results of different network overlay methods
>
>
> All:
>
> Here are some raw performance test results based on our understanding of the 
> different network overlay methods. We welcome discussion and comments.
>
> Kalyani and Tom
> ___
> dmm mailing list
> dmm@ietf.org<mailto:dmm@ietf.org>
> https://www.ietf.org/mailman/listinfo/dmm

__

Re: [DMM] some test results of different network overlay methods

[Pablo Camarillo (pcamaril)]

Hi Tom, Kalyani,



If the SR processing of the two SIDs is done by the end host, then I believe 
the results for SR are obviously not valid.



Also in all the hardware-based routing platforms for which we have done interop 
https://tools.ietf.org/html/draft-filsfils-spring-srv6-interop-00#section-2, we 
have SRv6 running at linecard rate.



Note that I find this performance testing work interesting, and I’m willing to 
help you carry them. However, for next releases I would also consider 
leveraging projects like linux foundation fdio CSIT 
https://wiki.fd.io/view/CSIT/Description, in order to have a more methodical 
and accurate results (ILA has higher throughput than native IPv6 with a lower 
TPS).



Thanks.



Cheers,

Pablo.


De:Tom Herbert 
Enviado:viernes, 16 de marzo de 2018 7:58 p. m.
Para:Uma Chunduri
Cc: dmm
Asunto: Re: [DMM] some test results of different network overlay methods

On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri  wrote:
> Great work, Thank you Kalyani & Tom.
>
> 2 quick questions:
>
> 1.  I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the 
> topology used. Do intermediate nodes handle these SIDs, with pointer update 
> in SRH?

Two hosts connected back to back. SR processing done by end host.

> 2.  Also for Geneve  - it's IP4 encap and VNI no TLVs?
>
No TLVs. GUE uses RCO extension. Other than that all the variants
should be out of the box with no options set. Encapsulations are
v4/v4, SRv6 and ILA are all IPv6.

I'll post the all the configuration scripts to github once I have some time..

Tom


> --
> Uma C.
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
> Sent: Friday, March 16, 2018 11:16 AM
> To: dmm 
> Subject: [DMM] some test results of different network overlay methods
>
>
> All:
>
> Here are some raw performance test results based on our understanding of the 
> different network overlay methods. We welcome discussion and comments.
>
> Kalyani and Tom
> ___
> 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

[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  on behalf of Satoru Matsushima 

Date: Tuesday, 6 March 2018 at 01:34
To: dmm 
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
宛先: >
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] SRv6 for Mobile User-Plane

[Pablo Camarillo (pcamaril)]

Hi Satoru,



Thank you for your detailed comments. Replies inline [PC].



Cheers,

Pablo.



On 27/02/2018, 05:46, "Satoru Matsushima"  wrote:

Pablo,



First of all, thank you for your thorough review on the draft, and concrete 
proposal to improve it.

I think I agree almost on the three proposals. Let me comment on some of 
your points.





> [...snip...]



>

> I believe its straightforward to support IPv4 UE traffic by doing SRv6 
with T.Encaps behavior. Hence, I think this should be documented in the draft.



Yes.

[PC]: I have proposed some text with the packet workflow in the github 
repository for this draft. Please review it.



> The encapsulation behavior should be the default one, both for IPv4 and 
IPv6 UE traffic. However, a specific provider is allowed to do SRH insertion 
within a controlled domain [draft-voyer-6man-extension-header-insertion-02] for 
UE IPv6 traffic.

> Also, in order to reduce overhead at the UPFs when using encapsulation, I 
would replace the End.B6 function for a new End.MAP function.

> For example, if we consider the following topology:

> UEgNBUPF1UPF2

>

> Then the uplink packet flow for the basic mode would look like this:

> UE_out: (A, Z)

> gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps  

> UPF1_out:  (gNB, U2::1) (A, Z) -> End.MAP

> UPF2_out:  (A, Z) -> End.DT

>

> The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.





So ‘End.MAP’ function you proposed looks that the dest address in outer 
header works as last SID in SRH but just one SID doesn’t require SRH in the 
packet over the wire. If it corrects, I think it’s a good idea. I’d appreciate 
if you can contribute text and pseudo code for End.MAP to the draft. I tend to 
replace basic mode with it.

[PC]: Your understanding is correct. I have added the pseudocode of this 
function in the github repository for this document.



>

> Notice that using encapsulation, if you compare it with today user-plane 
using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 
header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP).



That sounds make sense. I’ve studied and shared a comparison of total 
overhead size for various deployment cases. That study shows it as well.

[PC]: Yes. Your study is very complete and indeed it was showing the lower 
overhead of SRv6. Thank you for taking the time to elaborate it. I think it’s 
worth keeping your study.



>

> ===

>

> With respect to the aggregation mode, aside from using the encapsulation 
mode as described before, I would also like to add a note on the I-D on the 
fact that we can support the aggregation mode without changes in the N2 
interface:

> The current I-D for aggregation mode assumes that the gNB (uplink) has 
knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and 
so on. Even though the I-D does not describe how the gNB is retrieving this 
information, I would like to make a statement on the fact that there are two 
alternatives:

> A. The N2 interface is modified in order to signal a SID list to the gNB.

> B. The N2 interface is not modified. In this case, we signal through the 
N2 interface an SRv6 BindingSID, that the gNB is going to resolve into a SID 
list via an SDN controller either using PCEP, reverse DNS lookup or LISP.





Maybe you have seen End.B6 defined as L2-anchor function in the section of 
aggregate mode. I think that the current draft doesn’t cover the case of N2 
no-change. But I have to admit that the text need to be more clear to mention 
for that. Any text for it would be really welcome.

[PC]: Indeed, you are right. The current text is ambiguous. I have proposed 
some text clarifying this in the github repository for this draft.





>

> I’m aware that the I-D focuses on the user-plane, however I believe it’s 
important to state this alternatives since it simplifies the adoption and 
reduces impact in the existing mobile architectures (without going into the 
details on the mechanisms for each one of the alternatives of LISP, PCEP, 
reverse DNS-lookup).



I think that we are on the same page. Deploying srv6 for mobile user-plane 
provides programmability of data-path for not only existing style of mobility 
management, but also any other type of optimization logics from various 
aspects, such as ID-LOC, ETSUN for example.



[PC]: We are in the same page. SRv6 is providing the flexibility and 
scalability in the data-path. Then many other techniques as ID-LOC for example 
might leverage it in the future to build even more interesting stuff.



>

> ===

>

> On the other hand, the current I-D proposes a mechanism for stateless 
interworking with legacy access networks that doesn’t support SRv6 (SGW and/or 
eNB). This mechanism presented in the I-D is limited 

[DMM] SRv6 for Mobile User-Plane

[Pablo Camarillo (pcamaril)]

Hello authors, DMM,



I have reviewed your I-D on SRv6 for mobile user-plane and I would like to make 
some proposals. I have already discussed and brainstormed the details with some 
of the authors of the draft and they agree to this changes, however I would 
like to get the WG feedback on it.



Thank you,

Pablo.



I believe its straightforward to support IPv4 UE traffic by doing SRv6 with 
T.Encaps behavior. Hence, I think this should be documented in the draft.

The encapsulation behavior should be the default one, both for IPv4 and IPv6 UE 
traffic. However, a specific provider is allowed to do SRH insertion within a 
controlled domain [draft-voyer-6man-extension-header-insertion-02] for UE IPv6 
traffic.

Also, in order to reduce overhead at the UPFs when using encapsulation, I would 
replace the End.B6 function for a new End.MAP function.

For example, if we consider the following topology:

UEgNBUPF1UPF2



Then the uplink packet flow for the basic mode would look like this:

UE_out: (A, Z)

gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps  

UPF1_out:  (gNB, U2::1) (A, Z) -> End.MAP

UPF2_out:  (A, Z) -> End.DT



The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.



Notice that using encapsulation, if you compare it with today user-plane using 
IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 header), 
while GTP over IPv6 is using 56B (IPv6, UDP, GTP).



===



With respect to the aggregation mode, aside from using the encapsulation mode 
as described before, I would also like to add a note on the I-D on the fact 
that we can support the aggregation mode without changes in the N2 interface:

The current I-D for aggregation mode assumes that the gNB (uplink) has 
knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and 
so on. Even though the I-D does not describe how the gNB is retrieving this 
information, I would like to make a statement on the fact that there are two 
alternatives:

A. The N2 interface is modified in order to signal a SID list to the gNB.

B. The N2 interface is not modified. In this case, we signal through the N2 
interface an SRv6 BindingSID, that the gNB is going to resolve into a SID list 
via an SDN controller either using PCEP, reverse DNS lookup or LISP.



I’m aware that the I-D focuses on the user-plane, however I believe it’s 
important to state this alternatives since it simplifies the adoption and 
reduces impact in the existing mobile architectures (without going into the 
details on the mechanisms for each one of the alternatives of LISP, PCEP, 
reverse DNS-lookup).



===



On the other hand, the current I-D proposes a mechanism for stateless 
interworking with legacy access networks that doesn’t support SRv6 (SGW and/or 
eNB). This mechanism presented in the I-D is limited to IPv4/GTP legacy 
networks. I would like to propose a mechanism to support interworking with 
legacy gNBs that does not support SRv6 but do support IPv6/GTP.

The main benefit comes from the fact that we can leverage an SRv6 BindingSID to 
have remote classification and steering of the UE traffic over an SR policy 
[draft-filsfils-spring-segment-routing-policy].



In this scenario, I propose that we add the notion of an SR GW -as the current 
stateless interworking node in the I-D-. This SR GW can be either a software 
based platform -e.g. VPP- or any existing router -the mechanism is simple and 
can be supported in existing HW-. This SR GW receives through the control plane 
the SR policies and installs the required Binding SIDs.



Then, for any UE connecting to a gNB, the N2 interface is going to signal an 
IPv6 address and a TEID. However, the difference is that with this new 
mechanism the IPv6 address that we are going to signal is going to be an SRv6 
BindingSID instantiated at the SR GW.



The overall workflow is the following:



Uplink

Note: S1, S2 represent service functions and C1 represents a node for TE 
purposes

UE sends its packet (A, Z) on a specific wireless bearer to its gNB

gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID T 
(N2 interface unchanged)

gNB_out: (gNB, B) (GTP: TEID T) (A, Z)   ;; Interface N3 is 
unchanged

SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z)   ;; new End.GTP.UP

S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)

C1_out: (SRGW, U2::1) (A, Z)  ;; assuming 
PSP

UPF2_out:  (A, Z);; 
End.DT



Downlink

UPF2_in: (Z, A) 
  ;; UPF2 maps the flow with SID list 

UPF2_out:  (U2::1, C1) (gNB, SRGW::TEID, S1, SL=3) (Z, A)   ;;  T.Encaps

C1_out: (U2::1, S1) (gNB, SRGW::T, S1, SL=2) (Z, A)

S1_out: (U2::1, SRGW::TEID) (gNB, SRGW::T, S1, SL=1) (Z, A)

SR_GW: (SRGW, gNB)(GTP: TEID=T)(Z, A) ;; End.GTP.DN

gNB_out: (Z, A)

Re: [DMM] SRv6 for Mobile User-Plane

[Pablo Camarillo (pcamaril)]

(+ Charlie)

From: dmm <dmm-boun...@ietf.org> on behalf of "Pablo Camarillo (pcamaril)" 
<pcama...@cisco.com>
Date: Monday, 26 February 2018 at 21:05
To: "dmm@ietf.org" <dmm@ietf.org>
Cc: "Voyer, Daniel" <daniel.vo...@bell.ca>, "cf(mailer list)" <c...@cisco.com>, 
"Miya Kohno (mkohno)" <mko...@cisco.com>, "satoru.matsush...@g.softbank.co.jp" 
<satoru.matsush...@g.softbank.co.jp>
Subject: [DMM] SRv6 for Mobile User-Plane


Hello authors, DMM,



I have reviewed your I-D on SRv6 for mobile user-plane and I would like to make 
some proposals. I have already discussed and brainstormed the details with some 
of the authors of the draft and they agree to this changes, however I would 
like to get the WG feedback on it.



Thank you,

Pablo.



I believe its straightforward to support IPv4 UE traffic by doing SRv6 with 
T.Encaps behavior. Hence, I think this should be documented in the draft.

The encapsulation behavior should be the default one, both for IPv4 and IPv6 UE 
traffic. However, a specific provider is allowed to do SRH insertion within a 
controlled domain [draft-voyer-6man-extension-header-insertion-02] for UE IPv6 
traffic.

Also, in order to reduce overhead at the UPFs when using encapsulation, I would 
replace the End.B6 function for a new End.MAP function.

For example, if we consider the following topology:

UEgNBUPF1UPF2



Then the uplink packet flow for the basic mode would look like this:

UE_out: (A, Z)

gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps  

UPF1_out:  (gNB, U2::1) (A, Z) -> End.MAP

UPF2_out:  (A, Z) -> End.DT



The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.



Notice that using encapsulation, if you compare it with today user-plane using 
IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 header), 
while GTP over IPv6 is using 56B (IPv6, UDP, GTP).



===



With respect to the aggregation mode, aside from using the encapsulation mode 
as described before, I would also like to add a note on the I-D on the fact 
that we can support the aggregation mode without changes in the N2 interface:

The current I-D for aggregation mode assumes that the gNB (uplink) has 
knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and 
so on. Even though the I-D does not describe how the gNB is retrieving this 
information, I would like to make a statement on the fact that there are two 
alternatives:

A. The N2 interface is modified in order to signal a SID list to the gNB.

B. The N2 interface is not modified. In this case, we signal through the N2 
interface an SRv6 BindingSID, that the gNB is going to resolve into a SID list 
via an SDN controller either using PCEP, reverse DNS lookup or LISP.



I’m aware that the I-D focuses on the user-plane, however I believe it’s 
important to state this alternatives since it simplifies the adoption and 
reduces impact in the existing mobile architectures (without going into the 
details on the mechanisms for each one of the alternatives of LISP, PCEP, 
reverse DNS-lookup).



===



On the other hand, the current I-D proposes a mechanism for stateless 
interworking with legacy access networks that doesn’t support SRv6 (SGW and/or 
eNB). This mechanism presented in the I-D is limited to IPv4/GTP legacy 
networks. I would like to propose a mechanism to support interworking with 
legacy gNBs that does not support SRv6 but do support IPv6/GTP.

The main benefit comes from the fact that we can leverage an SRv6 BindingSID to 
have remote classification and steering of the UE traffic over an SR policy 
[draft-filsfils-spring-segment-routing-policy].



In this scenario, I propose that we add the notion of an SR GW -as the current 
stateless interworking node in the I-D-. This SR GW can be either a software 
based platform -e.g. VPP- or any existing router -the mechanism is simple and 
can be supported in existing HW-. This SR GW receives through the control plane 
the SR policies and installs the required Binding SIDs.



Then, for any UE connecting to a gNB, the N2 interface is going to signal an 
IPv6 address and a TEID. However, the difference is that with this new 
mechanism the IPv6 address that we are going to signal is going to be an SRv6 
BindingSID instantiated at the SR GW.



The overall workflow is the following:



Uplink

Note: S1, S2 represent service functions and C1 represents a node for TE 
purposes

UE sends its packet (A, Z) on a specific wireless bearer to its gNB

gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID T 
(N2 interface unchanged)

gNB_out: (gNB, B) (GTP: TEID T) (A, Z)   ;; Interface N3 is 
unchanged

SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z)   ;; new End.GTP.UP

S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)

C1_out: (SRGW, U2::1) (A, Z)  ;; assuming