[spring] Limited domains ...

Robert Raszuk <robert@raszuk.net> Wed, 27 May 2020 22:40 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 7EBE43A0D36 for <spring@ietfa.amsl.com>; Wed, 27 May 2020 15:40:00 -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 g6CiBSufiuou for <spring@ietfa.amsl.com>; Wed, 27 May 2020 15:39:58 -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 7395F3A0D2D for <spring@ietf.org>; Wed, 27 May 2020 15:39:58 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id k11so4737381ejr.9 for <spring@ietf.org>; Wed, 27 May 2020 15:39:58 -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=QUnkLN2YSaR5HbteyCyxyB6siGs72zMMvQ3x+CKqOr4=; b=EXHGjV/DWbJSbcIbmSLPCGOJqoc1++5ar1y0TTLM6vyD9qpsXJ3qIng4NbCRA0zrvX csxaMhKdNeFwdmjFhvwjN9BOJjO85+e6riy0e51Snbp4mlJJ8INY1WVmHyKi4BD5YcrA pnNoiUxK92dUPP87NELYjLhYP8Jblcm/y+xSDhaLj3R6trq9ZPtWdIhHqLVJfyEVS/Pd DSsn3HTJwjow7iaDaFmlx7tIczMM2zVbtgYEwm1ITu6fPZD+UmCuFBMglV98PIISR9fv +n4DX18U5cNZHvT0rtBoisJPjTGJFd8nC+6Auv70b2IdP2TXB3/6T0LbNMvFElMRnyrv /FBg==
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=QUnkLN2YSaR5HbteyCyxyB6siGs72zMMvQ3x+CKqOr4=; b=I1chVECjqmhLjbzohxrm4yvmCjQNWzs6idmfFsSyz6AbTSqWkxxmsH9+h6rH7EEI7X uj7YmZ0AkA0TFldUhuSPgfOPQnd1vHayFaHQzf6jD9lEOu0EeanzdAQOqcN2zr4cfBqu cDfYsGEVYA2cqafNr2d3Ex26GBkNRBYN5/H1qe6Osf+8aEsVelz5CeyOqc9YfJJX0pOH As3RKncMrA+rjU5C/fU5iHAEpwgnRz9xOJ9gS1KItfLCETrToT+Md3IEQMX5uIsAVqJu PiWH3PFO2N2vmJ8FHfnKutLLKEb7ChSclYVL+/jUq/kOJn60Dahxn8vIhiT/vo646gD+ CCFQ==
X-Gm-Message-State: AOAM533tgLb0VMIvkrdmk8Vf5mJL3a0KRv+LNf/zkUhMul1D/96q+BKm P783QZpkmBCRxPoN6HE1Hrlh0bmDGk5F23WP8bwUQp/p
X-Google-Smtp-Source: ABdhPJxLO55OTcOCRyvvhwqsxmK/LWdA6QcXe5Lf/m5qy205Falm5/noBkY2sBJAXN4vk4KDpe21jnS+IwqVzaw8O4Y=
X-Received: by 2002:a17:906:29d9:: with SMTP id y25mr480925eje.198.1590619196623; Wed, 27 May 2020 15:39:56 -0700 (PDT)
MIME-Version: 1.0
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <CAOj+MME+kkfTKFQaS1zvW7wgQvLqui6jFQH9-eai6eY32t9fmQ@mail.gmail.com> <b8cd530c-e07b-f74f-0f58-43414441b6ef@gmail.com> <1E239000-24BD-4E8A-A0D0-6876CE666137@cisco.com>
In-Reply-To: <1E239000-24BD-4E8A-A0D0-6876CE666137@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 May 2020 00:39:48 +0200
Message-ID: <CAOj+MMFCYoHD4hdXvVtfWUup3vbPBi5M-=mWUWHsm_d9RXpybg@mail.gmail.com>
To: "Zafar Ali (zali)" <zali@cisco.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000030239e05a6a8e4dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9NizWe9tZu3HxPQPYqXKt8sf4GA>
Subject: [spring] Limited domains ...
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: Wed, 27 May 2020 22:40:01 -0000

/*adjusting subject */

> The scope of CRH is “limited domain” and not the “Internet”.

Well that is only what the document under adoption call says.

However we have all seen described use cases over Internet  ... so much of
limited domain. Explanation given is that "limited domain" does not to be
continuous ... very clever indeed !

I am observing this point as my use case is also over Internet.

So if I apply any RH on my application host_1 carry it over Internet to my
server host_2 clearly those two hosts create a "limited domain".

Maybe we should just drop right here this "limited domain"
restriction/scope for any solution being discussed here ?

Thx,
R.


On Thu, May 28, 2020 at 12:32 AM Zafar Ali (zali) <zali@cisco.com> wrote:

> Hi,
>
>
>
> The authors of CRH has already have multiple drafts and more CP/ DP
> changes will be required. E.g., it will require
>
>    - ISIS changes (draft-bonica-lsr-crh-isis-extensions)
>    - To carry VPN information (draft-bonica-6man-vpn-dest-opt)
>    - For SFC (draft-bonica-6man-seg-end-opt)
>    - BGP changes (draft-alston-spring-crh-bgp-signalling,
>    draft-ssangli-idr-bgp-vpn-srv6-plus)
>    - PCEP extension (TBA)
>    - OAM for debugging the mapping table
>    - Yang interface
>    - More to come
>
>
>
> The scope of CRH is “limited domain” and not the “Internet”.
>
>
>
> Given this, where the IETF community discuss how these so-called “building
> blocks” fits together?
>
>
>
> If author’s claim is that the home for the architecture work is not
> Spring, then the authors should create a BoF in routing area to first
> defined architecture, use-case and requirements.
>
> This is the hard worked everyone else did before the CRH authors.
>
> Why they are looking for a short cut?
>
>
>
> CRH is a “major” change and outside the scope of 6man charter.
>
> It should follow the proper IETF review process.
>
>
>
> Why CRH authors are trying to “skip the queue” and “skip the routing
> area”?
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>