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

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

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 <[e-mail]> 
Sent: sábado, 31 de diciembre de 2022 2:23
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Sri Gundavelli (sgundave) <[e-mail]>; Sri Gundavelli (sgundave) <[e-mail]>
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 behaviors represented as SRv6 segments would be part of a slice" as it is not normatively defined, and it should be up to other document to define that.