Re: [spring] Managing "global" SIDs

Robert Raszuk <robert@raszuk.net> Wed, 24 July 2019 20:41 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 8280212060C for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 13:41:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 X6oblJnzYm0n for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 13:41:34 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 49ABD120494 for <spring@ietf.org>; Wed, 24 Jul 2019 13:41:34 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id x22so41965548qtp.12 for <spring@ietf.org>; Wed, 24 Jul 2019 13:41:34 -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=XF8HJ/2eQXzr2Igd7kGvdhozmaz5FPN0ybz9slcxlCM=; b=NqX/Ngbzl9ab8RYn1modX1mDyMB930YTt4zmbWaU31CT1T/XrwBiNtWLtn+p9O81rG coOHu5rZ+jzTsW++I9izezepes9FrTRaCypebLYxVoLAgNLJG+jC+YZd3gmVm/GQqeeg c5Z2c++ZlkV/Nu2WJWY+soDP5h2BHLCOsYIYF2hrp1N+ASP2T7VYLZ5cUEGa7+hSPdrK G7VGl0MXHIAfC4PJzX7viDXd/S7oWRJ2xs8D2myZ9EmVmaPGelMdAmwlXGK4qZSMiglG NLwDZSQEl2A30Ff6wu/o6Tcoca92Dt8M4C+1rzXRs6JQF2tY3GfZqXDb8jfvxWFI8OVJ e//g==
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=XF8HJ/2eQXzr2Igd7kGvdhozmaz5FPN0ybz9slcxlCM=; b=MPrIRz1ryoDlVKOHEHQMMGhSS0EeqlHm7WUDITTLpXCQT3V/j0mCpwzhDJiEHXyIJ0 3nsrn4n34yI4FpNHRvginZqhwUZcgWgPXeuuynoBDQGgDZFs1tUrKf1SPGDGt7IMqEzD 4sDD4DPvjyhIuS5MXVgtm8L1zAVVN72xht8dOLVr3zjwvTQjQjIZ1DWIABwKbg1xW7MJ Uh8sygu9BEwHUfqroe0O2t5vSz1n0Zj8PxjiUlj1INSsYRwkabLHY01yGO/GZmPklEVd wWP3OuZl2S/+lffW1efG0iwj53UO9oZYss/k3fN+pyEoP/o7/yTrwbqjvwzxzgkDeXpJ IYxQ==
X-Gm-Message-State: APjAAAU+eWocP1xwO6pqKmJXSs4PvAAHYxcCv7+mIIShy2xy1iGKW+96 QAuN3a+WBDu1+GcmOEInFV0SWQQEfGkWtwd1VTX+Hg==
X-Google-Smtp-Source: APXvYqw7L1EeJLGYxJSiUigZznpcHOrAodaFGZjnH1mL65AxljF5tD8JEavOhbrkn2Fo81sRQE8ReJJU8mThn+HpVdk=
X-Received: by 2002:ad4:4562:: with SMTP id o2mr61275242qvu.116.1564000893356; Wed, 24 Jul 2019 13:41:33 -0700 (PDT)
MIME-Version: 1.0
References: <CABRz93VUjBJhCB8aq7goV6_ws=0jJb5UeOPSeapP4c3+WUbH8w@mail.gmail.com> <CA+b+ER=pKm=KrQP3BO+=Vz6ByLzvZvmeTFeqJr9ntiUg_L5UBA@mail.gmail.com> <CABRz93W=S2P9AoMmwhUxMtjXvE6K6q1TB3ax5kMwBO=qhptcQw@mail.gmail.com> <AM0PR03MB382888B3783231FA5A629D2C9DC60@AM0PR03MB3828.eurprd03.prod.outlook.com> <CAA=duU1YJDPFKtpXF+i3_YsqoOaN_n-P5dvVkTn3OY6nJ1=P2w@mail.gmail.com> <d44f23a9-4a6c-49fa-be2d-58ecad58d8e6@Spark> <FD8E9693-7FC6-40E6-AAD0-616EF3FA9FE2@gmail.com> <d3a6955d-17d1-4789-b9e8-3967bb31ed5a@Spark> <CAOj+MMGShYGDoXPwYVn7ijSsSZrAFaTxkHyuHeZVcwZmAAk8Jg@mail.gmail.com> <85a590d8-0eab-4627-a466-4ccf9008e3a6@Spark> <CA+b+ERmNe4igetSMeXaVO1rzcek0pyRBQC3UtgBu2VyzXXpbJA@mail.gmail.com> <67e17b21-f9f7-4dc4-9073-9706d4095935@Spark>
In-Reply-To: <67e17b21-f9f7-4dc4-9073-9706d4095935@Spark>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 24 Jul 2019 22:41:25 +0200
Message-ID: <CAOj+MMGH1byUZkrJUo0a9uoRk3O+55GybT51r2xHboVKKuHp7A@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Robert Raszuk <rraszuk@gmail.com>, vahid tavajjohi <vahid.tavajjohi@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Andrew G. Malis" <agmalis@gmail.com>, SPRING WG List <spring@ietf.org>, Kireeti Kompella <kireeti.kompella@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ad5edd058e7355b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/GII8r-LrIRUuOJWfTaWEJ1ZUAXA>
Subject: Re: [spring] Managing "global" SIDs
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, 24 Jul 2019 20:41:37 -0000

Jeff,

Please re-read my msg :)

I said that regardless what vendors will offer - those who actually run the
network will have their own *single* NMS to configure it in a fully vendor
independent way.

Take care,
R.

On Wed, Jul 24, 2019 at 10:36 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> some disagree:
>
> "Hi all,
>
> I think each vendor will uses its own NMS. So, it can’t be easy to manage
> global SID allocation with multi-vendor environment alongside multi-NMS.
> Therefore, PCE (standard) is better choice.
>
> Regards,
> Vahid
> "
>
> Cheers,
> Jeff
> On Jul 24, 2019, 4:35 PM -0400, Robert Raszuk <rraszuk@gmail.com>, wrote:
>
>
> > Sure, my point was that you won’t need a “NMS per vendor”
>
> I don't know any network which would use "NMS per vendor" today. In fact
> the entire reason to develop your own NMS is to have your own interface to
> the network provisioning to be vendor agnostic.
>
> Best,
> R.
>
> On Wed, Jul 24, 2019 at 10:29 PM Jeff Tantsura <jefftant.ietf@gmail.com>
> wrote:
>
> Robert,
>
> Sure, my point was that you won’t need a “NMS per vendor” and hence a need
> to agree on control plane protocol (PCEP). Abusing control plane for
> configuration… been there :)
> Specifically to PCEP point - PCEP creates ephemeral state, (not persistent
> across reboots), and hence rather unsuitable for configuration.
>
> Cheers,
> Jeff
> On Jul 24, 2019, 4:21 PM -0400, Robert Raszuk <robert@raszuk.net>, wrote:
>
> Jeff,
>
> > I think (sincerely hope) you are wrong, there’s a reason we have spent
> last 7 or so years working on YANG.
>
> Even if in the perfect universe all devices would support Yang models
> uniformly - customers are still going to use their private NMS systems
> except instead of CLI or xml as NNI to network elements they will use YANG
> models.
>
> r.
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>