Re: [spring] Managing "global" SIDs

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 24 July 2019 20:36 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 D78DD1205F8 for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 13:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com
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 ENxcqKpFJIsw for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 13:36:51 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 DF0A1120494 for <spring@ietf.org>; Wed, 24 Jul 2019 13:36:50 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id d23so46912656qto.2 for <spring@ietf.org>; Wed, 24 Jul 2019 13:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=3ZaxgV/DnQUIPKtNgY3ygT+MGB6XVY0Xit4S21ZGgNg=; b=uzmUxEfANc37mZFTYdWVaprSivwcNN23XGZ+ehGzsdygY0NscN2rxiCxagJJCZM1w+ lVqGziDFK+IFXE+/6syqlw5/zXriejMTRaoySMhijFJR26a8wC36UqgxR5kdU1fV9Lqr YBmCh0SkW4LL3S471THRC+3fUnVOrnmOpJc6IyQfGcUX05tP9mIwhoDYkmkJ9lHkGejp t1JGwENpkT5tDD580PEBogmj+rNfebSC1fC7BZISDGiqo1116G79YPtAgjjrgSy1XtrB JJwLUJ7byp1UgqUUME8fWzk0qejfywoOQD+Q9vKhNzXO0ox/ZV6rrQBhYxRDwQ7PZA6d 1VHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=3ZaxgV/DnQUIPKtNgY3ygT+MGB6XVY0Xit4S21ZGgNg=; b=pmBzxvMnDfwf6gB2eHMlrmYl57VEu5cFfg+QQObGd1f9Vp56OE4Sr3KAueO0zsPPfN Jic3kidqgcKAjSiPIXeXBJ0BtIQbzR+tg/IitINZgv+bEn55FmFIM3cn656qjLfvP+Av TB+uBj8xQxYOBbF3OXNY2igO1p/UP2wpRHnSB2kyJV/6IzDlroT6tFj4qRslQlr53+3r q+U83LwAlx/1CabvR1oCSgNmdZGvp0VFndkwwwJHpGSflZw9ySMgBGPc8r/lYpQ3PcID lsCExWygDJca6rKPpvaZvUkkBp8QcAN5WjksUoyOl9mz50TanM88hZ5FI1K57ob4ijKW rgZw==
X-Gm-Message-State: APjAAAVRkHeLS02qkihFv5nX2WjiBi9xU6diT1apNE4NtI8uRias9cLG nANHts8UDQ8LBGgx/HA1ZRs=
X-Google-Smtp-Source: APXvYqxjSRCLeBf40e+qPo7JmcaOnaOCLwaXo056M54H8R9lRGXYsLhwJo75Akgl+uDPbA1KQWaa2Q==
X-Received: by 2002:a0c:a8d1:: with SMTP id h17mr60248206qvc.117.1564000610077; Wed, 24 Jul 2019 13:36:50 -0700 (PDT)
Received: from [2001:67c:1232:144:2083:8e8c:ff7f::] ([2001:67c:1232:144:cd8d:8bfe:dd2a:67e5]) by smtp.gmail.com with ESMTPSA id b13sm29224077qtk.55.2019.07.24.13.36.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 13:36:49 -0700 (PDT)
Date: Wed, 24 Jul 2019 16:36:43 -0400
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Robert Raszuk <rraszuk@gmail.com>
Cc: vahid tavajjohi <vahid.tavajjohi@gmail.com>, SPRING WG List <spring@ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Andrew G. Malis" <agmalis@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Message-ID: <67e17b21-f9f7-4dc4-9073-9706d4095935@Spark>
In-Reply-To: <CA+b+ERmNe4igetSMeXaVO1rzcek0pyRBQC3UtgBu2VyzXXpbJA@mail.gmail.com>
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>
X-Readdle-Message-ID: 67e17b21-f9f7-4dc4-9073-9706d4095935@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5d38c160_3fa62aca_12dc6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/smcdMha7mpl3ne8oBkEvZG3j9As>
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:36:53 -0000

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.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >