Re: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Robert Raszuk <robert@raszuk.net> Tue, 26 May 2020 16:08 UTC

Return-Path: <robert@raszuk.net>
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 39F1D3A0893 for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 09:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 efrQ_vkjElnQ for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 09:08:30 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 C28F23A0844 for <ipv6@ietf.org>; Tue, 26 May 2020 09:08:29 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id l27so2305098ejc.1 for <ipv6@ietf.org>; Tue, 26 May 2020 09:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ew7EwRGb0+8MF7q1acgldXYgBrATZvTdCU6gc88rIhg=; b=TPv8HeBoe2ZVe173Hdl5PE0gsZpXeKE+/gmgeRfzBRTAMuquG7YjOcM3c6Bg7si0Ut Bs0aJuhU9QpEvP0fy4IBnLn83i1MYwuITbN6g9nD5qqEOGfBIBOrFn4ugr/rTtLoaDnT BQQ0j3k0bjwusLaftbLCteaCqGTIc0b/vpg8RnDRHvzboRAbiCqpv2zVTwSDreJ9ivAU 8+kV0Rubsc2YR43dJnS0PaKhPJ1RdTTG+asOGjnQ9VW3QyJ9XPE6hCKj5ye8MueOlFKQ A6rz30HNSoy3jkWxW10QSorDFxZi10v9gyElbDEKxGidb/8mEGEkZXMGwJ/MYXl/iBf2 6M1g==
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=ew7EwRGb0+8MF7q1acgldXYgBrATZvTdCU6gc88rIhg=; b=HDjrIFsnEH0NcIv/3ZsAz3+A8uWW/BQGisUz/KL40O0or/OhrL7U7R4rs0ai5hoO9c 52LtGldEiNdCsAioBpDR2CNc/+t7gj8clx5gqIQBDP6QMxUYGMsUusfp7ylcWCLmUwlN U1PhHZ4DVFTWZru/I9PrttfAwceX+kx4cltablm98hbuPE7e33WTI5eYjt6MnErV7jgk coOQi+i9hP6U2BqQ2gu4LEwhxALEFmzxRCMOIxtna3smcbI7lSkJ6rhn/E/yVHIalrvT G8MTRA+maV/LyDRNNY44cpkhcFxptXa3ZPg5nTV79HkrLMyLSQ3GPdOAi1T+3GCITmZ/ VTzg==
X-Gm-Message-State: AOAM532Je5nIYhUpFk83JlUa+CHMG1QRUhPPIjlm2NH4qbUcJIkPMpoQ 2UVe8FjomIMN7mUrMv1d39m+iqsadBse1FzCXgi2CA==
X-Google-Smtp-Source: ABdhPJxnWii+gUklgoZj4/TbHygxtH5Q6gSbQtUyXPQyT2zRjnZxFEvSMc9dTK6T5TupLVU8LMZN0Rlqzk0rmdDr2gY=
X-Received: by 2002:a17:906:b31a:: with SMTP id n26mr1695146ejz.441.1590509307976; Tue, 26 May 2020 09:08:27 -0700 (PDT)
MIME-Version: 1.0
References: <759F2FDB-C5ED-4FFA-9983-AE5D201E7CC5@cisco.com> <DM6PR05MB63480B378F943AA6B29A0CD8AEB00@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63480B378F943AA6B29A0CD8AEB00@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 26 May 2020 18:08:14 +0200
Message-ID: <CAOj+MMFC2pGuajw+bxRXJen634QLoAOV1ibNciJ3mgybb7TS9w@mail.gmail.com>
Subject: Re: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: "Zafar Ali (zali)" <zali@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000050751205a68f4eb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/clnBfSE5jkyQ-bIfJSeW9dq26HQ>
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: Tue, 26 May 2020 16:08:38 -0000

Ron,

"just works" is great. But let's zoom in and explore how it works in
practice.

Imagine on ingress PE I am mapping to engineered north CRH path flows using
TCP dst port 80 dst IPv6 X::Y

Further imagine on the very same PE I am also mapping flows using TCP port
22 going to IPv6 dst X::Y to take south CRH path via my network.

Then mgmt station does ICMP ping  and traceroute  ... and it wants to ping
and trace from this PE over both paths. What are the four commands I
would use ?

Many thx,
Robert.







On Tue, May 26, 2020 at 5:15 PM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

