Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
Greg Mirsky <gregimirsky@gmail.com> Wed, 26 February 2020 00:54 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825CD3A0A0B; Tue, 25 Feb 2020 16:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-BMbF2kGuBs; Tue, 25 Feb 2020 16:54:09 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DB63A0A0A; Tue, 25 Feb 2020 16:54:08 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id 83so611063lfh.9; Tue, 25 Feb 2020 16:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3HA6wl/1fNi5yA3LX/Xu8Fpp+7EJymDa9EuIkjwU2tI=; b=Zs5AtHmeFuYqB1sI8P48L0n33Z+BCc6elH3Q88o4wcux698cD43DNppo6+NtOpOWQs 9NfIn0pTDUXBw7Gpc79aNie+kB6TzkA++chSr1SoxFAy/QgBCgKub1VquWBA+4LC/w5Q 5au4XuA7bMH/jGubSYnUwYl2KVTOoM0dVNeliwzKcCskAK7Md6LAQZUfjG2tkKMsuJhs yyMPXpGooaEz+WBKJOpJ8yjk1CITdoEWh4T5kWTSrl3dNvHaOJijSMnQzaWLyGfa9PYZ x9Ph3WYLPNAYkj0J1lsjKLBFoLVvpNGoVpGgKwS1BRtDJELanjgz7qou49YzVgaH9cCF Vunw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3HA6wl/1fNi5yA3LX/Xu8Fpp+7EJymDa9EuIkjwU2tI=; b=LllNJAY0MMXjk6BCFTgguS58EWicQ3K+pgGjniM60W/Q5Z2iB43qu1UmQQEKBqHH1J njKMojzCtWg9VHEFrEjdzpeI4ooI+4bpKXQKlge5T3YlW5fYRzive6JhAahf9Dr3uPW0 JL8AmTrm82Pnnj/f/7EXBwGfBs0Lf/IyDI0GOA6diuo3sA+HognLe0jGJXhLdg7vscak gpadB3AdrSmbck2GedSBzWqvBrHKwdhyj8rKHEgIgHCngwxV9xRRpLv0q+rP5brl1KMZ yWbhY2lJLDvxpVVjFVZLrRgSqIUF1NQo7k8WFilf5WTrbnK9DjiblRpJt46wVk3QYfem vl/A==
X-Gm-Message-State: APjAAAWO7WSU4+T/pOe2NbtMPXhWo30eHivaAgBg3p4Z9881SpqtGNRI v+z4J7tk6/5DoCHY2M4Gf3sPC4PIbge6KxhZL2s=
X-Google-Smtp-Source: APXvYqwjUdQqafJwkZ63S/JJNO2LLlHjMS3gg8eQjspU95S4fRfX9XIYaS1QFw0MULDNodnbqRiqhMYuqtqAp+dMBTc=
X-Received: by 2002:ac2:52a2:: with SMTP id r2mr804160lfm.33.1582678446263; Tue, 25 Feb 2020 16:54:06 -0800 (PST)
MIME-Version: 1.0
References: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org> <CA+RyBmX5=Z_sMrv8CGO7N_ZFwefQsrr=rNyaJwN+2p+9d8TS3Q@mail.gmail.com> <B496472A-0AB3-42D9-BC4E-14E5E2769008@cisco.com> <613EC60C-C81D-4CF1-9CBF-4135571CCDF6@cisco.com>
In-Reply-To: <613EC60C-C81D-4CF1-9CBF-4135571CCDF6@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 25 Feb 2020 16:53:54 -0800
Message-ID: <CA+RyBmWgQWftckWySD7WyOMt4Q9oQkhk0fZv64Xsy3nEuNvRng@mail.gmail.com>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
To: "Zafar Ali (zali)" <zali@cisco.com>
Cc: Ole Troan <otroan@employees.org>, SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000955178059f700ab1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fT02d68x4DhoqK-Pj53g9XkF-fo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 00:54:12 -0000
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) <zali@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)" <zali@cisco.com> > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky <gregimirsky@gmail.com>, Ole Troan <otroan@employees.org > > > *Cc: *SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs < > 6man-chairs@ietf.org>, "Zafar Ali (zali)" <zali@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-bounces@ietf.org> on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Thursday, December 5, 2019 at 5:22 PM > *To: *Ole Troan <otroan@employees.org> > *Cc: *SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs < > 6man-chairs@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 <otroan@employees..org > <otroan@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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
- 6man w.g. last call for <draft-ietf-6man-spring-s… Ole Troan
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Joel M. Halpern
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Greg Mirsky
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Zafar Ali (zali)
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Joel M. Halpern
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Joel M. Halpern
- Re: 6man w.g. last call for <draft-ietf-6man-spri… li_zhenqiang@hotmail.com
- RE: 6man w.g. last call for <draft-ietf-6man-spri… Ron Bonica
- Re: 6man w.g. last call for <draft-ietf-6man-spri… otroan
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Joel Halpern Direct
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Robert Raszuk
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Rakesh Gandhi
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Robert Raszuk
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Joel M. Halpern
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- RE: [spring] 6man w.g. last call for <draft-ietf-… Ron Bonica
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Loa Andersson
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Bob Hinden
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Brian E Carpenter
- Re: 6man w.g. last call for <draft-ietf-6man-spri… Bob Hinden
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Zafar Ali (zali)
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky
- Re: [spring] 6man w.g. last call for <draft-ietf-… Loa Andersson
- Re: [spring] 6man w.g. last call for <draft-ietf-… Greg Mirsky