Comments on <draft-ali-6man-spring-srv6-oam-02>

Xiejingrong <xiejingrong@huawei.com> Wed, 10 July 2019 02:34 UTC

Return-Path: <xiejingrong@huawei.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 E399712008A for <ipv6@ietfa.amsl.com>; Tue, 9 Jul 2019 19:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 whhn9n-Ukx5n for <ipv6@ietfa.amsl.com>; Tue, 9 Jul 2019 19:34:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBA6120048 for <6man@ietf.org>; Tue, 9 Jul 2019 19:34:16 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F418D7FEDAAFE5F164B9 for <6man@ietf.org>; Wed, 10 Jul 2019 03:34:14 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 03:34:14 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Wed, 10 Jul 2019 10:34:04 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "6man@ietf.org" <6man@ietf.org>
Subject: Comments on <draft-ali-6man-spring-srv6-oam-02>
Thread-Topic: Comments on <draft-ali-6man-spring-srv6-oam-02>
Thread-Index: AdU2xs33SCKIecO8RGu9mVAXzXvUpg==
Date: Wed, 10 Jul 2019 02:34:04 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8DC856@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8DC856nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY>
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, 10 Jul 2019 02:34:20 -0000

Hi,
I have a few comments on <draft-ali-6man-spring-srv6-oam-02>:

3.1.1.  O-flag Processing
   Implementation of the O-flag is OPTIONAL.  A node MAY ignore
   SRH.Flags.O-flag.  It is also possible that a node is capable of
   supporting the O-bit but based on a local decision it MAY ignore it
   during processing on some local SIDs.  If a node does not support the
   O-flag, then upon reception it simply ignores it.  If a node supports
   the O-flag, it can optionally advertise its potential via node
   capability advertisement in IGP [I-D.ietf-isis-srv6- extensions] and
   BGP-LS [I-D.ietf-idr-bgpls-srv6-ext].

   The SRH.Flags.O-flag implements the "punt a timestamped copy and
   forward" behavior.

   When N receives a packet whose IPv6 DA is S and S is a local SID, N
   executes the following pseudo-code, before the execution of the local
   SID S.

     1. IF SRH.Flags.O-flag is one and local configuration permits THEN
            a. Make a copy of the packet.
            b. Send the copied packet, along with an accurate timestamp
               to the OAM process.      ;; Ref1
     Ref1: An implementation SHOULD copy and record the timestamp as soon as
     possible during packet processing. Timestamp is not carried in the packet
     forwarded to the next hop.
[XJR] O-flag is OPTIONAL while the process is the first, I don't think it is optimized.
I don't even believe the process is clear until the whole process is put together. I try this for the End.DT4 function (1a to 3a is added as above):
1a.   IF NH=SRH AND SRH.Flags.O-flag is one and local configuration permits THEN
2a.      a. Make a copy of the packet.
3a.      b. Send the copied packet, along with an accurate timestamp to the OAM process. ;; Ref1
1.   IF NH=SRH and SL > 0
2.      drop the packet                                         ;; Ref1
3.   ELSE IF ENH = 4                                            ;; Ref2
4.      pop the (outer) IPv6 header and its extension headers
5.      lookup the exposed inner IPv4 DA in IPv4 table T
6.      forward via the matched table entry
7.   ELSE
8.      Send an ICMP parameter problem message                  ;; Ref3
9.      drop the packet

Then a packet (NH=SRH<with O flag>, SL=0, ENH=ICMPv6) will go to 2a/3a and 8/9, means that two ICMP will be send to CPU. Right ?
Besides, the Step 1 to 9 should be more optimized, other than deep check of SRH.Flags.O-flag at the beginning.


4.1.2.  Pinging a SID Function
   The classic ping described in the previous section cannot be used to
   ping a remote SID function, as explained using an example in the
   following.
   Consider the case where the user wants to ping the remote SID
   function B:4:C52, via B:2:C31, from node N1.  Node N1 constructs the
   ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1;
   NH=ICMPv6)(ICMPv6 Echo Request).  The ping fails because the node N4
   receives the ICMPv6 echo request with DA set to B:4:C52 but the next
   header is ICMPv6, instead of SRH.  To solve this problem, the
   initiator needs to mark the ICMPv6 echo request as an OAM packet.

[XJR] Who produce the problem then ? Seems like it is the SID itself drop the ICMPv6 packet.
I guess it is easy for an SID to support sending the ICMPv6 packet to CPU, and support pinging this SID just the same as pinging a classic IPv6 address. Is it ?
I try this for the End.DT4 function (add 7A and 8A):

1.   IF NH=SRH and SL > 0
2.      drop the packet                                         ;; Ref1
3.   ELSE IF ENH = 4                                            ;; Ref2
4.      pop the (outer) IPv6 header and its extension headers
5.      lookup the exposed inner IPv4 DA in IPv4 table T
6.      forward via the matched table entry
7A.   ELSE IF ENH = 58
8A.      Send the packet to CPU
7.   ELSE
8.      Send an ICMP parameter problem message                  ;; Ref3
9.      drop the packet

Isn't this simpler than adding a new End.OTP SID ?
The normal use of End.DT4 doesn't require an SRH header, while the pinging of the End.DT4 need to add an SRH with an End.OTP and the End.DT4. That looks strange to me.