> Zafar,
>
>
>
> Tracing the path of an IPv6 packet containing CRH is somewhat easier than
> tracing the path of an MPLS LSP. In order to trace the path of an MPLS LSP,
> you need to deploy either RFC 4950 or RFC 8029. However, you don’t need to
> deploy anything special to trace the path of an IPv6 packet that contains
> CRH. Traceroute just works.
>
>
>
> Furthermore, when you trace the path of an IPv6 packet that contains CRH,
> each node returns either an ICMP Time exceeded message or an ICMP parameter
> problem message. From those messages, you can infer contents of the CRH-FIB
> at each node. So, there is no need for a special OAM mechanism to query the
> CRH-FIB.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Zafar Ali (zali) <zali@cisco.com>
> *Sent:* Tuesday, May 26, 2020 2:22 AM
> *To:* Greg Mirsky <gregimirsky@gmail.com>; Ron Bonica <rbonica@juniper.net
> >
> *Cc:* Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf..org>;
> Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>; Zafar Ali
> (zali) <zali@cisco.com>
> *Subject:* CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6
> Compact Routing Header (CRH)"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
>
>
> I agree with Greg. OAM is not only ping/traceroute.
>
>
>
> The CRH “mapping table” also bring additional operation complexities and
> hence need for OAM tools to debug.
>
>
>
> Even for the use of Traceroute in a CRH network, I would like to remind
> Ron of the following email thread.
>
> https://mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrcckxlUnJI$>
>
>
>
> “[RB] In reality, the debuggability characteristics of SRv6+ are very similar to those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID or SR-MPLS Label) to an IPv6 address.
>
> [RB] So, would you like to argue that debuggability is a huge issue in
> SR-MPLS?
>
>
>
> [ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in
> https://tools.ietf.org/html/rfc8029
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrccvQJcKGT$>
> .
>
> [ZA] Are you suggesting you will introduce something similar to RFC8029?”
>
>
>
> Ron then responded with the need for extending RFC 5837 (which is essentially bringing SR-MPLS OAM tool kit for IPv6).
>
>
>
> This is not surprising as CRH is just a poor re-engineering of SR-MPLS
> Data Plane with IPv6 Control Plane [RFC8663].
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *ipv6 <ipv6-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Saturday, May 16, 2020 at 8:46 PM
> *To: *Ron Bonica <rbonica@juniper.net>
> *Cc: *Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>,
> "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
> *Subject: *Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> Hi Ron,
>
> I agree that ICMP will work under CRH as it works today without it. But
> OAM is not only ping/traceroute. I think that there is value in checking
> out all known FM and PM OAM tools. Though, I would not be surprised to find
> out that everything works with CRH out-of-the-box way.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sat, May 16, 2020, 17:04 Ron Bonica <rbonica@juniper.net> wrote:
>
> Greg,
>
>
>
> The question may be moot. I don’t foresee any CRH OAM work. PING and
> TRACEROUTE “just work”.
>
>
>
>                                                          Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Greg Mirsky
> *Sent:* Saturday, May 16, 2020 4:24 PM
> *To:* Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>
> *Cc:* IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> *Subject:* Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Darren,
>
> I'm confused by what I think is a suggestion that any work on OAM relevant
> to an IPv6 EH does not belong in 6man WG. If that is what you've suggested,
> then what about draft-ietf-6man-spring-srv6-oam, which is in WGLC, and Ali
> and I are working to resolve comments? Are you suggesting that we should
> stop the authors of that draft find a different WG to anchor or hold the
> BoF? I'm puzzled.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sat, May 16, 2020 at 7:00 AM Darren Dukes (ddukes) <ddukes=
> 40cisco..com@dmarc.ietf.org <40cisco.com@dmarc..ietf.org>> wrote:
>
> Hi Bob and Ole.
>
>
>
> I’m not supporting the draft for adoption by 6man. I know you’re shocked
> ;).
>
>
>
> I have one main concern with 6man adoption that I think many can agree
> with.
>
>
>
> This draft will require substantial work related to the 16/32bit
> identifier (CP and OAM) that is not ipv6 nor ipv6 maintenance and for which
> this working group does not have a mandate nor, traditionally, expertise to
> drive.
>
>
>
> Others have said “this is not 6man’s concern” and I agree because 6man is
> an ipv6 maintenance WG, not the segment mapping working group.  I believe
> the authors should find a WG with that concern to drive this work. I know
> starting work without requirements is fun and exciting, but you will likely
> end up at the wrong destination.
>
>
>
> Brian had one suggestion on this topic.
>
>
>
> In the past I’ve suggested SPRING, or if the authors desire, a BOF to
> build consensus and gather requirements for its parent SRm6 work or some
> variant of it.
>
>
>
> I hope the authors, WG, chairs and AD consider these points during this
> adoption call.
>
>
>
> Thanks
>
>   Darren
>
>
>
>
> ------------------------------
>
> *From:* ipv6 <ipv6-bounces@ietf.org> on behalf of Bob Hinden <
> bob..hinden@gmail.com <bob.hinden@gmail.com>>
> *Sent:* Friday, May 15, 2020 6:14 PM
> *To:* IPv6 List
> *Cc:* Bob Hinden
> *Subject:* Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> This message starts a two-week 6MAN call on adopting:
>
>  Title:          The IPv6 Compact Routing Header (CRH)
>  Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
>  File Name:      draft-bonica-6man-comp-rtg-hdr-21
>  Document date:  2020-05-14
>
>  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK$>
>
> as a working group item. Substantive comments regarding adopting this
> document should be directed to the mailing list.  Editorial suggestions can
> be sent to the authors.
>
> Please note that this is an adoption call, it is not a w.g. last call for
> advancement, adoption means that it will become a w.g. draft.  As the
> working group document, the w.g. will decide how the document should change
> going forward.
>
> This adoption call will end on 29 May 2020.
>
> The chairs note there has been a lot of discussions on the list about this
> draft.   After discussing with our area directors, we think it is
> appropriate to start a working group adoption call.  The authors have been
> active in resolving issues raised on the list.
>
> Could those who are willing to work on this document, either as
> contributors, authors or reviewers please notify the list.   That gives us
> an indication of the energy level in the working group
> to work on this.
>
> Regards,
> Bob and Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr$>
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>