Re: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Tianran Zhou <zhoutianran@huawei.com> Mon, 06 April 2020 14:33 UTC

Return-Path: <zhoutianran@huawei.com>
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 7E39B3A08B0 for <lsr@ietfa.amsl.com>; Mon, 6 Apr 2020 07:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gR8gU1ZVwLet for <lsr@ietfa.amsl.com>; Mon, 6 Apr 2020 07:33:40 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A013A08B8 for <lsr@ietf.org>; Mon, 6 Apr 2020 07:33:39 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 84EF16052598421C338A; Mon, 6 Apr 2020 15:33:34 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Apr 2020 15:33:33 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 6 Apr 2020 22:33:31 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1713.004; Mon, 6 Apr 2020 22:33:31 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: wangyali <wangyali11@huawei.com>, "Acee Lindem (acee)" <acee@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
Thread-Index: AdYMH2FT4znh1B99QwGc4A3ZVrv7QQ==
Date: Mon, 06 Apr 2020 14:33:30 +0000
Message-ID: <3e36da22f09b4da39f19306d86c27de8@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.220.197]
Content-Type: multipart/alternative; boundary="_000_3e36da22f09b4da39f19306d86c27de8huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ygRr-Hhz_y3AexqbcUQx5xdc6bs>
Subject: Re: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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: Mon, 06 Apr 2020 14:33:47 -0000

Hi Greg,
Thanks for your replay. Please see in line.

Cheers,
Tianran

发件人: Greg Mirsky [mailto:gregimirsky@gmail.com]
发送时间: 2020年4月4日 6:13
收件人: Tianran Zhou <zhoutianran@huawei.com>
抄送: wangyali <wangyali11@huawei.com>; Acee Lindem (acee) <acee@cisco.com>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Christian Hopps <chopps@chopps.org>; lsr@ietf.org
主题: Re: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Hi Tianran,
thank you for your kind attention to my questions. Please find my notes in-lined below under the GIM>> tag.

Kind regards,
Greg

On Thu, Apr 2, 2020 at 11:33 PM Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote:
Hi Greg,

Good questions. Please see my reply in line.

Thanks,
Tianran

From: Greg Mirsky [mailto:gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>]
Sent: Friday, April 3, 2020 6:58 AM
To: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>>
Cc: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Subject: Re: [Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Hi Yali, et al,
thank you for the interesting discussion. I have several questions about the purpose of advertising ifit capabilities in IGP (and in general):

  *   Do you see a capability to export telemetry information as a mandatory or optional?
What’s the context with this question? Frankly, I did not have a deep well thinking on this question. But in our case, I wish it’s mandatory.
GIM>> If it is mandatory, then all nodes in a domain support IFIT and, consequently, there's no need to advertise the capability in the homogeneous, IFIT-wise, domain. Would you agree?

ZTR>> I am sorry, I did not understand  your question before. Yes, you are right. So here we assume that not all nodes support IFIT, and different nodes may support different data plane options.

  *   Do you expect that a segment route to be constructed to prefer ifit-capable nodes comparing to nodes that are not?
Yes. This is one use case. As my echo to Robert, we want to achieve the SLA assurance network. We think the capability for visibility to verify the SLA compliance, and also the capability to get the accurate measurement for path computation should be considered. Should be considered from the very beginning when we compute the path.
GIM>> I understand that IFIT-capability might be used as one of CSPF constraints. But, as I think of it, it can simply be discovered in the course of running on-path telemetry collection. Would you agree?

ZTR>>We also considered some options for the IFIT-capability discovery. It seems what we proposed here is more elegant and straight forward.
Thank you for your kind consideration of my questions.

Regards,
Greg

On Wed, Apr 1, 2020 at 8:13 PM wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>> wrote:
Hi Acee, Chris and Les,

This is Yali. Many thanks for your kind comments and suggestion.

Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that there's another RFC7883 that advertising S-BFD discriminators in IS-IS. In my understand, BFD is a protocol to detect faults in the bidirectional path between two forwarding engines, including interface, data links, etc.

Similarly, IFIT provides a complete framework of a family of on-path telemetry techniques, which are used to monitoring performance metrics of service flows, e.g. packet loss, delay. So we consider there's a same methodology with S-BFD that advertising IFIT node capabilities.

Please let us know your comments and opinion. Thanks.

Best regards,
Yali

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:acee@cisco.com<mailto:acee@cisco.com>]
发送时间: 2020年4月1日 20:29
收件人: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>; wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>>
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member...

