Re: [spring] draft-ali-6man-spring-srv6-oam-00
Loa Andersson <loa@pi.nu> Thu, 23 May 2019 03:43 UTC
Return-Path: <loa@pi.nu>
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 3BDAA120156; Wed, 22 May 2019 20:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 5ukSOHcMZaWx; Wed, 22 May 2019 20:42:56 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0280D120152; Wed, 22 May 2019 20:42:56 -0700 (PDT)
Received: from [192.168.1.13] (unknown [119.94.165.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9DA0933F5AF; Thu, 23 May 2019 05:42:50 +0200 (CEST)
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
To: Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>, Robert Raszuk <rraszuk@gmail.com>
Cc: "cpignata@cisco.com" <cpignata@cisco.com>, SPRING WG <spring@ietf.org>, "cfilsfil@cisco.com" <cfilsfil@cisco.com>, "fbrockne@cisco.com" <fbrockne@cisco.com>, Ron Bonica <rbonica@juniper.net>, "rgandhi@cisco.com" <rgandhi@cisco.com>, "naikumar@cisco.com" <naikumar@cisco.com>, "zali@cisco.com" <zali@cisco.com>, ipv6@ietf.org
References: <BYAPR05MB48219486CC62D9DAD4F613DEBE570@BYAPR05MB4821.namprd05.prod.outlook.com> <BYAPR05MB48215C3ED0EC73CEBCBC9DE3BE000@BYAPR05MB4821.namprd05.prod.outlook.com> <CAO42Z2yVA77PZDe7JzYQ8Sfqvd_Pxtx8kAtvHWxm6H3kZnkyiw@mail.gmail.com> <BYAPR05MB4821FA5861785D61A3BD3C76BE000@BYAPR05MB4821.namprd05.prod.outlook.com> <BYAPR05MB4821C138597D9686DFE10278BE000@BYAPR05MB4821.namprd05.prod.outlook.com> <CA+b+ER=yznuPeRMESW_3CMQDVrXvO13e_a-Yh5QHfuNrpK0PBQ@mail.gmail.com> <BYAPR05MB4821AD5C0CEFF91F695BBCB9BE000@BYAPR05MB4821.namprd05.prod.outlook.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <2e4ecdcd-021c-e39b-fd12-7c43c5796e93@pi.nu>
Date: Thu, 23 May 2019 11:42:48 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <BYAPR05MB4821AD5C0CEFF91F695BBCB9BE000@BYAPR05MB4821.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Jn42QYzGBFXRl6vlX_-C2RIeFMk>
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: Thu, 23 May 2019 03:43:00 -0000
Rajesh, It seems to me that "it is recommended" indicate that the ordering is optional/OPTIONAL. Does this document (or your comment) create a MANDATORY ordering of EH's?? /Loa On 2019-05-22 22:44, Rajesh M wrote: > I think as long as we ensure below order it must be OK. > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > > IPv6 header > > Hop-by-Hop Options header > > Destination Options header (note 1) > > Routing header > > Fragment header > > Authentication header (note 2) > > Encapsulating Security Payload header (note 2) > > Destination Options header (note 3) > > Upper-Layer header > > *From:* Robert Raszuk <rraszuk@gmail.com> > *Sent:* Wednesday, May 22, 2019 7:55 PM > *To:* Rajesh M <mrajesh@juniper.net> > *Cc:* cfilsfil@cisco.com; zali@cisco.com; naikumar@cisco.com; > cpignata@cisco.com; rgandhi@cisco.com; fbrockne@cisco.com; SPRING WG > <spring@ietf.org>; Peter Psenak <ppsenak@cisco.com>; Ron Bonica > <rbonica@juniper.net> > *Subject:* Re: [spring] draft-ali-6man-spring-srv6-oam-00 > > Hi Rajesh, > > I think some folks are just confusing "insertion of new EH" from > "modification of existing EH" ? To me those are completely different > actions. > > And processing of any EH is explicitly allowed by RFC8200 as long as dst > address in the top v6 header is the processing entity which seems to be > the case here. Such processing nowhere in RFC8200 seems to be prohibited. > > Let's also observe that as it is often the case with OEM it is actual > network elements who act as both src and dst of the end to end OEM > sessions :). > > Thx, > > R. > > On Wed, May 22, 2019 at 3:56 PM Rajesh M > <mrajesh=40juniper.net@dmarc.ietf..org > <mailto:40juniper.net@dmarc.ietf.org>> wrote: > > Agreed (cannot claim compliance with RFC8200). Authors please comment > > Guys in this draft I see that all the example such as ping, > traceroute to ipv6 address-> use SRH insertion rather than SRH > encapsulation.This is intentionally done to reduce the packet size > (since underlying data can be only ipv6) ? > > *From:* Mark Smith <markzzzsmith@gmail.com > <mailto:markzzzsmith@gmail.com>> > *Sent:* Wednesday, May 22, 2019 10:15 AM > *To:* Rajesh M <mrajesh@juniper.net <mailto:mrajesh@juniper.net>> > *Cc:* cfilsfil@cisco.com <mailto:cfilsfil@cisco.com>; zali@cisco.com > <mailto:zali@cisco.com>; naikumar@cisco.com > <mailto:naikumar@cisco.com>; cpignata@cisco.com > <mailto:cpignata@cisco.com>; rgandhi@cisco.com > <mailto:rgandhi@cisco.com>; fbrockne@cisco.com > <mailto:fbrockne@cisco.com>; SPRING WG <spring@ietf.org > <mailto:spring@ietf.org>>; ipv6@ietf.org <mailto:ipv6@ietf.org>; > Peter Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>> > *Subject:* Re: draft-ali-6man-spring-srv6-oam-00 > > EH insertion is not compliant with RFC8200. Equipment doing so > cannot claim compliance with RFC8200. > > On Wed., 22 May 2019, 11:08 Rajesh M, > <mrajesh=40juniper..net@dmarc.ietf.org > <mailto:40juniper.net@dmarc.ietf.org>> wrote: > > Guys in this draft I see that all the example such as ping, > traceroute to ipv6 address-> use SRH insertion rather than SRH > encapsulation. > > This is intentionally done to reduce the packet size (since > underlying data can be only ipv6) ? > > Juniper Internal > > Juniper Internal > > Juniper Internal > > *From:* Rajesh M > *Sent:* Wednesday, April 3, 2019 1:06 PM > *To:* cfilsfil@cisco.com <mailto:cfilsfil@cisco.com>; > zali@cisco.com <mailto:zali@cisco.com>; naikumar@cisco.com > <mailto:naikumar@cisco.com>; cpignata@cisco.com > <mailto:cpignata@cisco.com>; rgandhi@cisco.com > <mailto:rgandhi@cisco.com>; fbrockne@cisco.com > <mailto:fbrockne@cisco.com> > *Cc:* SPRING WG <spring@ietf.org <mailto:spring@ietf.org>>; > ipv6@ietf.org <mailto:ipv6@ietf.org>; Ron Bonica > <rbonica@juniper.net <mailto:rbonica@juniper.net>> > *Subject:* draft-ali-6man-spring-srv6-oam-00 > > Please find few comments on this draft > > 1. Section 3.1.1 , below must be Ref2 > > *Ref1*: Hardware (microcode) just punts the packet. Software > (slow path) > > implements the required OAM > > mechanism. Timestamp is not carried in the packet forwarded to the > > next hop. > > 2. 4.1.2.2, here it must be N2 (page 10) > > If the target SID is not locally programmed, *N4* responses with > > the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not > > locally implemented (TBA)"); otherwise a success is returned. > > 3. 4.1.2.2, here it must be B:4:C52 (page 11) > > The ICMPv6 process at node N4 > > checks if its local SID (*B:2:C31*) is locally programmed or not > > and responds to the ICMPv6 Echo Request. > > 4. 4.3.2.2, here it must be B:4:C52 (page 16) > > The traceroute process at > > node N4 checks if its local SID (*B:2:C31*) is locally > > programmed. > > 5) in below two cases is it B5:: or it must be A:5:: ? > > > ping A:5:: via segment-list B:2:C31, B:4:C52 > > Sending 5, 100-byte ICMP Echos to *B5::,* timeout is 2 seconds: > > !!!!! > > > traceroute A:5:: via segment-list B:2:C31, B:4:C52 > > Tracing the route to *B5::* > > Thanks > > Rajesh > > Juniper Internal > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org <mailto:ipv6@ietf.org> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo&e=> > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > spring@ietf.org <mailto:spring@ietf.org> > https://www.ietf.org/mailman/listinfo/spring > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzukhcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuNWxM&e=> > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64
- draft-ali-6man-spring-srv6-oam-00 Rajesh M
- RE: draft-ali-6man-spring-srv6-oam-00 Rajesh M
- Re: draft-ali-6man-spring-srv6-oam-00 Mark Smith
- RE: draft-ali-6man-spring-srv6-oam-00 Rajesh M
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Loa Andersson
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Robert Raszuk
- RE: [spring] draft-ali-6man-spring-srv6-oam-00 Rajesh M
- RE: [spring] draft-ali-6man-spring-srv6-oam-00 Adrian Farrel
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Loa Andersson
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Robert Raszuk
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Mark Smith
- RE: [spring] draft-ali-6man-spring-srv6-oam-00 Ron Bonica
- RE: [spring] draft-ali-6man-spring-srv6-oam-00 Adrian Farrel
- Re: [spring] draft-ali-6man-spring-srv6-oam-00 Tom Herbert
- Re: draft-ali-6man-spring-srv6-oam-00 Zafar Ali (zali)