IETF Logo Mail Archive

[Idr] Re: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

liu.yao71@zte.com.cn Thu, 08 August 2024 01:53 UTC

Return-Path: <liu.yao71@zte.com.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 0BDB7C15152E for <idr@ietfa.amsl.com>; Wed, 7 Aug 2024 18:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M75HPghs4sW for <idr@ietfa.amsl.com>; Wed, 7 Aug 2024 18:53:34 -0700 (PDT)
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 CFD0AC14CE22 for <idr@ietf.org>; Wed, 7 Aug 2024 18:53:32 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4WfVST0mGyz8XrSC for <idr@ietf.org>; Thu, 8 Aug 2024 09:53:29 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (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 4WfVRv0Xffz4x6Cx; Thu, 8 Aug 2024 09:52:59 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 4781qpcf064189; Thu, 8 Aug 2024 09:52:51 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid203; Thu, 8 Aug 2024 09:52:52 +0800 (CST)
Date: Thu, 08 Aug 2024 09:52:52 +0800
X-Zmail-TransId: 2afb66b424f4ffffffffcdb-df431
X-Mailer: Zmail v1.0
Message-ID: <20240808095252554VlH9uJIF5w3ImX36fWk8n@zte.com.cn>
In-Reply-To: <SJ0PR08MB66220668F30E8B89E4C697C2B3B32@SJ0PR08MB6622.namprd08.prod.outlook.com>
References: SJ0PR08MB66220668F30E8B89E4C697C2B3B32@SJ0PR08MB6622.namprd08.prod.outlook.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: shares@ndzh.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4781qpcf064189
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66B42519.000/4WfVST0mGyz8XrSC
Message-ID-Hash: MUDBTFGA5TD43POPD5R4AOOPJOJPB6AM
X-Message-ID-Hash: MUDBTFGA5TD43POPD5R4AOOPJOJPB6AM
X-MailFrom: liu.yao71@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8bv_aLjP0-H205pDZLUNIA-DRxA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Sue,

I support the adoption of this draft. 
 

Does this BGP-LS addition help SR Egress Peering points in operational networks? 
Yes, it's helpful for for the network where LAGs have been implemented or are under consideration for deployment.

Does this draft handle the BUM traffic in a way that Prevents looping? 
This document does not increase the risk of looping itself and existing mechanisms to prevent looping for BUM are applicable，session 5 has provided some recommendations.

Are there any problems in the technology described? No.


Yao


Original


From: SusanHares <shares@ndzh.com>
To: idr@ietf.org <idr@ietf.org>;
Subject: [Idr] WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

_______________________________________________
Idr mailing list -- idr@ietf.org
To unsubscribe send an email to idr-leave@ietf.org
 

IDR WG: 
 
This begins a 2 week WG adoption call for  
draft-lin-idr-sr-epe-over-l2bundle-07.txt
https://datatracker.ietf.org/doc/draft-lin-idr-sr-epe-over-l2bundle/
 
 
The authors should reply to this email with an 
IPR statement indicating whether they know of an intellectual property. 
 
This document describes how to support Segment Routing 
BGP Egress Peer Engineering over Layer 2 bundle members. 
This document updates [RFC9085] to allow the L2 Bundle Member 
Attributes TLV to be added to the BGP-LS Attribute
associated with the Link NLRI of BGP peering link.
 
 
In your comments regarding adoption,  please consider 
 

Does this BGP-LS addition help SR Egress Peering points


in operational networks?  

Does this draft handle the BUM traffic in a way that 


Prevents looping?
(Broadcast, Unknown Unicast, and Multicast (BUM))

Are there any problems in the technology described? 


 
Cheerily, Sue Hares

v2.26.15 | Report a Bug | By Email | System Status