Limited domains ...

Robert Raszuk <robert@raszuk.net> Wed, 27 May 2020 22:40 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 2B7393A09D2 for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 15:40:01 -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 glZshEhx0-uL for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 15:39:58 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 515D63A0C66 for <6man@ietf.org>; Wed, 27 May 2020 15:39:58 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id l21so29962998eji.4 for <6man@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=S+uTfYYoM/WKI2kx2SoVSoi3OZgSE142Lsqi1e68zcP6s+d2HSMCW9JvN9qP1DgJVd ZUa6Fj7EA68jeGGW/fFnk1nB9UubWZK5VsrcJhBAhKoeNNKIC7EjIGhga+UDddDcULST fxx/Jh6+ZIjGbOu5I7Y6X/niTg8Yv1iwdM0u7JscgpzHS0s7v6o9AtMR/iZfU1JnKAk3 pBdK4mRxUBgBtYsrolWpBji6wectbC2yyM7lpHxYmfWXISmUWeYYx0KUVUW330uU0vgN LSu0zenH5MRr6XTSRv0SuPth7KSboQUjFhp4lVo4XT8BEH2LYPNYR7ndeZa2qOLvul8O N5Dg==
X-Gm-Message-State: AOAM533d03D+DVkz5ssLN6YdiE+p/Am0qFIPYUlDE+/IUMAyrEs8xPvh 0tcYG6Dxr3zDua/jHFXSysr1nfOSfB1oMBaji/nMEw==
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>
Subject: Limited domains ...
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/ipv6/eukWufHfApFJBqiDQPoCB5FrBmc>
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: 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
>