IETF Logo Mail Archive

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

liu.yao71@zte.com.cn Thu, 17 February 2022 06:51 UTC

Return-Path: <liu.yao71@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD63A149E; Wed, 16 Feb 2022 22:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kWpWfvNTonae; Wed, 16 Feb 2022 22:51:42 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD023A1469; Wed, 16 Feb 2022 22:51:40 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4JzlqH0bP2z8PxDM; Thu, 17 Feb 2022 14:51:39 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4Jzlph0Fy1z50FXn; Thu, 17 Feb 2022 14:51:08 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 21H6ovYT094799; Thu, 17 Feb 2022 14:50:57 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Thu, 17 Feb 2022 14:50:57 +0800 (CST)
Date: Thu, 17 Feb 2022 14:50:57 +0800 (CST)
X-Zmail-TransId: 2afc620df05198adf554
X-Mailer: Zmail v1.0
Message-ID: <202202171450576802065@zte.com.cn>
Mime-Version: 1.0
From: <liu.yao71@zte.com.cn>
To: <rbonica@juniper.net>, <jgs@juniper.net>, <draft-ietf-bess-srv6-services@ietf.org>, <bess-chairs@ietf.org>, <bess@ietf.org>
Cc: <etmetz@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl2.zte.com.cn 21H6ovYT094799
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 620DF07B.000 by FangMail milter!
X-FangMail-Envelope: 1645080699/4JzlqH0bP2z8PxDM/620DF07B.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/<liu.yao71@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 620DF07B.000/4JzlqH0bP2z8PxDM
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/He3P0Q9Y76VBhh9N_m_w-FuFRf0>
Subject: Re: [bess] =?utf-8?q?John_Scudder=27s_Discuss_on_draft-ietf-bess-srv?= =?utf-8?q?6-services-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Feb 2022 06:51:53 -0000

Hi,
Ron and John both mentioned that leveraging the existing AFI/SAFI may cause misunderstanding of the SRv6 service routes.
We encountered this problem during implementation and submitted a draft talking about this.
https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02
One solution(if new AFI/SAFI is not defined) we proposed in the draft is to define a new BGP capability code for for SRv6-based BGP service capability, and then SRv6 service routes would only be exchanged between devices that support it based on this capability.
Do you think this is a possible solution?

Regards,
Yao

v2.8.7 | Report a Bug | By Email