IETF Logo Mail Archive

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

"zhuyq8@chinatelecom.cn" <zhuyq8@chinatelecom.cn> Fri, 18 March 2022 03:43 UTC

Return-Path: <zhuyq8@chinatelecom.cn>
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 A6D143A1519 for <idr@ietfa.amsl.com>; Thu, 17 Mar 2022 20:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 GQP8OfeAZQC6 for <idr@ietfa.amsl.com>; Thu, 17 Mar 2022 20:43:29 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADC73A1368 for <idr@ietf.org>; Thu, 17 Mar 2022 20:43:28 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.188:58054.1866470569
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-61.144.66.66 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 133C2280129 for <idr@ietf.org>; Fri, 18 Mar 2022 11:43:15 +0800 (CST)
X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn
Received: from ([172.18.0.188]) by app0023 with ESMTP id 911defe8de364314bf4187324f35d265 for idr@ietf.org; Fri, 18 Mar 2022 11:43:20 CST
X-Transaction-ID: 911defe8de364314bf4187324f35d265
X-Real-From: zhuyq8@chinatelecom.cn
X-Receive-IP: 172.18.0.188
X-MEDUSA-Status: 0
Sender: zhuyq8@chinatelecom.cn
Date: Fri, 18 Mar 2022 11:43:14 +0800
From: "zhuyq8@chinatelecom.cn" <zhuyq8@chinatelecom.cn>
To: idr <idr@ietf.org>
References: <00ca01d8348c$8b05d270$a1117750$@ndzh.com>, <f2166c7f83054905a7cbe41ed2ce3e92@huawei.com>, <2022031717505658517623@chinatelecom.cn>, <052c0e5d3bdd43f4a63e2d35bc81c5dd@huawei.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.22.188[cn]
Mime-Version: 1.0
Message-ID: <2022031811431455194827@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart366563133114_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uoyKDcTvIp5nSYG59IfG3wcfscw>
Subject: [Idr] 回复: RE: 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: Fri, 18 Mar 2022 03:43:34 -0000

Hi All,
 
I have read this draft, this draft defines extensions to BGP to advertise the IFIT capabilities of the egress node to the ingress node in an IFIT domain.
This draft does not conflict with draft-ietf-idr-sr-policy-ifit and is very useful in the networks where no controller is introduced, it help network operators to deploy IFIT in their networks.
I support the WG adoption of this draft.
 
Cheerily,
Yongqing 



zhuyq8@chinatelecom.cn

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:39 PM
To: 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