On 4/1/20, 8:08 AM, "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>> wrote:

    There is also a difference between some of the existing applications advertised in IGP capabilities. For example, MSD is used with the routing information to construct SR paths. The information for all these OAM mechanisms doesn't share this affinity. Also, it seems like a slippery slope in what is needed for each of the mechanism.
    Thanks,
    Acee

    On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> on behalf of zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote:

        Hi Les,

        Thanks very much for your suggestion. I have a quick look at rfc6823. Sounds like a good idea. I will think about it.

        Cheers,
        Tianran

        -----Original Message-----
        From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com<mailto:ginsberg@cisco.com>]
        Sent: Wednesday, April 1, 2020 1:47 PM
        To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>
        Cc: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
        Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

        Tianran -

        I am very much in agreement with the points Chris has made.

        IGPs do not exist to advertise capabilities/configure applications - which seems to me to be what you are proposing here.
        The fact that you can easily define the encodings does not make it the right thing to do.

        This issue was discussed at length in the context of https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I would not object - though I do think Chris has correctly pointed out that NETCONF/YANG is likely a more appropriate solution for your use case.

           Les


        > -----Original Message-----
        > From: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
        > Sent: Tuesday, March 31, 2020 7:53 PM
        > To: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>
        > Cc: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>>; Les Ginsberg (ginsberg)
        > <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
        > Subject: RE: [Lsr] A new version of I-D,
        > draft-liu-lsr-isis-ifit-node-capability-02
        >
        > Hi Chris,
        > Thanks for your quick reply, and please see inline.
        >
        > Cheers,
        > Tianran
        >
        > -----Original Message-----
        > From: Christian Hopps [mailto:chopps@chopps.org<mailto:chopps@chopps.org>]
        > Sent: Wednesday, April 1, 2020 10:00 AM
        > To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
        > Cc: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; wangyali
        > <wangyali11@huawei.com<mailto:wangyali11@huawei.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>;
        > lsr@ietf.org<mailto:lsr@ietf.org>
        > Subject: Re: [Lsr] A new version of I-D,
        > draft-liu-lsr-isis-ifit-node-capability-02
        >
        >
        >
        > > On Mar 31, 2020, at 9:28 PM, Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
        > wrote:
        > >
        > > ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing
        > protocol, which is better. But I did not see the modification to
        > routing protocol with some TLVs is a heavy work, or more complex than
        > NETCONF/YANG.  I see both are available and useful.
        >
        > I'm not sure what you mean by boiling the ocean. I'm saying that YANG
        > is built and intended for querying capabilities and configuring
        > routers. Why isn't that where you are looking first for configuring your monitoring application?
        >
        > ZTR> I know NETCONF can do both query and configuration. And I know
        > resent YANG-Push improvements to reduce the polling.  But routing
        > protocol solutions are also widely used for this. There are already
        > many RFCs and implementation practices. We considered both ways, and
        > aimed for different scenarios.
        >
        > You don't see the major difference between writing a YANG model vs
        > modifying all of the standard IETF routing protocols?
        >
        > ZTR> I know many differences between NETCONF and routing protocol.
        > There are many details on both interfaces, implementations, scenarios
        > when comparing them. That's what I mean boil the ocean.
        > Here I do not know what's the "major difference" you mean?
        >
        > Thanks,
        > Chris.

        _______________________________________________
        Lsr mailing list
        Lsr@ietf.org<mailto:Lsr@ietf.org>
        https://www.ietf.org/mailman/listinfo/lsr




_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr