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

"Zafar Ali (zali)" <zali@cisco.com> Wed, 17 July 2019 00:48 UTC

Return-Path: <zali@cisco.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 47CC4120110; Tue, 16 Jul 2019 17:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ANWF/kBP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BXDIL+O4
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 hOgkO-uUEJxR; Tue, 16 Jul 2019 17:48:50 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19661200C4; Tue, 16 Jul 2019 17:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37557; q=dns/txt; s=iport; t=1563324530; x=1564534130; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yD17daC+6DnervW/W9LFaCIyFeNnI7tp9eJpCguGs5o=; b=ANWF/kBPu0lVowtN4+q7B9MviS0fom9/gI4V7BChn8eTNQU8gT5lJ0E3 OvGK5DeD3JQ534kb8k2oTFHEXQlMT7qXCyv/ZcnsuVYCnnykLIguFx0K+ /Wc0+ZsbPikaBBUZMVQlnyQi/WeZqCy2dXivdxHRZtGE5VerlQ7n1nuj/ Y=;
IronPort-PHdr: 9a23:9VLDxBP45mhz2an4QFQl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSwdDjMwXmwI6B8vQG0T/LdbhbjcxG4JJU1o2t3w=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AnAAA5by5d/5ldJa1mGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGBFC9QA2pVIAQLKIQcg0cDjlCCW5dQglIDVAkBAQEMAQEtAgEBhEACF4IjIzcGDgEDAQEEAQECAQVthTwMhUoBAQEBAxIRChMBASUSAQ8CAQgRAwECIQEJAgICMB0IAQEEAQ0FIoMAAYEdTQMdAQKiDQKBOIhgcYEygnkBAQWCR4JGGIITCYE0AYteF4FAP4E4H4JMPoRLBxKCajKCJo54hH6Ia44GCQKCGZQMG4IthyWOOI01VZZ7AgQCBAUCDgEBBYFmIiqBLnAVZQGCQYJBDBeDTopTcoEpjxQBAQ
X-IronPort-AV: E=Sophos;i="5.64,272,1559520000"; d="scan'208,217";a="585662271"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 00:48:49 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6H0mnoR019315 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2019 00:48:49 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Jul 2019 19:48:48 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Jul 2019 19:48:48 -0500
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 16 Jul 2019 20:48:47 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J70p4SxkYAj87R1j3QtaYnHZ8uuoFqslVQsHG5WZt4WQ+j+FbzuSR3IuvdiCQ8UBS+WvTwnykkZjLSBgFnnZZlAo0dwbI2dJyXkmOr9RrPMbIG2QOfj3+URLqEKVNMJ1jryetf76QaDj7+g7Mjr4d6hKb6lSjUEKDbWFyfZKN+mf5XZ40WMbz/3YL0XKI71RqBejk84gpZgpBTuRXYZ8biajJYxcL/Ddm9LWVYHvd1a+WV+1THqD/xJg40O4mWTc+WAhDto5VchAiFaC85+4TcEdcxOGdluyp66NgEenAxshXC9RZ/eoNPJoRQy75uv30GMESUM33Hc1gktZFOJqSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yD17daC+6DnervW/W9LFaCIyFeNnI7tp9eJpCguGs5o=; b=ZfTejXBe3eQrwNgJd1FcLmnWCYVY/i0KkU5xnFip1PzBUuVG/Hk7RaL9VKJ8SegMoZTYPTmfnGZ+zQQ+BIjA6Gok3Xx5ODOlvMLCIA7/hws3d1CJPoQYnHFASvQrar1JmTD4CaV+A5vxdTHJocIYYuXQMS8Nf+pJPqhqWUTRXKdw9hO1Ecf0946cogp8u51Xghx75izhGH73BjFpZ2cqci+ZWrWfWXPkfcuCCE4jJezlezEaX/xeQMtGlDDE1AjwxGy1OOZg3hikCppyPklTBYoiri785PmmelAbGRTkI4D/Kh3xGY5Zp3QPtmgv8eAxRr3zFGyRtysiBUBjmmUNEw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yD17daC+6DnervW/W9LFaCIyFeNnI7tp9eJpCguGs5o=; b=BXDIL+O4hEs910Qh2h2oMTx+RpdhRzpFS3hPk0jNkh6x3tcrKNMy4C8uBSqgBAr3Dr4lGFIeBXP0AfWy6kMuH9zBHevrStN7hEMXUfr96++aG/k51/nQG6d6Qw/dy9oIKapx8NrMq6rywM5l2jzCWQaN1oi+7XsdHAEVkC1Y/lU=
Received: from DM6PR11MB3324.namprd11.prod.outlook.com (20.176.122.29) by DM6SPR01MB0018.namprd11.prod.outlook.com (20.176.113.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.15; Wed, 17 Jul 2019 00:48:46 +0000
Received: from DM6PR11MB3324.namprd11.prod.outlook.com ([fe80::b475:bfcf:d78d:ee73]) by DM6PR11MB3324.namprd11.prod.outlook.com ([fe80::b475:bfcf:d78d:ee73%3]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 00:48:46 +0000
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Xiejingrong <xiejingrong@huawei.com>, "6man@ietf.org" <6man@ietf.org>
CC: "Zafar Ali (zali)" <zali@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: Comments on <draft-ali-6man-spring-srv6-oam-02>
Thread-Topic: Comments on <draft-ali-6man-spring-srv6-oam-02>
Thread-Index: AdU2xs33SCKIecO8RGu9mVAXzXvUpgFUQ4GA
Date: Wed, 17 Jul 2019 00:48:46 +0000
Message-ID: <CB7B16C2-58D1-41DF-90E7-C01D453BFCA4@cisco.com>
References: <16253F7987E4F346823E305D08F9115AAB8DC856@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB8DC856@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zali@cisco.com;
x-originating-ip: [2001:420:c0cc:1003::a9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8e76347b-5f90-4539-2188-08d70a508695
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6SPR01MB0018;
x-ms-traffictypediagnostic: DM6SPR01MB0018:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DM6SPR01MB00186FC5A18B80B248EAE201DEC90@DM6SPR01MB0018.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01018CB5B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(366004)(136003)(39860400002)(376002)(199004)(189003)(2906002)(86362001)(478600001)(91956017)(76116006)(6306002)(54896002)(186003)(64756008)(66446008)(33656002)(66556008)(66476007)(66946007)(46003)(446003)(476003)(2616005)(14454004)(11346002)(6512007)(4326008)(99286004)(486006)(36756003)(316002)(53936002)(110136005)(54906003)(58126008)(6246003)(25786009)(6116002)(790700001)(5660300002)(7736002)(6486002)(6436002)(2501003)(229853002)(256004)(14444005)(9326002)(8676002)(76176011)(53546011)(68736007)(81156014)(81166006)(102836004)(71200400001)(71190400001)(6506007)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6SPR01MB0018; H:DM6PR11MB3324.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: SqdnU20aQ017kgr7Loqz7gH+Wd8BihXXYwk7rKAhMU1WzqS3ySLHrPZelgolZrW9DhFR6tJWUvof65HtjaZRBZ5KuoxwrR1kHg1QL8TcneB/rcgM+fG3DfZprzVOgPfN7tfnLOeazGlZIB360aDvCQtH/B8OqFMJm2HmlWqw0O5Z5S0Bb60gJoLfHJ1di8bStlMT8JZ41qFaeYe+k7jN3iqIXeFNXUd/KTM01h7uwZsGB/eklExf+a48ukS9vgXpAWnTb0icAkpuqTC0nQTuuqPjiXMlHLcWXdIbbkrWBTOuiCHU639K9pmo4C/ysJaCRHn5maylo58lKys0NSafhbadKVTU30o4L5VCxxE1YuOZdcU9Rxqip+Y5kYL9JaLNrbLjkcsY25KjAFlQzE7TJ4hr0hFEWCjikyjQ3YKAnUw=
Content-Type: multipart/alternative; boundary="_000_CB7B16C258D141DF90E7C01D453BFCA4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e76347b-5f90-4539-2188-08d70a508695
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 00:48:46.6237 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zali@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6SPR01MB0018
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/d3s8dKRjuaZkbRAynvapIArYjWY>
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, 17 Jul 2019 00:48:55 -0000

Hi Xiejingrong,

Many thanks for your comments. Greatly appreciated.

First off, let’s take the example in section 4.2.2.2 of the draft.
Let’s also modify the example using END.DT4 SID in your example.


I.e., user user wants to traceroute to a remote SID function B:5:DT4, via <B:2:C31, B:4:C52> from node N1 using O-bit.

In this case,


Node N1 initiates a traceroute probe with SRH as follows (A:1::,

      B:2:C31)(B:5:DT4, B:4:C52, B:2:C31; HC=64, SL=2, Flags.O=1;

      NH=UDP)(Traceroute Probe).

When O-bit is processed at node 2, we the existing pseudo code works fine.
When O-bit is processed at node 4, we the existing pseudo code works fine.
The pseudo code for O-bit processing at node 5 needs a fix – please see [ZA] in-line for the suggested change to address your comment.
We can make the change to address your comment during the IETF week.

Thanks

Regards … Zafar

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Xiejingrong <xiejingrong@huawei.com>
Date: Tuesday, July 9, 2019 at 10:34 PM
To: "6man@ietf.org" <6man@ietf.org>
Subject: Comments on <draft-ali-6man-spring-srv6-oam-02>

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,
[ZA] Add Ref2
     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.

[ZA] Ref2: An implementation should not generate further ICMP error during local SID S processing. If local SID S processing requires generation of an ICMP error, the error is generated by the local OAM process.

[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.

[ZA] The pseudo code does not restrict an implementation to optimize O-bit processing, as necessary, to get the same behavior.

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.

[ZA] The issue is that an implementation may not send ICMP error.