Hi Zafar, et al., I apologize for the unintended confusion but when I've said that I'll review the updates I was under the impression (self-imposed) that a new version has been published already. I'll be glad to review the updates in the working version and share my notes if you can kindly send it my way. Or I can wait for it to be published. Let me know what works for you best.
Regards, Greg On Fri, Feb 21, 2020 at 5:07 PM Zafar Ali (zali) <z...@cisco.com> wrote: > Hi Greg, > > > > I went back to your comments to verify the latest version in the GitHub > addresses them (as marked by [ZA]). > > This is with the exception of your question on handling of BFD control > packets or STAMP test packets. Please see [ZA2] for the specifics. > > > > One thing that stands out from your review comments is that we need a > sub-section on the illustration on the use of O-bit. We are in the process > of adding the O-bit usage illustration. Please see [ZA2] for more details.. > > > > Many thanks for taking an offline call, earlier. I will reach-out to you > again to discuss your comments. > > > > Thanks > > > > Regards … Zafar > > > > *From: *"Zafar Ali (zali)" <z...@cisco.com> > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky <gregimir...@gmail.com>, Ole Troan <otr...@employees.org > > > *Cc: *SPRING WG <spring@ietf.org>, 6man WG <i...@ietf.org>, 6man Chairs < > 6man-cha...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com> > *Subject: *Re: [spring] 6man w.g. last call for > <draft-ietf-6man-spring-srv6-oam> > > > > Hi Greg, > > > > Many thanks for your detailed comments. Much appreciated. > > > > Please see comments in-line and how the new version addresses your > comments. > > I also look forward to our offline discussion on Friday. > > > > Please note we have been also maintaining the latest version of the draft > in the 6man-Github. > > > > Thanks > > > > Regards … Zafar > > > > *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Thursday, December 5, 2019 at 5:22 PM > *To: *Ole Troan <otr...@employees.org> > *Cc: *SPRING WG <spring@ietf.org>, 6man WG <i...@ietf.org>, 6man Chairs < > 6man-cha...@ietf.org> > *Subject: *Re: [spring] 6man w.g. last call for > <draft-ietf-6man-spring-srv6-oam> > > > > Dear Authors, et al., > > please find my comments, as WG LC comments, questions to this document > below. > > - The Abstract and Introduction describe the document as "defines > building blocks for Operations, Administration, and Maintenance (OAM) in > Segment Routing Networks with IPv6 Dataplane (SRv6)". I believe it would be > helpful to demonstrate that the existing mechanisms used in IPv6 to > demultiplex and realize OAM functions, e.g., using the well-known > destination UDP port number, are not sufficient and require the > introduction of new methods, e.g., O bit in SRH. > > [ZA2] We are adding illustration on the use of the o-bit. > > [ZA] If you look at section 4 of the draft, it explains how existing > probing mechanisms are used and why extensions are needed. In the new > revision posted, we have added additional information on why the O-bit in > SRH is defined (for telemetry purpose). Please have a look at the latest > revision as we have tried to address your comment. > > - This document introduces the O-flag into SRH as the building block > for OAM in SR networks with IPv6 data plane. It appears that the functions > that are realized using the O-flag are already supported by the existing > OAM protocols that enable fault management (e.g., variations of Echo > Request/Reply, BFD) and performance monitoring (e.g., STAMP). > > [ZA2] We are adding illustration on the use of the o-bit. > > [ZA] The O-bit is for telemetry use. In the new revision posted, we have > added additional normative text on O-bit processing to clarify this point.. > Please have a look at the latest revision. > > - Also, the use of the new "building block for OAM" in SRv6 splits the > SR OAM suit into two functionally separate toolsets - one for SR-MPLS and > another for SRv6. > > [ZA] SRv6 uses IPv6 data plane and hence applicability of the IPv6 OAM > tools is discussed. > > - The document defines the support of O-flag as OPTIONAL. In that > case, what is the benefit of advertising the support of O-flag by an SR > node (even though the advertisement itself is optional)? > > [ZA] To let the other nodes/ controller know if the O-bit is supported by > a local node. > > - The document uses the term "accurate timestamp" without the > discussion or definition of what level of accuracy is required or expected, > methods to acquire an accurate timestamp, format(s) that must or may be > used to record a timestamp, and what are possible implications of not > providing an accurate timestamp. > > [ZA] We have addressed this comment by replacing “accurate” with “a”. It > is really up to the local implementation and draft does not add any > requirements. > > - The document asserts that to support "Many scenarios require punting > of SRv6 OAM packets at the desired nodes in the network" can be done only > with using OAM Endpoint with Punt function. I believe that TTL/Hop Count > Expired had been used successfully to achieve the same result. > > [ZA] Yes, and tracerouting is done using TTL/ HC. Please see section 4. > > - what is the apparent need to introduce functional duplication to > already existing OAM technique? How a packet would be processed if both > O-flag and the OAM SID End.OP are present (the specification only > recommends setting O-flag to 0 when End.OP SID is present)? > > [ZA] Good point. The restriction really does not exist and the new > version corrects the text. > > - Section 3.4 introduces function OAM Endpoint with Timestamp and > Punt. At the same time, processing the O-flag, defined, as: > > a. Make a copy of the packet. > b. Send the copied packet, along with an accurate timestamp > > Is the difference in making or not making a local copy significant enough > to have two mechanisms to achieve essentially the same result? How a packet > will be processed if both O-flag and the OAM SID End.OTP are present (the > specification only recommends to set O-flag to 0 when END.OTP SID is > present) ? > > > > [ZA] Good point. The restriction really does not exist and the new > version corrects the text. > > > - Section 3.5 states that: > > SRH TLV plays an important role in carrying OAM and Performance > > Management (PM) metadata. > > I cannot find any other text that illustrates how SRH TLV plays any role > in FM and/or PM OAM. > > > > [ZA] Indeed, the current draft does not define any TLV for OAM purposes. > The section was added as future drafts may define OAM TLVs. > > However, based on your comments, the section has been removed in the new > revision. > > > - It is stated in Section 4: > > This section describes how OAM mechanisms can be implemented using > the OAM building blocks described in the previous section. > > As this is the Standard document, using the normative language would be > very much desirable. Then it would be clearer whether the use of not only > O-flag but of OAM SIDs as well is optional or mandatory. > > > > [ZA] Based on your comment, modified the text in the document to add > normative language. Specifically: > > o In the new revision, we have added normative text at the beginning > of 3.1.1 where O-bit is defined. > > o Sections 3.3 and 3.4 adds normative texts for OAM SIDs. > > o 4.1.2 and 4.2.2 further adds additional normative text for Ping and > traceroute use-cases, respectively. > > > > > - I've noticed that functions used as an example in the document are > all part of active OAM functions. At the same time, the defined processing > of the O-flag is very much similar to the operation of in-situ OAM. But I > don't find any reference to in-situ OAM mechanism, nor discussion of > whether both can be used in combination or are mutually exclusive. > > [ZA] Based on your comment, we have removed the relevant section. > > - In Section 4.1.2 the identification of an OAM (active OAM or some > other kind of OAM) packet defined as: > > The OAM packets are identified either by setting the O-flag in SRH or > > by inserting the END.OP/ END.OTP SIDs at an appropriate place in the > > SRH. > > Is the use of any of these methods required for any OAM? If that is the > case, then the normative language must be used. Also, is it required to use > any of these methods for, for example, BFD control packets or STAMP test > packets? Isn't using assigned by IANA port number sufficient to identify > active IP OAM packets? Wouldn't the same be applicable in SRv6 OAM? > > > > [ZA2] You are right that IANA assigned port number should be sufficient to > identify active OAM packets. In order to process the OAM packets targeted > to a SID, based on a local configuration, the net-pgm needs to allow > processing of the OAM packets. What we need is a clarification in the > net-pgm draft for the Upper Layer Processing. I’ve added NET-PGM editors > (Spring is already CC’ed) to request this change. > > > > [ZA] Normative language has been added to address your comment. 4.1.2 and > 4.2.2 further adds additional normative text for Ping and traceroute > use-cases, respectively. > > > - I have a question on how a local node selects an application that is > to receive a punted packet (whether marked by O-flag that includes one of > OAM SIDs)? The document provides examples where the destination is either > ICMPv6 or a traceroute (?) process. Is that an exhaustive list? > > [ZA] The list is not exhaustive. Furthermore, O-bit is for telemetry use. > > > > I greatly appreciate your kind consideration and am looking forward to the > productive discussion. > > > > [ZA] Likewise, many thanks for your comments. > > > > Thanks > > > > Regards … Zafar > > > > Regards, > > Greg > > > > On Wed, Dec 4, 2019 at 3:53 PM Ole Troan <otr...@employees..org > <otr...@employees.org>> wrote: > > Hello, > > As agreed in the working group session in Singapore, this message starts > a new two week 6MAN Working Group Last Call on advancing: > > Title : Operations, Administration, and Maintenance (OAM) in Segment > Routing Networks with IPv6 Data plane (SRv6) > Author : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M.. Chen > Filename : draft-ietf-6man-spring-srv6-oam-02 > Pages : 23 > Date : 2019-11-20 > > https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/ > > as a Proposed Standard. > > Substantive comments and statements of support for publishing this > document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will end > on the 18th of December 2019. > > To improve document quality and ensure that bugs are caught as early as > possible, we would require at least > two reviewers to do a complete review of the document. Please let the > chairs know if you are willing to be a reviewer. > > The last call will be forwarded to the spring working group, with > discussion directed to the ipv6 list. > > Thanks, > Bob & Ole, 6man co-chairs > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
