[Lsr] 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

wangyali <wangyali11@huawei.com> Tue, 10 March 2020 08:46 UTC

Return-Path: <wangyali11@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 D37C83A0E38 for <lsr@ietfa.amsl.com>; Tue, 10 Mar 2020 01:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 efMBiO5FOgPU for <lsr@ietfa.amsl.com>; Tue, 10 Mar 2020 01:46:43 -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 60E473A0E2E for <lsr@ietf.org>; Tue, 10 Mar 2020 01:46:42 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 69CF9F3DA83B9F20F41F for <lsr@ietf.org>; Tue, 10 Mar 2020 08:46:38 +0000 (GMT)
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 10 Mar 2020 08:46:37 +0000
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 10 Mar 2020 08:46:38 +0000
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 10 Mar 2020 08:46:37 +0000
Received: from DGGEML524-MBX.china.huawei.com ([169.254.1.105]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Tue, 10 Mar 2020 16:46:31 +0800
From: wangyali <wangyali11@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02
Thread-Index: AQHV9f2kJ86jgOaxVUeWHoa+ZNP6iahBfL7w
Date: Tue, 10 Mar 2020 08:46:30 +0000
Message-ID: <1520992FC97B944A9979C2FC1D7DB0F404DB2314@dggeml524-mbx.china.huawei.com>
References: <7B791419-FF64-4771-BB5E-15ED40F5F91B@cisco.com>
In-Reply-To: <7B791419-FF64-4771-BB5E-15ED40F5F91B@cisco.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.186]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/jzm-kK_jy_E9FEBsgJE0VudZKg4>
Subject: [Lsr] 答复: New Version Notification for draft-wang-lsr-ospf-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: Tue, 10 Mar 2020 08:46:45 -0000

Dear Acee,

Thanks a lot for your comments. I have revised the title of drafts and will take your suggestion to add more text on how to use the IFIT Capability information, once the submission is opened. Here is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One network domain may consists of multiple IFIT domain. Within the IFIT domain, one or more IFIT-options are added into packet at the IFIT-enabled head node that is referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY be updated by IFIT transit nodes that the packet traverses. Finally, the data fields are removed at a device that is referred to as the “IFIT decapsulating node”. 

The IFIT data fields must not leak to other domains. So, the IFIT encapsulating node need to know if the decapsulating node is able to support the IFIT capability. So that it can decide whether to add the IFIT-option or not.

The solution is similar to RFC8491. We use IGP to advertise the capability, so that head node can use. By using BGP-LS, a centralized controller can also learn the IFIT Capability of nodes to determine whether a particular IFIT Option type can be supported in a given network.

Best regards,
Yali

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:acee@cisco.com] 
发送时间: 2020年3月9日 18:30
收件人: wangyali <wangyali11@huawei.com>; lsr@ietf.org
主题: Re: [Lsr] New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,

A couple of very basic comments on these drafts. They are definitely not ready for consideration. 

    1. IFIT is never expanded as an acronym. Seems it should be as early as the title. 

          OSPF extensions for Advertising In-Situ Flow Information Telemetry (IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are they purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali" <lsr-bounces@ietf.org on behalf of wangyali11@huawei.com> wrote:

    Dear all,
    
    I'm Yali. Following is a new version of I-D, draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.
    
    Please let me know your questions and comments. Thank you.
    
    >>>>>>>>>>>
    Name:		draft-wang-lsr-ospf-ifit-node-capability
    Revision:	02
    Title:		Extensions to OSPF for Advertising IFIT Node Capability
    Document date:	2020-03-09
    Group:		Individual Submission
    Pages:		7
    URL:            https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
    Status:         https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
    Htmlized:       https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-ospf-ifit-node-capability-02
    
    Abstract:
       This document defines a way for an Open Shortest Path First (OSPF)
       router originating the RI LSA to announce IFIT node capabilities
       within the entire routing domain.  A new optional TLV is extended to
       the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
       information.  Such advertisements enable IFIT applications in an
       operational network domain.  Here, the term "OSPF" includes both
       OSPFv2 and OSPFv3.
    
    Best regards,
    Yali WANG
    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr