IETF Logo Mail Archive

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Robert Raszuk <robert@raszuk.net> Fri, 26 February 2021 12:10 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DBF3A1421 for <lsr@ietfa.amsl.com>; Fri, 26 Feb 2021 04:10:01 -0800 (PST)
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=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 mgPsYtNgpmvm for <lsr@ietfa.amsl.com>; Fri, 26 Feb 2021 04:09:59 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 15F8E3A1420 for <lsr@ietf.org>; Fri, 26 Feb 2021 04:09:59 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id r23so10355909ljh.1 for <lsr@ietf.org>; Fri, 26 Feb 2021 04:09:58 -0800 (PST)
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=xgAouFeqs8xG4i7J24fa7ZosloIxuYWvNDivMnrVCQI=; b=Uph6Y8bvxnbf5hfQvjouadbOgQWhFzFORrRUPezpQjGEoPvhATO997aYoQxcwTIbZg HReWPqhGeCtLOWMS2akh1GNaUKG8XSQdWamqcx0Z9hMbXFevUqI4It2vy7b6uBx0iQWr PE/tyuQRcAgrCnfdN+OWN8TzO9MdiuEolhf/3u+ncIhMjAsG9agwvYiVNXtriX59mY8D IB8OCxHruf+UkoEHFUj8RVH1XJqp1JTuDmtMIQ1Qv+kOkbqu/tTtw4/I2trzDd+nYBSX 3+gytRb+UzQLm9zaNvzTIhrHfP+snQev1YxJ6NHM4XFM8Wzsc+bgk3YM59rQMKt+Pt+X IvZA==
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=xgAouFeqs8xG4i7J24fa7ZosloIxuYWvNDivMnrVCQI=; b=b/8tT2cdzi76U0OKViCnNzyuKSsnAT7HVAcb4XPoRrGm3CgwOHXEtfopnipi+d829/ RCEzrylzE9XX/l1EU7M1X6ijqh6gVZ36k5rZlZpfqcTdhhug4EJ7OK3S95Yr7yBbEOmn O4kfWc5YlCaob+cHaLzo0d4HGJSjewlQDKx9gcADB33JtFQg2bCnLiYZvm/lgDbJXqP+ nMTbV2sk5kO5mi1EYvXwCrL8+Xi8lE8mKgBOIqzt8ElE4OfDeiprYg5azTDkzhvUZ/Oi Qm0vMps4DcWke/jr6UKktJwCxPwrYgUO0PgOlaQQCtDdaLtVImpaQEnzJjZr03zkPsQF +HuQ==
X-Gm-Message-State: AOAM533bqXs9lGZBC2e44VbcQ1wWKzN+8JLoDrwTG+hH/pFEDYi11rr2 KHrnPhBp3+vTy77oSaKI2ByFko4U0A4cRJjlsO2bIA==
X-Google-Smtp-Source: ABdhPJx2tir7N5bZm8dsNC2uhRk3IwnELUXwCB27D0qJjXngoclejqGzljj6xRf3/mWSgfApjWBkDFQsgp7Vr/6QVFg=
X-Received: by 2002:a2e:145e:: with SMTP id 30mr1590829lju.199.1614341397308; Fri, 26 Feb 2021 04:09:57 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHsDgfD8avbRtvthhd0=c-X25L9HBc0yQTby4vFQKECLQ@mail.gmail.com> <7D53A65F-7375-43BC-9C4E-2EDCF8E138C8@chinatelecom.cn>
In-Reply-To: <7D53A65F-7375-43BC-9C4E-2EDCF8E138C8@chinatelecom.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 26 Feb 2021 13:09:46 +0100
Message-ID: <CAOj+MMEAJdqvmhfpVEc+M+v_GJ92hmjggbDWr3=gSAM4y3HkYg@mail.gmail.com>
To: Aijun Wang <wangaj3@chinatelecom.cn>
Cc: wangyali <wangyali11@huawei.com>, Huzhibo <huzhibo@huawei.com>, lsr <lsr@ietf.org>, Tony Li <tony.li@tony.li>, Tianran Zhou <zhoutianran@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000008878f005bc3c2570"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5S1vZM_JGwYghO_f26j3movJqzw>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 12:10:02 -0000

Aijun,

How multi instance is implemented is at the discretion of a vendor. It can
be one process N threads or N processes. It can be both and operator may
choose.

MFI is just one process - by the spec - so it is inferior.

Cheers,
R.


On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang <wangaj3@chinatelecom.cn> wrote:

> Hi, Robert:
>
> Separate into different protocol instances can accomplish the similar
> task, but it has some deployment overhead.
> MFIs within one instance can avoid such cumbersome work, and doesn’t
> affect the basic routing calculation process.
>
> Aijun Wang
> China Telecom
>
> On Feb 26, 2021, at 19:00, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
> Hi Yali,
>
>
>> If this was precise, then the existing multi-instance mechanism would be
>> sufficient.
>> [Yali]: MFI is a different solution we recommend to solve this same and
>> valuable issue.
>>
>
> Well the way I understand this proposal MFI is much weaker solution in
> terms of required separation.
>
> In contrast RFC8202 allows to separate ISIS instances at the process
> level, but here MFIs as defined must be handled by the same ISIS process
>
>    This document defines an extension to
>    IS-IS to allow *one standard instance* of
>
>    the protocol to support multiple update
>
>    process operations.
>
>
> Thx,
> R.
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>

v2.23.0 | Report a Bug | By Email