Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion

Robert Raszuk <robert@raszuk.net> Thu, 18 January 2018 23:15 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DEA129C6E for <lsvr@ietfa.amsl.com>; Thu, 18 Jan 2018 15:15:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 A3SVuQ5RteYN for <lsvr@ietfa.amsl.com>; Thu, 18 Jan 2018 15:15:36 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 80BC312D77D for <Lsvr@ietf.org>; Thu, 18 Jan 2018 15:15:27 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id 141so89942wme.3 for <Lsvr@ietf.org>; Thu, 18 Jan 2018 15:15:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jMC2GzY0QlB7TVGS1Jdo/5/EvEnCw3vFI0BnQ8+ClNA=; b=R3AGc1QdXxRAvlMNOxXCl/evIxIpzZErEx3QeJn9JjT4+g3+vqfbMEJfVmiHGEGJS8 HFgPIs9PQVybWiMB0jzmpBf+rAK71N9Miyw2WLn4CnztCu02+PLLQZM36LBd7VsOKp9S FhK3JfXM3xyOjygWexNGDYISNfU8usBY3JB7BQruDhUqzLSmvTQHioJerIFgyEfD+SP5 bEe8orgeXI2yRklzFJnBytYBqZv5SMFZXyKFa752p7q9XG/eJ80Oak2J2bsFTG5T4/vM JLqw8+JNWguVz/OTC4GuQGSDHRlKe6ZKdOHjfCk/ST7sFiVggW4n9pEaFtPZjOPEuf/F j3pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jMC2GzY0QlB7TVGS1Jdo/5/EvEnCw3vFI0BnQ8+ClNA=; b=Lsn7S+zNXNKlkVkGoRumLuEzvAf+1KHLCPpwlPUQ7n8Q56sxhz8nIOSWE3E2VMK1Vj q8nSlhjCCRDYidWfTxqdxQz/nQ3j3Bb3lLnd0Yl2F8At3baQJ/GslxY5tpDmAyRAtNAA EC2zb2KF+3HreysH0srvThzE630wm/DcZf32fabVuh9Y12ns4UO7dgM47VKlyjfEjABG GaCP9WQvCDswzg4T2WSPori/RLMLaXXoFOFFXAbj8yBYKktB6dqqnTYrrRU1ubI7p5R7 P1bCINFLP6gZvYyYjrk7qAvS261wI04XUZ+21L+9oXwU9LK0jNKoWLpUsIVD1k44eDxr 6Kcw==
X-Gm-Message-State: AKwxyte1Js0BXpeJWoMHcKUOq33zz53A5/yNDfINAnGZz0FUvenrYCZF Q14Bgp6XXXFgxcbZtm0Dkj3uMHH5K9hXTHMeknE=
X-Google-Smtp-Source: ACJfBotqZqB1Nv47L+SCgrc1waQusus+xaTS60VsGO9eOJZfVuefK3H55nXGUF7WdyBp20ncnQEQoKN8pQqthTyUqvE=
X-Received: by 10.28.88.129 with SMTP id m123mr2340876wmb.64.1516317325880; Thu, 18 Jan 2018 15:15:25 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.74.139 with HTTP; Thu, 18 Jan 2018 15:15:25 -0800 (PST)
Received: by 10.28.74.139 with HTTP; Thu, 18 Jan 2018 15:15:25 -0800 (PST)
In-Reply-To: <42C11665-5A01-4473-A9B3-0FE1F7B0D201@tony.li>
References: <CAJc3aaO8-OdJDNwNmofsadVWVdWdhk45p3Qs1DKjCvN1R_0vPA@mail.gmail.com> <D59B7ABE-F423-4F67-8DB3-2A177C6BD567@gmail.com> <F7708676-BE03-424D-8BBB-10AB0D1D3854@gmail.com> <m2inbystfc.wl-randy@psg.com> <71703812-2113-40A1-B299-251B9961E3A4@gmail.com> <CA+b+ER=4q8cfnQkk8zMBgUauaHvjyWDLvGG9P11UZ+Ndyt77kw@mail.gmail.com> <42C11665-5A01-4473-A9B3-0FE1F7B0D201@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 19 Jan 2018 00:15:25 +0100
X-Google-Sender-Auth: r86crbkL9IaGq4b05jZuPF6TNrY
Message-ID: <CA+b+ERn2xCd0Q-4YR3JWFSPCdHO=8SorErSquQXkWxNMvLbWfw@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Randy Bush <randy@psg.com>, "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>, Lsvr@ietf.org, Gaurav Dawra <gdawra.ietf@gmail.com>, victor@jvknet.com
Content-Type: multipart/alternative; boundary="001a114416bc9372800563152384"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/9ewG0f1JUCpCz5Bu8K98xWDdxUY>
Subject: Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2018 23:15:38 -0000

Well to the best of my understanding each AFI/SAFI as defined today carries
different address class.

With spf bgp we have a bit of a conflict as safi 1/1 or 2/1 may carry the
exact same prefix as new fancy bgp spf.

Clearly the authors of the latter need to differentiate how new SAFI is
going to interwork with existing eBGP in any hypothetical deployment.

- - -

Completely agreed on "rationale" part as far as forming WG. I was more
commenting on misleading community by setting up non wg forming bof just to
see it has suddenly resulted in forming two working groups.

I am wishing them all the best !

R.



On Jan 19, 2018 00:02, "Tony Li" <tony.li@tony.li> wrote:



Robert,

There are some questions on how bgp spf would select routes when executed
concurrently with "standard" bgp.

The answer by some is to run it in parallel and just call it bgp as
otherwise it will not sell ;)



And I believe that’s why there’s already an AFI/SAFI mechanism
incorporated: to de-multiplex information with alternate semantics.
Therefore, we do not need another mechanism.


Outside of all of this Alia and Alvaro are setting working groups for both
rift and bgp-spf based on their own judgements.

In Singapore we had a non wg forming bof on dc routing. How did that result
in creation of two new wg is unknown.

Is this how now IETF working groups get formed ? Behind the scene and
without even single document spelling out what is wrong with current
protocols ?



The creation of WGs has always been at the discretion of the Area
Directors.  Please see RFC 2418.  This RFC does NOT use the word
‘rationale’.

Tony