IETF Logo Mail Archive

Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

"zhuyq8@chinatelecom.cn" <zhuyq8@chinatelecom.cn> Thu, 21 July 2022 10:02 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 6ED3DC14F73D for <idr@ietfa.amsl.com>; Thu, 21 Jul 2022 03:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 UXQslkWL0WZs for <idr@ietfa.amsl.com>; Thu, 21 Jul 2022 03:02:28 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0275BC157B54 for <idr@ietf.org>; Thu, 21 Jul 2022 03:02:27 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.48:48314.261504996
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.128.174.35 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id ED5B328010F; Thu, 21 Jul 2022 18:02:21 +0800 (CST)
X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn
Received: from ([172.18.0.48]) by app0024 with ESMTP id 4cd69d15e81343b7a7752b6f3646bf56 for shares@ndzh.com; Thu, 21 Jul 2022 18:02:22 CST
X-Transaction-ID: 4cd69d15e81343b7a7752b6f3646bf56
X-Real-From: zhuyq8@chinatelecom.cn
X-Receive-IP: 172.18.0.48
X-MEDUSA-Status: 0
Sender: zhuyq8@chinatelecom.cn
Date: Thu, 21 Jul 2022 18:02:19 +0800
From: "zhuyq8@chinatelecom.cn" <zhuyq8@chinatelecom.cn>
To: shares <shares@ndzh.com>, idr <idr@ietf.org>
References: <BYAPR08MB48725C453611F6A21F255295B3809@BYAPR08MB4872.namprd08.prod.outlook.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.22.188[cn]
Mime-Version: 1.0
Message-ID: <2022072118021922429635@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart346082714723_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OqfUuMti19fD4E0b2XIZqfSRwUg>
Subject: Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 21 Jul 2022 10:02:30 -0000

As a one of the biggest service providers in China, we had deployed large scale BGP-LU in our network. BGP CAR is a nature evolution of BGP LU and will provide us the new capability to carry intend across multiple BGP domain. I prefer to adopt BGP CAR.
B.R
  Yongqing Zhu
zhuyq8@chinatelecom.cn
 
From: Susan Hares
Date: 2022-07-07 02:16
To: idr@ietf.org
Subject: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
This begins a 2-week WG Adoption call (7/6/2022 to 7/20/2022) for the following drafts: 
draft-dskc-bess-bgp-car-05.txt 
(https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/) 
draft-kaliraj-idr-bgp-classful-transport-planes-17.txt 
(https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/) 
The associated drafts may be useful in your consideration. 
CAR:
draft-ietf-spring-segment-routing-policy-22
https://datatracker.ietf.org/doc/ draft-ietf-spring-segment-routing-policy/
 
draft-ietf-idr-segment-routing-te-policy-18
https://datatracker.ietf.org/doc/ draft-ietf-idr-segment-routing-te-policy/
 
draft-dskc-bess-bgp-car-problem-statement-05.txt
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/
CT
draft-hegde-spring-mpls-seamless-sr-06.txt
https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/
 
draft-kaliraj-idr-multinexthop-attribute-02.txt 
(https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/) 
 
draft-kaliraj-bess-bgp-sig-private-mpls-labels-04 
(https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/)
 
You may discuss adoption of one or both the main drafts (CAR or Classful-Transport (CT)) in your response, and the associate drafts.   
A few caveats on your discussion:
Please do not worry whether the drafts belong in BESS or IDR.  
Both BESS and IDR work on creating relevant quality standards in BGP, 
and the chairs will work this out. 
 
The IDR has spent time over 2020-2022 discussing these drafts.  
For background information, see the following links below.  
You can refer to these previous presentations or email discussions in your responses.   
 
Please constrain your discussion to whether these drafts should be adopted.  
I’ve started another email thread on whether path establishment/distribution 
for a color (aka QOS/SLA/Transport Class) should be done via a 
specific BGP route (i.e., per-color NLRI) rather than as per-color attributes on a route.  
https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/
 
Questions (to consider) for these drafts: 
Jeff Haas (IDR Co-chair) posted a summary on March 21, 2022 that for 
route resolution and route origination/propagation, BGP-CAR and BGP-CT are functionally identical, 
but operationally different.  
    ( https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/
Do you agree or disagree that these two drafts are functionally identical? 
If you agree, should we have just one draft or do the operational difference encourage us to have two drafts?  
If you disagree, do the functional differences encourage us to have one or two drafts adopted?

v2.23.0 | Report a Bug | By Email