Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

Huaimo Chen <huaimo.chen@futurewei.com> Wed, 01 July 2020 00:53 UTC

Return-Path: <huaimo.chen@futurewei.com>
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 59AE93A0842 for <idr@ietfa.amsl.com>; Tue, 30 Jun 2020 17:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 m56piGvTig3s for <idr@ietfa.amsl.com>; Tue, 30 Jun 2020 17:53:22 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760095.outbound.protection.outlook.com [40.107.76.95]) (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 92B123A083F for <idr@ietf.org>; Tue, 30 Jun 2020 17:53:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DotnWMZ72YYHGKawsEGZjwrYgtuJvl6vBQSIvDgFmJprynq80mXIq0XVkiTw5sAVc0OvFoknPR/R6659Y5QqO6f6gQnCBEVYB3GFPAURIShMeQWf90lj3zuWy1YmwREz+855S0pnmvMYmu70X3xfhMol3zs6UGD3FqFU5alviymuoVYSQj0v06Y21s+ebd0dg4Xx1Eo7p3LnM1i5gGRHHkhqoEWa5vmJmmw1NnSN6HLdUEKms9KBraSFn2tW3Cqby9uf3U8D3okMYSO01HskwfA+agMeHqYElHqPz462SKCqEB9n/u+e+WMRO9/fYUlSbGk1vcz3h2fLKopQxk01+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ukb3wN2MP2tXadWZzCTlTHCidXoHHAbuxL3wFLFnp/g=; b=gOODQp0V6NOS91AaVzbvhj3AzRCzTVTzl79Sqijky1pKzv0xyDYTPmJX6cGWwK4dTg6zRoXcTvrwj7caxlrgCn++QzhF4ZIYa2B7evUnTf1aNvoJ9u6bIQczlXeJ/8MSad13dW/3p9RNeD82jzNIcEjav32yP68SvVg0NdSXNl37xhICGCP//q6qiQf0i7yqdt6USwxSOH2GntTaeamWWlfXxRIw55ov3UMZnk1VK3uqngoP57qhVN6vJnJoj/WdnpKhx8aI9zSXLY8e7EicSVXfglPQtXgkKnBYdLIqhlplHaiGkh3LGC3KpL6oKpnmFo+S2ekGKT5GfdIf9Po7eA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ukb3wN2MP2tXadWZzCTlTHCidXoHHAbuxL3wFLFnp/g=; b=izYtuKe3ZqfQfk9QKN9fN2zmPFniI5ors/D834Pz7jTIf0llwAj9vGL7INUwsHqs+xUsXHGvWdTGJt+T11/bZ933bMzYr5LjQXmdArxApEssjB9tko2tsg5l6+rMIVV/oOFiVnh7v7dK5mGNt5nihwm949L+poyJd5WDmvb0qHc=
Received: from BY5PR13MB3110.namprd13.prod.outlook.com (2603:10b6:a03:187::21) by BY5PR13MB3285.namprd13.prod.outlook.com (2603:10b6:a03:190::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.10; Wed, 1 Jul 2020 00:53:20 +0000
Received: from BY5PR13MB3110.namprd13.prod.outlook.com ([fe80::9d8d:bb6d:5de4:6729]) by BY5PR13MB3110.namprd13.prod.outlook.com ([fe80::9d8d:bb6d:5de4:6729%5]) with mapi id 15.20.3153.019; Wed, 1 Jul 2020 00:53:20 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt
Thread-Index: AQHWPrB2BxhuXRWuVkemgdTmvsgUxajVTDSAgBAMbYCAAA+yd4AK9irngAAr3wCAAAGdS4ABdcxR
Date: Wed, 01 Jul 2020 00:53:19 +0000
Message-ID: <BY5PR13MB3110FE2D86251F504C0067C2F26C0@BY5PR13MB3110.namprd13.prod.outlook.com>
References: <159174295808.20598.10881535719552756514@ietfa.amsl.com> <CABNhwV0BzBWXmcn+ge9AXBZ69bg_3ht74YoFW8rRLi5A5pjdsw@mail.gmail.com>, <CABNhwV2FDXpR3dOZwnJTp_P_iC+Hi8W2NtRXjLcNJJo6M4bXxg@mail.gmail.com>, <MN2PR13MB3117DD76779455FEEC34968CF2940@MN2PR13MB3117.namprd13.prod.outlook.com> <MN2PR13MB31177858AB89433F8086D46AF26E0@MN2PR13MB3117.namprd13.prod.outlook.com>, <4d4f462181b247f8ae657767a5a8f25a@huawei.com>, <MN2PR13MB31178D45D9B276C509891DB5F26F0@MN2PR13MB3117.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB31178D45D9B276C509891DB5F26F0@MN2PR13MB3117.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2601:199:4300:8e5a:8ca:3ad3:9eeb:5666]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 08e6cbb5-81f4-4e48-913b-08d81d59261c
x-ms-traffictypediagnostic: BY5PR13MB3285:
x-microsoft-antispam-prvs: <BY5PR13MB3285E485A8DB2289C09C13BFF26C0@BY5PR13MB3285.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04519BA941
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jdtXMQcwkgGOnDHbjIPtd1Nal3+mT7KzfGHUwmAdny6RXB+gGtvHoo/3Iq3Kf/ve21N/GBlFNQUquwqM2NnMvco6GbNOKSHyy63tHE86RD1AR9kuTlFFEpIevZKtAseqhby9JyKcJ60dzdg56u3rEpvIl0vM68mi0oZI7TGmNcznF/qo0T38uqtBxRuKCur8RyQeEMX2ztBSLXxQNMqQQBZvzZt9Z4IIFwZga/OEOVxmaWNRAY7cavd3C1RSeS46opbLF6VePhBw0yLF8loTrU0/Y/F7jKSzYWWNgqQc+YgGYdXLAbirWfvpVR9fwhJw396yAxHFNVx9kxO+GUXDIIw/rSpQXdGOO/knAjQ3Y/XSG2d4KkIlxPzdnp2CxkfZ0qFuelRNDwZGCfSg4d31SA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3110.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39850400004)(136003)(396003)(376002)(346002)(8676002)(19627405001)(166002)(4326008)(52536014)(6916009)(478600001)(316002)(83380400001)(5660300002)(7696005)(8936002)(64756008)(66476007)(66556008)(66946007)(55016002)(66446008)(6506007)(9686003)(53546011)(33656002)(186003)(86362001)(71200400001)(2906002)(76116006)(66574015)(44832011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: yi+WpQ0GJQTJUt+xEkfkerjTsHwR780y34PcFXH+nHZyYSinr8+ogpah6jLzjn4LDyjbUwP1DrwJsMQgX2LF/4gQ990K2/ATMUNhuYWWSj0BkuFWpVG2IugCf6zKdsqUZA5PHu5DLbRmuzNll1UUwXMp9AVsZ+aZM0sjwmRXdiwb5azifVgNtS/Y1xCUknZIQsZ78h9o7XIQYHqtOT+/r20nZ73rx9f/TJMefZUPwCmpjqkONsPdKL8pkL6AIKdValQ/GW638EVFXog/p7BHeoh9knjhKMikTvuCF/MGiq8M/NSnsl6mpH8g4NfvPcPMc0Xj1kebmoDX7wA0MG0qhNtdlWlUABkdqsgjPdLT2bjXy7E/XxuzCYJ2ZCRI1fEhNHbQmmF2m2evS9t7wZGYZO6aIFbn59BUpw8tZ2V2M3XRtq+mZ65whJKy2UfGts2H9nRRzGb2ngxvDOLLEaccFjHjmAjeeNGvWvsf092HZW4wu13ZjHbC2whP35FrBWITbKs9GOGuApVMCM89dINg/p0AuijbEekf3xMbWMWN/BDFPG1xdlVDZxZza0Ztfb4E
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3110FE2D86251F504C0067C2F26C0BY5PR13MB3110namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3110.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 08e6cbb5-81f4-4e48-913b-08d81d59261c
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 00:53:19.9707 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QcMM21OQfrvqC+Paw2wuKhNsjIlUhk6d/8CzBLy67Ogmrdch8oLMvHJTq5sT8DLRlTb3fKdV14Nhc0y80qNA9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3285
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bhLO94nd1wlzQ6c3V9th_shWEnE>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt
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: Wed, 01 Jul 2020 00:53:24 -0000

Hi Gyan,

    Thank you very much for your comments.

    Our answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo on behalf of authors
________________________________

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Monday, June 22, 2020 7:15 PM
To: idr@ietf.org<mailto:idr@ietf.org> <idr@ietf.org<mailto:idr@ietf.org>>
Cc: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt





Authors



Few comments



In the abstract and introduction it mentions adjusting traffic.  When reading the abstract and introduction adjusting traffic the first thing I think of when saying adjusting is BGP QOS QPPB policy to rate limit BGP traffic.



[HC]: It seems that the way (or say RPD) in which the traffic is adjusted in the draft and BGP QOS QPPB are different. The BGP QOS QPPB is based on configurations or commands. Different configurations for different parts of the network need to be done. These configurations combined with the BGP propagation provides some QoS policy on some traffic. The RPD provides a way to adjust the traffic (i.e., adjust the route attributes to redirect the traffic to the less used links) automatically without those configurations on different parts of the network.




In general routing policy is pretty straight forward with active / backup routing policy.



However when optimal active/ active all active routing optimization is required where geographic region based routing is desired and if routing control optimization is desired between both peering AS’s , the policy can become very complex and unmanageable.  If routing control policy is on one side only, the other side AS back hauls based on peering policy the policy is complex but manageable.  However optimized routing so both sides of peering does not back haul can be very complex.



There are many peering scenario and this one above  is a dual transit as all active peering policy scenario.



The above relates to AFI /SAFI 1/1 2/1 and can be accomplished with standard communities.



[HC]: The above can be achieved using standard communities, but can be very complex as you said. Using the RPD in stead of the standard communities can reduce the complexity greatly and can adjust the route attributes without configurations for some parts of the network to redirect the service traffic from the heavy-loaded links to the links with light traffic. Thus the network resource is effectively used and the QoE is improved. For example, in one metro area network without using the RPD, planning and implementing a redirection of a service traffic (coming to and exiting from a router) takes days. After the RPD is deployed in the network with a controller NCE, this takes just minutes instead of days.




I would say auto adjustment of active routing paths routing where routing control is required on both sides of peering to enable optimized paths



[HC]: The RPD can be used for automatically adjusting active routing paths on the both sides of a peer if it is required and permitted. In the case where the two sides of a peer are two different ISPs (say ISPa and ISPb) and each side (ISP) does not allow the other to control its network, when ISPa adjusts routing paths, it can not control the network owned by ISPb directly.




Kind Regards



Gyan



[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C07a9442b208a4e85cc3108d81c9b0415%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637290799405571469&sdata=wTNqdsqeXJVkHqK%2FZ0iIDAstepTYRxWtDoxX%2FSOg9HY%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD