Re: [alto] Comments on the Path-Vector draft during IETF 102

Dawn Chen <dawn_chen_f@hotmail.com> Mon, 20 August 2018 02:05 UTC

Return-Path: <dawn_chen_f@hotmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1529C130DD9 for <alto@ietfa.amsl.com>; Sun, 19 Aug 2018 19:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level:
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 qXdQ3bGdcKKh for <alto@ietfa.amsl.com>; Sun, 19 Aug 2018 19:05:17 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003092.outbound.protection.outlook.com [40.92.3.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8069130DD7 for <alto@ietf.org>; Sun, 19 Aug 2018 19:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QPF7DEPiC7qXJEVKLse5yjqkwAG0tEEqZJoU052tRrQ=; b=Kq/JHBiPb+LVIJWABxRHjTBFuVoKZ8fe7W7m8gebS6mJMmJt69DCWabdJ7zpCCtjgC4L7ADi2cHezVrvcFVTEwtV7Ao/vD+7Qm2W1eD2yK2yZH42sJXAtymQMeCBwgVm/6N+6TN3O2d4IvgrbQCl/oeJOIcOW31/iA9Nelb0uXg1jMp1n0pmG0OG6XIebWKrUXGeO5zu/Mf8Yl9S+fJ6jrgP/V7lXdweoDmPiknJvzx2D0sU3PecYXtHNIopZpCO4dtsQFCXCV0L2B7HIrzzzJNviLXryeDVINRxRbMlDGRoHDqX0DlAyu8juZMr4u4a5H6U2xNtr7JGrP3xI55O9A==
Received: from BL2NAM02FT003.eop-nam02.prod.protection.outlook.com (10.152.76.53) by BL2NAM02HT243.eop-nam02.prod.protection.outlook.com (10.152.76.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1080.9; Mon, 20 Aug 2018 02:05:15 +0000
Received: from BLUPR02MB1202.namprd02.prod.outlook.com (10.152.76.57) by BL2NAM02FT003.mail.protection.outlook.com (10.152.76.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1080.9 via Frontend Transport; Mon, 20 Aug 2018 02:05:15 +0000
Received: from BLUPR02MB1202.namprd02.prod.outlook.com ([fe80::ad34:9f82:7eff:9a35]) by BLUPR02MB1202.namprd02.prod.outlook.com ([fe80::ad34:9f82:7eff:9a35%5]) with mapi id 15.20.1059.023; Mon, 20 Aug 2018 02:05:15 +0000
From: Dawn Chen <dawn_chen_f@hotmail.com>
To: Qiao Xiang <xiangq27@gmail.com>
CC: IETF ALTO <alto@ietf.org>
Thread-Topic: [alto] Comments on the Path-Vector draft during IETF 102
Thread-Index: AQHULpAh86s6plUJ60WV0aUtuZMWGqTH9uDk
Date: Mon, 20 Aug 2018 02:05:15 +0000
Message-ID: <BLUPR02MB1202A7187ED5D29EF85BB08CB5320@BLUPR02MB1202.namprd02.prod.outlook.com>
References: <CAOB1xS8rD9D4kaNNu+9PLin9Q7R69sx036xjvnwj4wV7Nv=o2Q@mail.gmail.com>
In-Reply-To: <CAOB1xS8rD9D4kaNNu+9PLin9Q7R69sx036xjvnwj4wV7Nv=o2Q@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:AB88DB0BDDF06172264D25E6AF6191B6E6FCB9FE8C0FE51AB583437BF78133A1; UpperCasedChecksum:D13986FB497FEF90388C069A4EF0D3E01C7EF5F284E15FD99C3AE2BB6E229166; SizeAsReceived:7130; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [UnBBac1GicMPZJIdbwhvuXBXu1K7UevElcxI8Jf9pXw=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL2NAM02HT243; 6:QwsHXoadD/zIvZAB4UJCuid0mJW9VPJHRwWHu3FUH1qo70t6a7koKYLaxx77Tf9aMh3Hvjjc+vxUbwMy3Jh8Rlzo49zIhQkyIPdL1Fl/Mt+fwb5ldCfbieLS97OkVD7SL/AAt/Ys1HdGi10Jm80sFhUOglezi0gRyeRqnwVIj5FapZY+8pblGWeW/KR7wGjTuCEuxQj0ZsG8A0E4pe9kzGDhvgBZafw2RCmRiPhYHnDhHxKRRJ4USmo5unF4/IJVS0MHVs5snquD8OMFJ0gDBfLsJhnbOofQMhwYGuf3HQ6ehLOFrq5m0pUqqO2PAEMZbi5gIdjCbfGsbn5ZClu+9KS70BYkBATFqYmskdu/eYXXhZ2w7JzXZ4/let21528SU6If5ey9cWZah61P4RzhNWWtiG2BYUjpDfAYsQ1UeYMjsinOw5/r15rWO7MkhGTcI3EnFZTWJJpRWRWrzvoraA==; 5:V79meD0+L2wgUlc5ST7V3brcQ5Kw8iUmUARqkCnU4EFPMOz6LlcAzjJtZ6ETmF6asx7L6A1EtJWd7JeGYU1eN3+6Mw9JQHez14HWbEXPd1ZvHmO1+ESrgbnTRST9vuyIP4KJo4oqql8M/O4MDFJ4FD3Us5GIV/T9WoN4VavmCNY=; 7:+wmlXeXZN5LGlNwf4cYi22PbCl8E3lhOCYsHbHXZWnnUTFObYz2210h1c4atfKzv9Usi+Wt4LHJSr0MNczUN7c0QBxMg/ZE0/QyQ9e4ar3O6YTF87hX3xFO+H27ix8zSHMs4z+bmLiwpCcJuUcFdgwFMgz72znGBeKrRWjQsSqlou/q2q7ra6UHTFN3CuoMjA7i9rB0TUe6oQ8pn2CcK/d27EE7N6zN+yakPz1DbRrXg+fAmrgzrIH/SwNxj1YJn
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BL2NAM02HT243;
x-ms-traffictypediagnostic: BL2NAM02HT243:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BL2NAM02HT243; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT243;
x-forefront-prvs: 0770F75EA9
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(74316002)(102836004)(6506007)(83332001)(7696005)(14454004)(53546011)(76176011)(2900100001)(5250100002)(104016004)(86362001)(105586002)(20460500001)(229853002)(6916009)(39060400002)(9686003)(305945005)(33656002)(5660300001)(6246003)(55016002)(106356001)(4326008)(82202002)(25786009)(6436002)(73972006)(87572001)(486006)(5024004)(1411001)(11346002)(81156014)(56003)(14444005)(476003)(256004)(8676002)(99286004)(6346003)(446003)(8936002)(68736007)(26005)(97736004)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT243; H:BLUPR02MB1202.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dawn_chen_f@hotmail.com;
x-microsoft-antispam-message-info: 0KeI+SqmnonlgefFYYZ0+RMdSVHfifuoJ1BkHKStGcvHA6/ElXicrB6SrY2SpWkAova/hu9VoBV4bwTRmZpIo3Ns3NwK+P5o71CZjEpd7TZVLK2EGqDYQqHF/fI08Jt4vD9/Li4s32YhjNEZ1RZCfAn2vPdbqnen47SOQR8HvfEkF22vop79T+WeUtQkjzCqIQstXoLkhEngV0BjP19AfAofEB4Z1i3hmK/oXMf07+M=
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-Network-Message-Id: 980e2199-4b27-4a7d-3c2f-08d606415ec9
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2018 02:05:15.1370 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT243
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/F8Fm6etNMBRR99bU95NIEhIMtAs>
Subject: Re: [alto] Comments on the Path-Vector draft during IETF 102
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 02:05:19 -0000

Hi Qiao,

For the second issue Handling multipath, I would think it is a general problem not specific to path vector. Actually, base ALTO protocol also has such problem. Current base ALTO protocol only has one cost value between a source-destination pair. Similar to base ALTO protocol, multi-cost, cost calendar also adopt such setting. So, instead of considering multipath in path vector, I suggest that the multipath consideration can be a general consideration that will include base ALTO protocol, multi-cost… if possible.

Thanks,
Dawn

________________________________________
From: alto <alto-bounces@ietf.org>; on behalf of Qiao Xiang <xiangq27@gmail.com>;
Sent: Wednesday, August 8, 2018 4:48 AM
To: IETF ALTO
Subject: [alto] Comments on the Path-Vector draft during IETF 102

Dear authors of the PV draft and the ALTO WG members,

Before and during IETF 102, I raised a couple of issues about the path vector draft: (1) why we use a vector of abstract network element (ANE)? and (2) update the current PV design to support multicast/multicast. It was suggested during IETF 102 that we move this discussion to the mailing list. Hence the following are my opinions in detail:

1. The design choice of using "array/sequence/list of abstract network elements (ANEs)".

We all know that the concept "path vector" in this draft was highly motivated by BGP, a path-vector interdomain routing protocol. In BGP, a path vector encodes an AS path, which provides the semantics that to reach a destination IP prefix, which ASes will be traversed in what "order". The AS-path vector has semantics: (1) the first one in the vector is the neighbor AS providing this route, (2) the last one is the destination AS providing the destination IP prefix, (3) The ASes in between help provide information about inter-AS connectivity. In contrast, a path vector in ALTO is an ANE-path. What semantics does it have? In order words, why does the order of ANEs matter? One may argue that it may help provide information like "a flow will pass through a firewall middlebox before entering a DPI middlebox", but why would a network operator want to provide such detailed private information to the application? Is there a strong, reasonable use case?

In Danny's multi-domain broker draft tries to use the PV extension to provide the AS-path information for different NFs. This may be a strong case to use the array of ANEs, instead of a set of ANEs, in the PV draft. However, such information is already provided by BGP and will be the source of an ALTO server getting such information, why is ALTO better than BGP at providing such information?

I see 3 ways that we can proceed:

(1) we keep the current design, and provide strong use cases in the draft to justify "array of ANEs" is necessary, and explicitly state that the application MUST recognize that the returned array of ANEs MAY be unordered;
(2) we keep the current design, do not provide strong use cases to justify this design, but explicitly state that the server MAY return the array of ANEs unordered;
(3) we change the design from "array of ANEs" to "set of ANEs" (i.e., cost mode changed from "array" to "set"). Given that all specifications in ALTO are specified using JSON format, which does not have a concept called "set", this design choice may seem a bit strange. However, I believe that we should not let the specification language used by the WG affect the semantics of the design.

2. Handling multipath (and potentially multicast).

The current PV design does not handle multipath routing or multicast. Per suggestion from Richard, I took a look at how BGP handles multipath, given that PV was highly motivated by BGP. I found RFC7911 ("Advertisement of Multiple Paths in BGP") provides the solution. And the basic idea is very simple: in BGP announcement, assigning an ID (path identifier) to the route. This motivates me to propose the following design to let the PV extension support multipath.

Consider a source-destination pair (a flow), its route (no matter single-path route or multipath route) is essentially a set of route segments. When the ALTO client submits a PV query about this flow to the ALTO server. Instead of returning an array of ANEs, the ALO server returns a set of arrays of ANEs, where each array represents a route segment in the route of this flow and is assigned a unique ID. These IDs are also sent to the ALTO client. In addition to the property map of all ANEs used in these route segments, the ALTO server also sends another property map of all route segments, where the property is "traffic load percentage".

I intended to talk about this design during the IETF 102 meeting, however, given my unstable internet connection, I had to omit this part. Slide 4-6 in the attached presentation illustrates this design with an example. I believe this design perfectly provides accurate, compact information of resource sharing in multipath routing. It can also handle the resource sharing defined by TE policies, and can potentially provide such information in multicast, provided that the query format supports a query on multicast flow.

What do you think about these two issues? It would be great to hear the opinion from not only the authors, but also other WG members. If they are reasonable to most of you, may I suggest integrating them into the next version of the PV draft? Thank you very much.


Best wishes
Qiao Xiang
--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University