Re: [Gen-art] Genart last call review of draft-ietf-6man-spring-srv6-oam-09

Lars Eggert <lars@eggert.org> Wed, 26 May 2021 09:54 UTC

Return-Path: <lars@eggert.org>
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 4705F3A2877; Wed, 26 May 2021 02:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=eggert.org
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 YcDNFXYzYFBO; Wed, 26 May 2021 02:54:35 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 D27BE3A28C4; Wed, 26 May 2021 02:54:28 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 4ADB5600047; Wed, 26 May 2021 12:54:13 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1622022853; bh=JJeZT8ccE5WZ8+oTOrdcdF25bqhtsLghPx9L9xQfLck=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=hGvofXo5y7A34e7G1pxUF9XbjpIX8j5HAecE+EjpbmIubizvSna/Fylm3Ui856fc0 JtW4Ne6DFHCrzXHsbYTRnnisV/9cKmMg3sf6sstt+Rd21JjjUZSWLAG9xOavyimM1c uzstqTatmn1y5+RDoiOyiZwFl8pYqK1z76tZIfs8=
From: Lars Eggert <lars@eggert.org>
Message-Id: <DA6C4DB4-64CE-44BF-9876-84D93C8E2E28@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BD780C12-16B9-40FF-AAD9-F483AEB696F4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: [Gen-art] Genart last call review of draft-ietf-6man-spring-srv6-oam-09
Date: Wed, 26 May 2021 12:54:11 +0300
In-Reply-To: <161560168111.19762.11315856321978805374@ietfa.amsl.com>
Cc: General Area Review Team <gen-art@ietf.org>, ipv6@ietf.org, draft-ietf-6man-spring-srv6-oam.all@ietf.org, last-call@ietf.org
To: Matt Joras <matt.joras@gmail.com>
References: <161560168111.19762.11315856321978805374@ietfa.amsl.com>
X-MailScanner-ID: 4ADB5600047.A2121
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Mi9L4L2PgC4rTWzorOmZ7igD9-U>
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 May 2021 09:54:39 -0000

