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 <[email protected]> Sent: sábado, 31 de diciembre de 2022 2:23 To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Sri Gundavelli (sgundave) <[email protected]>; Sri Gundavelli (sgundave) <[email protected]> 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. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
