IETF Logo Mail Archive

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

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 21 March 2022 06:21 UTC

Return-Path: <wangaijun@tsinghua.org.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 8AC303A1215 for <idr@ietfa.amsl.com>; Sun, 20 Mar 2022 23:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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 66Q9QYCewaiN for <idr@ietfa.amsl.com>; Sun, 20 Mar 2022 23:21:44 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD5A3A1216 for <idr@ietf.org>; Sun, 20 Mar 2022 23:21:41 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 40F761C027A; Mon, 21 Mar 2022 14:21:37 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Susan Hares' <shares@ndzh.com>, idr@ietf.org
References: <00ca01d8348c$8b05d270$a1117750$@ndzh.com>
In-Reply-To: <00ca01d8348c$8b05d270$a1117750$@ndzh.com>
Date: Mon, 21 Mar 2022 14:21:37 +0800
Message-ID: <024201d83ceb$ebaf6070$c30e2150$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0243_01D83D2E.F9D51170"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQILMVkCQ/KfhDTgaiYAX9qxniU+q6xjc7gw
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWRpLTklWGkJLTBkYSk NKSUhJVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWU9LSFVKSktISkxVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6KyI6Lww4MT5OMxgsT0xNLy8v HCMKCT5VSlVKTU9MQ09ITUJMTUxOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpIS0NJNwY+
X-HM-Tid: 0a7fab2362b3d993kuws40f761c027a
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XcqjxVzvu-T6R-2Q-qOi4uVXXmY>
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: Mon, 21 Mar 2022 06:21:51 -0000

Hi, Sue:

Support its adoption.

I think the per-service iFIT capabilities advertisement is necessary,
especially for the BGP related services that span the different ASes, but in
the one limited domain.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: idr-bounces@ietf.org <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