Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST

"Chengli (Cheng Li)" <c.l@huawei.com> Wed, 30 September 2020 07:41 UTC

Return-Path: <c.l@huawei.com>
X-Original-To: srcomp@ietfa.amsl.com
Delivered-To: srcomp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7DE3A12A2 for <srcomp@ietfa.amsl.com>; Wed, 30 Sep 2020 00:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 f2JmL2Xaina5 for <srcomp@ietfa.amsl.com>; Wed, 30 Sep 2020 00:41:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC053A129C for <srcomp@ietf.org>; Wed, 30 Sep 2020 00:41:33 -0700 (PDT)
Received: from lhreml732-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 409B3232E126ED1C5706 for <srcomp@ietf.org>; Wed, 30 Sep 2020 08:41:32 +0100 (IST)
Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 08:41:31 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 08:41:31 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.72]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 15:41:28 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, srcomp <srcomp@ietf.org>
Thread-Topic: comments on REQ-8-26-HET-SID-LIST
Thread-Index: AdaWnjCCazSlmccsSGWRfQjyXFdVqgASrp5mAAThEHA=
Date: Wed, 30 Sep 2020 07:41:27 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB02C18E2C@dggeml529-mbx.china.huawei.com>
References: <DM6PR05MB6348841D7C7DF05589073B65AE320@DM6PR05MB6348.namprd05.prod.outlook.com> <BN6PR11MB4081ED6360A0A078F836A3E4C8330@BN6PR11MB4081.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB4081ED6360A0A078F836A3E4C8330@BN6PR11MB4081.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02C18E2Cdggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/srcomp/eLwO6nmE_fYnyhGHGsrxa3mrBP8>
Subject: Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST
X-BeenThere: srcomp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <srcomp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/srcomp>, <mailto:srcomp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/srcomp/>
List-Post: <mailto:srcomp@ietf.org>
List-Help: <mailto:srcomp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/srcomp>, <mailto:srcomp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 07:41:35 -0000

To me, I think the benefits are clear.

But in the real deployment, we should avoid the combination in order to simplify the deployment.

Therefore, it is a bonus instead of a basic requirement I think. It is good to provide this capability.

Best,
Cheng






From: Srcomp [mailto:srcomp-bounces@ietf.org] On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, September 30, 2020 1:33 PM
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; srcomp <srcomp@ietf.org>
Subject: Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST

Hi Ron

The metric states that a proposal permits the use of compressed and non-compressed segments within a segment list.

"A solution that supports compressed and non-compressed segments, and allows their combination within a segment list meets this requirement."


The benefits to deployment seem clear.  Some nodes support the compression solution while others do not yet, the service is incrementally upgradable.


Darren
________________________________
From: Srcomp <srcomp-bounces@ietf.org<mailto:srcomp-bounces@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
Sent: Tuesday, September 29, 2020 4:39 PM
To: srcomp <srcomp@ietf.org<mailto:srcomp@ietf.org>>
Subject: [Srcomp] comments on REQ-8-26-HET-SID-LIST


Folk,



The rationale for this requirement are dubious.



You are proposing that SR ingress nodes must support the following SR encoding:



  *   Legacy SRv6
  *   Compressed
  *   Hybrids containing Legacy encoding features and compressed encoding features



The rational are:



  *   That this supports one particular transition strategies
  *   That some nodes may not require compression



Other, more frequently deployed transition strategies are available. And what is the motivation for using classing encoding when compression is available?



                                                                       Ron












Juniper Business Use Only