Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

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

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6833A0F8F for <spring@ietfa.amsl.com>; Tue, 26 May 2020 12:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 O9q4d0QdXVdG for <spring@ietfa.amsl.com>; Tue, 26 May 2020 12:43:53 -0700 (PDT)
Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) (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 B25DB3A0FC6 for <spring@ietf.org>; Tue, 26 May 2020 12:43:52 -0700 (PDT)
Received: by mail-ej1-x641.google.com with SMTP id l27so3012805ejc.1 for <spring@ietf.org>; Tue, 26 May 2020 12:43:52 -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=N3FNxd4A/B/IX8fSYFPZnYFfZk6sp6k3g0xkMWVzmBw=; b=HcwSY+O3FiVkyjSizhGboiqE/qETB/fWy/vRKH463IfRQ2pR6DfeJAEzXztA0+iEkH 0lobzqf9+g3LTqWVxwNGdX2Vio0AsLfS30gcq/AyY4WUM2PejbwcOkTQCi6hG2jdHVyc 7ZcYQim5PLCKDt8K+UfVC1YB+qSQlCZtAgQ+RyhGY5mXXMwWCZP5b/uzFgidwH2U+KLh uxbpBmmCDCfxamZ0XDtusZlDs31RgFHioip6SGF8XREuZbFaQZuljGhNExMu4mSxqWgQ fgqRid0eigLCM3/y1+uWhMWXoDvBBvF8RzWmjMIyQqIdqpsjo29ur7rJCcaeSV4ppxhU 8qqw==
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=N3FNxd4A/B/IX8fSYFPZnYFfZk6sp6k3g0xkMWVzmBw=; b=gRgI6ztFpCEQQzJkC8tg5SnIoDvo8oN8x8xd6hkqJUIviOBLktfS2hIyNj5BXDoC34 nZW1X4uBwOJIENkBlyyRoAAzHE9PnBHHc7JzyKy4XG91bgzbuUVvmR01a6Sw9YaGbacm FG7WU2AsE/RDCaloU/zcITDELV8zjdtHNr/fwEUFsu+WindPn4Nv2Ro3mln0qgQwF1ud IzR6LUoE1fQFYOakXiVY4JLtz5LXY6JDG+YEaGpx8Jnieq/1yFIaIGDjcyNgWPxD5foA iZk0+OLuhq579qmYV/DgonKhUkWhInq48ViZ7fTNF59EzL1PwlcNYGhi3MK18kZNCCJO TGgg==
X-Gm-Message-State: AOAM532ikZd5oNz3+HdKPP/FhqwWPmFJXi1UvO1IZ0v0ccwLmr4xV4ij v71/R2oJ2KnXs/eDFDyElWrArhXOo5zTGqMgLyvkjcSbhio=
X-Google-Smtp-Source: ABdhPJzqvUiEiiQOsAdVEoFGkwQQduh+GB4VXQt9HS86RSGsZ3RCApYbAbRsV/fL8mDMZVe1513PXT+NXHbz0swfQjM=
X-Received: by 2002:a17:906:17d1:: with SMTP id u17mr2520035eje.242.1590522230260; Tue, 26 May 2020 12:43:50 -0700 (PDT)
MIME-Version: 1.0
References: <A87CBF94-3E2C-4AA9-9034-57248832D372@nokia.com> <51B3FE50-DF61-49B3-9A28-B8B70E5DF6ED@steffann.nl>
In-Reply-To: <51B3FE50-DF61-49B3-9A28-B8B70E5DF6ED@steffann.nl>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 26 May 2020 21:43:41 +0200
Message-ID: <CAOj+MMHRAuT1931reBLe-1UQ5gac4RmCtybk-OXn03atoAjDkA@mail.gmail.com>
To: Sander Steffann <sander@steffann.nl>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ad8fa05a692503d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/G65fr9XjmCMq66pxLyKEJwVfiPo>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 19:44:01 -0000

Hi Sander,

Ok your use case is indeed original and valid. No encapsulation at all.
Just plain end to end IPv6 header. Cool so far.

If so honestly for your use case I must observe that SRv6 with basic 128
bit SIDs is much easier to use.

Any scheme which requires mapping really works well in a limited domain or
at least over same control plane reach. How are you going to educate end
hosts as those would presumably apply CRH on the CRH content to impose ?

And how fast would that content get adjusted upon network changes ?

> RFC8663 doesn't work between domains that are not directly connected.

Oh it works just fine specifically over not directly connected domains. If
you can exchange mapping via some control plane between non connected
domains you will get next SID which you put in the DA of the packet.

Last just FYI you are violating CRH assumptions already ... draft says:

Is designed to operate within a network domain.


You said:

"I want a solution where the connectivity between the domains is plain IPv6
(e.g. the internet). "

CRH draft does not assume the use between domains over Internet. I think
such intended use case needs to be taken as consideration for the adoption
too.

Thx,
R.