IETF Logo Mail Archive

Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

"Yangfan(Fan,IP Standards)" <shirley.yangfan@huawei.com> Wed, 23 March 2022 06:44 UTC

Return-Path: <shirley.yangfan@huawei.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 1BEB63A0DE3 for <idr@ietfa.amsl.com>; Tue, 22 Mar 2022 23:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 kWfaIbcTHriK for <idr@ietfa.amsl.com>; Tue, 22 Mar 2022 23:44:03 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FE73A0DBE for <idr@ietf.org>; Tue, 22 Mar 2022 23:44:02 -0700 (PDT)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KNf1T3xcyz67NW9 for <idr@ietf.org>; Wed, 23 Mar 2022 14:42:53 +0800 (CST)
Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 23 Mar 2022 07:43:59 +0100
Received: from kwepeml500003.china.huawei.com (7.221.188.182) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 23 Mar 2022 14:43:57 +0800
Received: from kwepeml500003.china.huawei.com ([7.221.188.182]) by kwepeml500003.china.huawei.com ([7.221.188.182]) with mapi id 15.01.2308.021; Wed, 23 Mar 2022 14:43:57 +0800
From: "Yangfan(Fan,IP Standards)" <shirley.yangfan@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
Thread-Index: Adg0iU/LdOzWENOQQCinCgHK9waz6gJ0FLkQAAl7rrA=
Date: Wed, 23 Mar 2022 06:43:57 +0000
Message-ID: <bdeea37d4ac94191b8012b42d1f5178a@huawei.com>
References: <00ca01d8348c$8b05d270$a1117750$@ndzh.com> <3da37a079bf2417997937ed616b72fbf@huawei.com>
In-Reply-To: <3da37a079bf2417997937ed616b72fbf@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.70]
Content-Type: multipart/alternative; boundary="_000_bdeea37d4ac94191b8012b42d1f5178ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xykl4BnFo_VKdG5tBZZjRICCV3E>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
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: Wed, 23 Mar 2022 06:44:10 -0000

Hi IDR,

I support the WG adoption of this draft.
Replies to chair's questions:

1)       Yes, the extensions  do help the IFIT capability  advertisement from tail to head.

The capability should be refreshed when BGP peers are reestablished.

2)       Yes, the extensions are correctly specified.

3)       It surely helps if authors can add texts on how different extensions are used in each case, but IMHO not much necessary.

4)       Yes, it does help.

Best regards,
Fan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:39 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Greeting:

This begins a 2 week WG Adoption call (3/10/2022 to 3/24/2022)
for draft-wang-idr-bgp-ifit-capabilities-04
https://datatracker.ietf.org/doc/draft-wang-idr-bgp-ifit-capabilities/

In your comments please consider if:

1) Do the additions to BGP (2 Communities and
TLV for next-hop-capability attribute)
help the distribute information regarding the  IFIT options
from tail (egress) nodes to head nodes (ingress)?

Are there any cases where these BGP
Communities should be removed or ignored?


2) Are the mechanisms (2 Communities and
attribute TLV) correctly specified?

3) How do these additions interaction with the
  With SR technology for IFIT described in
   draft-ietf-idr-sr-policy-ifit, and its
   use of RFC9012 (tunnel attributes)?

(Authors an example on how these
technologies work together or
 operate separately would be helpful).

4)  Will this addition help network operators
deploying IFIT technology?


Cheerily, Sue

v2.23.0 | Report a Bug | By Email