Re: [spring] draft-ali-6man-spring-srv6-oam-00

Tom Herbert <tom@herbertland.com> Thu, 23 May 2019 15:37 UTC

Return-Path: <tom@herbertland.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 3656112004A for <ipv6@ietfa.amsl.com>; Thu, 23 May 2019 08:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 67mUFrg6u8VS for <ipv6@ietfa.amsl.com>; Thu, 23 May 2019 08:37:01 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 D0E35120110 for <ipv6@ietf.org>; Thu, 23 May 2019 08:37:00 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id l3so7249026qtj.5 for <ipv6@ietf.org>; Thu, 23 May 2019 08:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMpy3vpyNyazjyMmvZyyliRIi/xtkhn028HFDUXqFCs=; b=yzrXzRtKVmjxOg5SB1YySPOVX6jRNSq2w1HaCS8pTq45HrpylU0ZAt/Pqr6g84lqiS HDipR1P5NMFDWuaO5lYx2/59OI+4X5KW0WrmeTGXrGiL+LHjgS8vzqH+ujvP4lkl3zMo 0h1b2cxqPF4HGWG2hIvKZjRy9GznGMMrlACEuGi6/t3R0f3RSmF+VoJ3k6bQHbvCNyJQ 8Gq+TTQJ4H7ughO5TTth3M5HM7qCjgjplFA/sDDXuC+lfapGO4Wo+buXek65zdHdC0Gp Qq/e2sqhrmdmZwGE44zSCQaBijThYSPqrnCPklaKo/hBQiuEjtpVavmxrWVmuuYEVU5S Y3YA==
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=lMpy3vpyNyazjyMmvZyyliRIi/xtkhn028HFDUXqFCs=; b=C4mdfqiwJcRb4sz/xnVjXgxdmC484QQZeb/eKID+CBo8E+pgJhD8rcjx8wHYCb5G2Y /6s6kbzmlAgx50v78nXk8/9gVzDs8O43JsWko/eksmRUz9VoT2DlI+nm7AL+Q/zl5d8f DcFaTqGa2S3mnfToS2rc8rxrcnC/yF5/1Kge3i+k1CetgVMKGNTbqe5EKi+7ip4LhebN afSlPoSQ3wnR3hrdw1Dd13v8qkTC/LvEs6BUSztBiToaK0ft2ROOk4sDm2jA4fVYrnNn P4vCRcTzzQs2dXfJiswHp/gCkGIKdlK2u3QAZBWUqUoBixd9qmwHwMeWzEJyce8W2rfz yohA==
X-Gm-Message-State: APjAAAUsYSOwSkuKpZdGc3M+0pTUpxvcrDDPT05qF/ZJOueb8UwE6WOd BBLRMozfOJC0cZtKSZ/uGQjPfRmfaWeJnGAAWpAIFQ==
X-Google-Smtp-Source: APXvYqyBxL424vLXDA16OekPzLsnLQ873lyv4zOaXpKN097J0U+9nplkMZKzmfylAwDgryoVkizsbGsht3thmUtpgcA=
X-Received: by 2002:a0c:b057:: with SMTP id l23mr44014762qvc.55.1558625819575; Thu, 23 May 2019 08:36:59 -0700 (PDT)
MIME-Version: 1.0
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> <2e4ecdcd-021c-e39b-fd12-7c43c5796e93@pi.nu> <BYAPR05MB4821355CAED735797DEA8AC2BE010@BYAPR05MB4821.namprd05.prod.outlook.com> <03b501d51144$47022970$d5067c50$@olddog.co.uk> <CAOj+MMG5t0TRvOmtqvo7f7os1OWJmfGAMmsJ2cykNv2f+R6mKw@mail.gmail.com>
In-Reply-To: <CAOj+MMG5t0TRvOmtqvo7f7os1OWJmfGAMmsJ2cykNv2f+R6mKw@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 23 May 2019 08:36:48 -0700
Message-ID: <CALx6S37KHbi=E6hKxPpjEpN0++HaXY6H+KRvKwB7HmuadKdTng@mail.gmail.com>
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
To: Robert Raszuk <robert@raszuk.net>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Rajesh M <mrajesh=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000505f2905898fdab3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/S5bLbt_YXOC_3SMNEyxqB_jYcrQ>
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 15:37:05 -0000

On Thu, May 23, 2019 at 3:18 AM Robert Raszuk <robert@raszuk.net> wrote:

> All,
>
> May I ask where this concern is coming from ?
>
> All hardware I am aware of can easily do simple match on the type field
> rather then make any assumptions on the order of EHs.
>
> So putting aside main topic of this thread (as honestly I see no relation)
> it would be pretty bad to mandate any order, then have some hardware making
> any assumptions on it.
>
> After all the entire concept of EH is to have v6 packet format extendable
> in the future - am I wrong ?
>

Correct. EH is the extensibility mechanism of IPv6 and RFC8200 prescribes
the requirements. This includes the ordering requirements of EH and that is
deployed. Similarly RFC8200 has no allowance for extension header insertion
or deletion (the problems with those have previously been discussed on the
list). Segment routing is one instance of routing header and doesn't define
a new extension header, so I'm also missing what the concern is with regard
to the requirements of RFC8200.

Tom


>
> Best,
> R.
>
> On Thu, May 23, 2019, 10:48 Adrian Farrel <adrian@olddog.co.uk> wrote:
>
>> Hi all,
>>
>> I don't think that a loose statement of recommendation is quite enough.
>>
>> Trivially, the IPv6 header must come first and the upper layer header
>> must come last.
>>
>> I think that although the inclusion of the two destination options
>> headers is optional, their positions are quite tightly constrained.
>>
>> Personally, I think this is a good candidate for mandating ordering and
>> probably using RBNF (RFC 5030) to describe the possibilities.
>>
>> Thanks,
>> Adrian
>>
>> -----Original Message-----
>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Rajesh M
>> Sent: 23 May 2019 09:35
>> To: Loa Andersson <loa@pi.nu>; Robert Raszuk <rraszuk@gmail.com>
>> Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; cfilsfil@cisco.com;
>> naikumar@cisco.com
>> Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00
>>
>> Yes its just recommended 😊
>>
>>
>>
>> Juniper Internal
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Thursday, May 23, 2019 9:13 AM
>> To: Rajesh M <mrajesh@juniper.net>; Robert Raszuk <rraszuk@gmail.com>
>> Cc: cpignata@cisco.com; SPRING WG <spring@ietf.org>; cfilsfil@cisco.com;
>> fbrockne@cisco.com; Ron Bonica <rbonica@juniper.net>; rgandhi@cisco.com;
>> naikumar@cisco.com; zali@cisco.com; ipv6@ietf.org
>> Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
>>
>> 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
>> <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 <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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B6IE46DSDAOG-FbuEW2lRdgM_6U&s=2ix9kKHToQUM7NsHhHBM_SSVgBdT3cz6d2L0OrXshSo&e=
>> >         <
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE7A&e=
>> >
>> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> > lman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
>> > WzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzuk
>> > hcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuN
>> > WxM&e=>
>> >
>> >
>> > _______________________________________________
>> > spring mailing list
>> > spring@ietf.org
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> > man_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
>> > zoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B
>> > 6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE
>> > 7A&e=
>> >
>>
>> --
>>
>>
>> Loa Andersson                        email: loa@pi.nu
>> Senior MPLS Expert
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6
>> <https://www.ietf.org/mailman/listinfo/ipv6>
>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>