Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 48F653A0F05;
 Mon, 16 Mar 2020 11:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level: 
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 iVn9B7bTBRKG; Mon, 16 Mar 2020 11:54:48 -0700 (PDT)
Received: from hickoryhill-consulting.com
 (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100])
 (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 887FD3A0F04;
 Mon, 16 Mar 2020 11:54:48 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS))
 x-ip-name=166.177.57.99; 
From: "Susan Hares" <shares@ndzh.com>
To: "'Acee Lindem \(acee\)'" <acee=40cisco.com@dmarc.ietf.org>,
 "'wangyali'" <wangyali11@huawei.com>, <lsr@ietf.org>
Cc: "'IDR List'" <idr@ietf.org>
References: <C6D08B31-9B12-4EDA-9858-630E64D81270@cisco.com>
In-Reply-To: <C6D08B31-9B12-4EDA-9858-630E64D81270@cisco.com>
Date: Mon, 16 Mar 2020 14:54:35 -0400
Message-ID: <008001d5fbc4$56e1d460$04a57d20$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQIKG6apchqMuNmCO00/HMllMCTq9qfjUSlw
X-Antivirus: AVG (VPS 200316-0, 03/16/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com 
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/idr/bpsSsD9EaP8bYGpFaeQBISlUTUk>
Subject: Re: [Idr] 
 =?utf-8?b?562U5aSNOiBbTHNyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?=
 =?utf-8?q?on_for_draft-wang-lsr-ospf-ifit-node-capability-02?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>,
 <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
 <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 18:54:51 -0000

+1  to Acee Comments from IDR co-chair.   We are trying to make life =
easier for you-all.=20

Thanks, Sue=20

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, March 14, 2020 2:18 PM
To: wangyali; lsr@ietf.org
Cc: IDR List
Subject: Re: [Idr] =E7=AD=94=E5=A4=8D: [Lsr] New Version Notification =
for draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,
Please add some more context to the draft as to how the information will =
be used. I say draft rather than drafts since you can really combine the =
OSPF draft, IS-IS draft, and BGP-LS draft into a single LSR document. =
For RFC 8379, we included the BGP-LS specification in the OSPF draft and =
the IDR chairs have agreed to this for simple encodings such as this =
one. =20
Thanks,
Acee

=EF=BB=BFOn 3/10/20, 4:46 AM, "wangyali" <wangyali11@huawei.com> wrote:

    Dear Acee,
   =20
    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:
   =20
    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 =E2=80=9CIFIT =
encapsulating node=E2=80=9D. 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 =E2=80=9CIFIT =
decapsulating node=E2=80=9D.=20
   =20
    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.
   =20
    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.
   =20
    Best regards,
    Yali
   =20
    -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
    =E5=8F=91=E4=BB=B6=E4=BA=BA: Acee Lindem (acee) =
[mailto:acee@cisco.com]=20
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: =
2020=E5=B9=B43=E6=9C=889=E6=97=A5 18:30
    =E6=94=B6=E4=BB=B6=E4=BA=BA: wangyali <wangyali11@huawei.com>; =
lsr@ietf.org
    =E4=B8=BB=E9=A2=98: Re: [Lsr] New Version Notification for =
draft-wang-lsr-ospf-ifit-node-capability-02
   =20
    Hi Yali,
   =20
    A couple of very basic comments on these drafts. They are definitely =
not ready for consideration.=20
   =20
        1. IFIT is never expanded as an acronym. Seems it should be as =
early as the title.=20
   =20
              OSPF extensions for Advertising In-Situ Flow Information =
Telemetry (IFIT) Capability
   =20
       2. You probably could come up with a more succinct acronym for =
IFIT.=20
   =20
       3. The has no specification of how the capabilities are used. Are =
they purely informational?=20
   =20
    Thanks,
    Acee
   =20
    =20
   =20
   =20
    On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali" =
<lsr-bounces@ietf.org on behalf of wangyali11@huawei.com> wrote:
   =20
        Dear all,
       =20
        I'm Yali. Following is a new version of I-D, =
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.
       =20
        Please let me know your questions and comments. Thank you.
       =20
        >>>>>>>>>>>
        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-capabi=
lity-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-capab=
ility
        Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-ospf-ifit-node-capabil=
ity-02
       =20
        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.
       =20
        Best regards,
        Yali WANG
        _______________________________________________
        Lsr mailing list
        Lsr@ietf.org
        https://www.ietf.org/mailman/listinfo/lsr
       =20
   =20
   =20

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