Matt, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2021-3-13, at 4:14, Matt Joras via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Matt Joras
> Review result: Ready with Nits
> 
> 1.  Introduction
> 
>   As Segment Routing with IPv6 data plane (SRv6) [RFC8402] simply adds
>   a new type of Routing Extension Header, existing IPv6 OAM mechanisms
>   can be used in an SRv6 network.  This document describes how the
>   existing IPv6 mechanisms for ping and trace route can be used in an
>   SRv6 network.  This includes illustrations of pinging an SRv6 SID for
>   the SID connectivity checks and to validate the availability of a
>   SID.  This also includes illustrations for tracerouting to an SRv6
> 
> Trace route is spelled as two words here rather than a compound elsewhere.
> 
> 2.1.1.  O-flag Processing
> ...
>   If the telemetry data from the ultimate segment in the segment-list
>   is required, a penultimate segment SHOULD NOT be a Penultimate
>   Segment Pop (PSP) SID.  When the penultimate segment is a PSP SID,
>   the SRH will be removed and the O-bit will not be processed at the
>   ultimate segment.
> 
> This paragraph refers to it as the O-bit rather than the O-flag.
> 
> 2.2.  OAM Operations
> ...
>   Ping to a SID is used for SID connectivity checks and to validate the
>   availability of a SID.  Traceroute to a SID is used for hop-by-hop
>   fault localization as well as path tracing to a SID.  Section 3
>   illustrates the ICMPv6 based ping and the UDP based traceroute
>   mechanisms for ping and traceroute to an SRv6 SID.  Although this
>   document only illustrates ICMP ping and UDP-based traceroute to an
>   SRv6 SID, the procedures are equally applicable to other IPv6 OAM
>   probing to an SRv6 SID (e.g., Bidirectional Forwarding Detection
>   (BFD) [RFC5880], Seamless BFD (SBFD) [RFC7880], TWAMP Light and STAMP
>   probe message processing as described in [I-D.gandhi-spring-twamp-
>   srpm] and [I-D.gandhi-spring-stamp-srpm], respectively, etc.).
>   Specifically, as long as local configuration allows the Upper-layer
>   Header processing of the applicable OAM payload for SRv6 SIDs, the
>   existing IPv6 OAM techniques can be used to target a probe to a
>   (remote) SID.
> 
> This paragraph mixes "ICMPv6 based ping" and "ICMP ping". There is also
> not consistency with "-based", e.g. "UDP-based" versus "UDP based". The
> reference link to [I-D.gandhi-spring-twamp-srpm] is not functional.
> 
>   IPv6 OAM operations can be performed with the target SID in the IPv6
>   destination address without SRH or with SRH where the target SID is
>   the last segment.  In general, OAM operations to a target SID may not
>   exercise all of its processing depending on its behavior definition.
>   For example, ping to an END.X SID (refer [I-D.ietf-spring-srv6-
>   network-programming]) at the target node only validates availability
>   of the SID and does not validate switching to the correct outgoing
>   interface.  To exercise the behavior of a target SID, the OAM
>   operation SHOULD construct the probe in a manner similar to a data
>   packet that exercises the SID behavior, i.e. to include that SID as a
>   transit SID in either an SRH or IPv6 DA of an outer IPv6 header or as
>   appropriate based on the definition of the SID behavior.
> 
> The reference to [I-D.ietf-spring-srv6-network-programming] is not
> functional and "refer" before it reads awkwardly.
> 
> 3.1.1.  Classic Ping
> 
>   If an SRv6 capable ingress node wants to ping an IPv6 address via an
>   arbitrary segment list <S1, S2, S3>, it needs to initiate ICMPv6 ping
>   with an SR header containing the SID list <S1, S2, S3>.  This is
>   illustrated using the topology in Figure 1.  Assume all the links
>   have IGP metric 10 except both links between N2 and N3, which have
>   IGP metric set to 100.  User issues a ping from node N1 to a loopback
>   of node 5, via segment list <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>.
>   The SID behavior used in the example is End.X SID (refer [I-D.ietf-
>   spring-srv6-network-programming]) but the procedure is equally
>   applicable to any other (transit) SID type.
> 
> Suggest "initial an ICMPv6 ping". "IGP" is not defined here or subsequently
> in the document. Another broken reference, and the "refer" language.
> 
> ...
>   o  The echo request packet at N5 arrives as an IPv6 packet with or
>      without an SRH.  If N5 receives the packet with SRH, it skips SRH
>      processing (SL=0).  In either case, Node N5 performs the standard
>      IPv6/ ICMPv6 processing on the echo request and responds with the
>      echo reply message.  The echo reply message is IP routed.
> 
> "IPv6/ ICMPv6" is a typo, suggest just being ICMPv6 as the latter implies
> the former.
> 
> 3.1.2.  Pinging a SID
> 
>   The classic ping described in the previous section applies equally to
>   perform SID connectivity checks and to validate the availability of a
>   remote SID.  This is explained using an example in the following.
>   The example uses ping to an END SID (refer [I-D.ietf-spring-srv6-
>   network-programming]) but the procedure is equally applicable to ping
>   any other SID behaviors.
> 
> Broken reference to [I-D.ietf-spring-srv6-network-programming] and same
> refer language.
> 
> 3.2.1.  Classic Traceroute
> ...
>   If an SRv6 capable ingress node wants to traceroute to IPv6 address
>   via an arbitrary segment list <S1, S2, S3>, it needs to initiate
>   traceroute probe with an SR header containing the SID list <S1, S2,
>   S3>.  That is illustrated using the topology in Figure 1.  Assume all
>   the links have IGP metric 10 except both links between N2 and N3,
>   which have IGP metric set to 100.  User issues a traceroute from node
>   N1 to a loopback of node 5, via segment list <2001:DB8:B:2:C31::,
>   2001:DB8:B:4:C52::>.  The SID behavior used in the example is End.X
>   SID (refer [I-D.ietf-spring-srv6-network-programming]) but the
>   procedure is equally applicable to any other (transit) SID type.
>   Figure 3 contains sample output for the traceroute request.
> 
> Reference works here. But again "refer" language.
> 
> ...
>   The information about the IP address of the incoming interface on
>   which the traceroute probe was received by the reporting node is very
>   useful.  This information can also be used to verify if SIDs
>   2001:DB8:B:2:C31:: and 2001:DB8:B:4:C52:: are executed correctly by
>   N2 and N4, respectively.  Specifically, the information displayed for
>   the second hop contains the incoming interface address
>   2001:DB8:2:3:31:: at N3.  This matches with the expected interface
>   bound to END.X behavior 2001:DB8:B:2:C31:: (link3).  Similarly, the
>   information displayed for hop5 contains the incoming interface
>   address 2001:DB8:4:5::52:: at N5.  This matches with the expected
>   interface bound to the END.X behavior 2001:DB8:B:4:C52:: (link10).
> 
> The first sentence of this paragraph is awkwardly, perhaps just
> verbosely phrased. Suggest rephrasing along the lines of "The IP
> address of the interface on which the traceroute probe was received
> is useful."
> 
> 3.3.  A Hybrid OAM Using O-flag
> ...
>   The illustration is different than the In-situ OAM defined in [I.D-
>   draft-ietf-ippm-ioam-data].  This is because In-situ OAM records
>   operational and telemetry information in the packet as the packet
>   traverses a path between two points in the network [I.D-draft-ietf-
>   ippm-ioam-data].  The illustration in section 3 does not require the
>   recording of OAM data in the packet.
> 
> Broken reference to [I.D-draft-ietf-ippm-ioam-data]
> 
> ...
>   Consider the example where the user wants to monitor sampled IPv4 VPN
>   999 traffic going from CE1 to CE2 via a low latency SR policy P
>   installed at Node N1.  To exercise a low latency path, the SR Policy
>   P forces the packet via segments 2001:DB8:B:2:C31:: and
>   2001:DB8:B:4:C52::.  The VPN SID at N7 associated with VPN 999 is
>   2001:DB8:B:7:DT999::.  2001:DB8:B:7:DT999:: is a USP SID.  N1, N4,
>   and N7 are capable of processing SRH.Flags.O-flag but N2 is not
>   capable of processing SRH.Flags.O-flag.  N100 is the centralized
>   controller capable of processing and correlating the copy of the
>   packets sent from nodes N1, N4, and N7.  N100 is aware of
>   SRH.Flags.O-flag processing capabilities.  Controller N100 with the
>   help from nodes N1, N4, N7 and implements a hybrid OAM mechanism
>   using the SRH.Flags.O-flag as follows:
> 
> Is it reasonable to assume understanding of "VPN 999 traffic", "CE1",
> "CE2", and "low latency SR policy P"?
> 
> ...
>   o  When node N2 receives the packet with SRH.Flags.O-flag set, it
>      ignores the SRH.Flags.O-flag.  This is because node N2 is not
>      capable of processing the O-flag.  Node N2 performs the standard
>      SRv6 SID and SRH processing.  Specifically, it executes the END.X
>      (refer [I-D.ietf-spring-srv6-network-programming]) behavior
>      (2001:DB8:B:2:C31::) and forwards the packet P1 (2001:DB8:A:1::,
>      2001:DB8:B:4:C52::) (2001:DB8:B:7:DT999::, 2001:DB8:B:4:C52::,
>      2001:DB8:B:2:C31::; SL=1; O-flag=1; NH=IPv4)(IPv4 header)(payload)
>      over link 3 towards Node N3.
> 
> Inconsistent use of "SRH.Flags.O-flag" versus simply "O-flag".
> 
> 3.4.  Monitoring of SRv6 Paths
> ...
>   In the reference topology in Figure 1, N100 uses an IGP protocol like
>   OSPF or ISIS to get the topology view within the IGP domain.  N100
>   can also use BGP-LS to get the complete view of an inter-domain
>   topology.  The controller leverages the visibility of the topology to
>   monitor the paths between the various endpoints.
> "OSPF" and "ISIS" are not defined, and neither is "BGP-LS".
> 
>   The controller N100 advertises an END (refer [I-D.ietf-spring-srv6-
>   network-programming]) SID 2001:DB8:B:100:1::. To monitor any
>   arbitrary SRv6 paths, the controller can create a loopback probe that
>   originates and terminates on Node N100.  To distinguish between a
>   failure in the monitored path and loss of connectivity between the
>   controller and the network, Node N100 runs a suitable mechanism to
>   monitor its connectivity to the monitored network.
> 
> Broken reference to [I-D.ietf-spring-srv6-network-programming], and
> another use of "refer".
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art