Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Tony Przygienda <tonysietf@gmail.com> Thu, 15 February 2018 17:29 UTC

Return-Path: <tonysietf@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2212D574; Thu, 15 Feb 2018 09:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 rtQZgHWzTPQM; Thu, 15 Feb 2018 09:29:27 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 2C2F512D0C3; Thu, 15 Feb 2018 09:29:27 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id x21so2297404wmh.0; Thu, 15 Feb 2018 09:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WoIqFYihv84cH8uD3WWDOZ5wIP3AH8X7RCH6lhFaRGU=; b=IvARlbfjzTX/LMjx/RgGKWZ8V3FTDGajlLDhVS0K+Yy9sZpQ1dwkcKyZ9UeZsJEIHz p3cvtE2lBrmeEzq9qNoWns8S1h69V+eCrGr60ylPb9FYwmyLQWyv4Ax523dggAspEmn0 3VF0gHRFBzRYw5vb12WGaaYIYIuV3qQTBrB9mDbbQn8D1nUff3XzOGHU1lyRvl4TVbv0 512cKr0nlQgX+3ad1o7QUHrp3Z4kwilnoQjEYt+ria/xli/7jqLy4uXA50ua4YLsMcOv 1rg4Q1Xh/KEb7SVBz8DIjfDvLYXee9eLA3Yx7BlHixeEROxjKfh0GFzFbm5c8g/y6kCO ijyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WoIqFYihv84cH8uD3WWDOZ5wIP3AH8X7RCH6lhFaRGU=; b=N0HjZcBuiD0nxr8r4MFrPygDGcsYCmCTHdcbSG1Pv4AyH4pNkT7/cf5ckTth4SChk2 fuEZiZDwGDvvapJYcSvyEcCBvAwzL+HZk2St/ASmM8qgX+Cn7t3xSCFuPYMgZgByuTYB UFXNbZzpsx2Ivsrk9M01/x/kDHB8ER2sH2i7IkxgDk5cPt9Ht/zRj5dmmg8K5cj3I8i+ j9OOSFSfgVBHoru4awf8G9S37xDdSKhKlyq6bYS2qfCQY0FWdFsDsA7mI+RbMiXzZE2c ST+0JfNrrKLIPn6FtjpE4R/mjr42ONs9YPXN28/XjO2bqy74R08iFgxZDrKV1nC5cWM7 yaIA==
X-Gm-Message-State: APf1xPD+JPLDCXBAhy2tICgcs3tZz/HUgnPFBQLBuFCvArs9vPuxA3ez 19cIw3nuGhks03ndRTBEEQ/dcKhOimtJrP5n4JY=
X-Google-Smtp-Source: AH8x225+WzV6MkrF8n9BTB/F/orBFXr8zv7NyfUVf7Uu4mXju7WdwQKFNILhXXhOelJBpLmEz1+QwiHMk7QXMG/cBVg=
X-Received: by 10.80.135.154 with SMTP id a26mr4376483eda.82.1518715765740; Thu, 15 Feb 2018 09:29:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.231.7 with HTTP; Thu, 15 Feb 2018 09:28:45 -0800 (PST)
In-Reply-To: <CABFReBot3=NBuf=cfa3VhUd0X0VtEX-O5VbQgadNuvzXMkPCPg@mail.gmail.com>
References: <4A496052E7B7E84A9324854763C616FA377499CF@C111NTDEMBX52.ERF.thomson.com> <16253F7987E4F346823E305D08F9115A99A17846@nkgeml514-mbx.china.huawei.com> <D5A8BFBD-BDFA-40BA-9EB9-F4BF98AF12CA@nokia.com> <70842FFE-F12E-485D-A069-42977A8C0F7D@cisco.com> <F1CE0B21-32B5-43A2-81E6-258D9D9E1105@gmail.com> <63676097-F901-4B5F-9ED2-AB65ACE825A3@cisco.com> <3e06417f-f5af-6e95-2424-7e79b98153a8@juniper.net> <CA+wi2hN8KNSyCcspk6h5frSu8jrvqMPM8W3GOO1+HDfP4yM87g@mail.gmail.com> <CABFReBop9CtLexmzjNByad4PBj2r6XhiuUw+Nvto9xg8575xaA@mail.gmail.com> <CA+wi2hOw5oO8hgAUa=xu5m707i9=GHgNQ5hTF70iH=2OPdQg3w@mail.gmail.com> <CABFReBot3=NBuf=cfa3VhUd0X0VtEX-O5VbQgadNuvzXMkPCPg@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Thu, 15 Feb 2018 09:28:45 -0800
Message-ID: <CA+wi2hO2fzTRt7k9xDFiBhpw5wUo2N5WOUUGS0HeECf9Gh96pQ@mail.gmail.com>
To: Greg Shepherd <gjshep@gmail.com>
Cc: Eric C Rosen <erosen@juniper.net>, Xiejingrong <xiejingrong@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "bier@ietf.org" <bier@ietf.org>, "arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c0d18bb58030565439185"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/WySZ3ha5sVET6TO8PziMsTLydc8>
Subject: Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Feb 2018 17:29:30 -0000

On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <gjshep@gmail.com> wrote:

> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <tonysietf@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <gjshep@gmail.com> wrote:
>>
>>> For the record, there is no SR Registry. There is only an IGP Algo Type
>>> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
>>> section 8.5
>>>
>>
>> So is that a good idea, having multiple drafts in flight with fields
>> expecting to have magic couplings to each other while leaving e'thing
>> "unspecified" to "publish RFCs" while we "decide things later"?
>>
>
> That was a pivot, but still; there is no reference, there is no coupling.
>
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around
> for a while, and the IGP Algo registry will be tied to this draft and it's
> fate. If anyone is expecting to use this registry outside of the scope of
> this draft, it would be in their best interest to pull the registry
> description out into a separate draft.
>
>
OK, and I agree that if such a registry is pulled and under a clear charter
of mandating multiple technologies within an independent body then a
discussion starts to make sense and what the size of that should be given
that mandates algorithms over multiple technologies (SR, unicast, mcast,
whatever) and implies a "God's eye view" of all the elements of all the
technologies (and if a computation touches elements from two technologies
they become [optionally] coupled).  We are not talking IGP registry or
multicast computation registry or SR registry then but a "wider scope
registry". Yes, that is an intriguing thought with its own validity but
outside the scope of charter we're under as BIER.  Personally, I consider
multiple, if needed loosely coupled registries for each technology a less
centralized and hence "more Internet like" solution but I see how opinions
on such a thing can diverge ...

thanks

--- tony


>
>