From nobody Tue Apr 2 13:31:16 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A73120499 for ; Thu, 28 Mar 2019 07:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 FS5RAh305-22 for ; Thu, 28 Mar 2019 07:23:31 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 9D48912048B for ; Thu, 28 Mar 2019 07:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1553783010; x=1585319010; h=from:to:cc:subject:date:message-id:mime-version; bh=U04SYmX+KU4tUYrokNJxkZgG6qEJBCZ+GxWP0U9+oso=; b=mToDHONpTsyZh4x9XY9niCuMsBbYxVn56U7IBdHti5LW+lfm51dh9ljL BIaCz3y1PPiOIV52chREmTd4yL34q8dE0KIKqC4qUuaoz217Yxg6pGSTP m4yalkc3HbMvjaKb5QN2p3lvcbuNS69pGGHt1EZ1IiR9JSHZMDil9gfwM PQU0pq8QmYip7+F8HmxMhE5dap5S5CjhZL7cve5WLH4mBuZf9bTwhueo3 pxNcIfkXxDRDvRKIYuFtqtIP7HoKyvC9E8HhB6zZ93g4c8VHBbuDktQmW vmnRtxWye6sAsEz260hMvcml5pE2c1gl6+ZOvIRr5hiqLPOPIz6kmZaDQ w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2019 15:23:27 +0100 X-IronPort-AV: E=Sophos;i="5.60,280,1549926000"; d="scan'208,217";a="391897082" Received: from he105871.emea1.cds.t-internal.com ([10.169.118.68]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 28 Mar 2019 15:23:26 +0100 Received: from HE101946.EMEA1.cds.t-internal.com (10.169.118.82) by HE105871.emea1.cds.t-internal.com (10.169.118.68) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 15:23:25 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101946.EMEA1.cds.t-internal.com (10.169.118.82) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 28 Mar 2019 15:23:25 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 15:23:25 +0100 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0458.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Thu, 28 Mar 2019 14:23:25 +0000 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189%4]) with mapi id 15.20.1730.019; Thu, 28 Mar 2019 14:23:25 +0000 From: To: CC: , , , Thread-Topic: draft-rass-panrg-mpath-usecase Thread-Index: AdTlbormHOVqAJilSy+eOsBwQ+x38A== Date: Thu, 28 Mar 2019 14:23:25 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.19.3.219] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae4b2650-a8c9-4a52-c114-08d6b388f075 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0458; x-ms-traffictypediagnostic: LEJPR01MB0458: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(136003)(199004)(189003)(33656002)(8676002)(86362001)(54906003)(19627235002)(478600001)(5640700003)(2906002)(106356001)(2351001)(790700001)(2501003)(68736007)(81166006)(75402003)(186003)(81156014)(6116002)(14454004)(105586002)(71190400001)(14444005)(71200400001)(3846002)(26005)(72206003)(256004)(6916009)(66066001)(53936002)(54896002)(7696005)(6306002)(52396003)(74482002)(476003)(4326008)(102836004)(316002)(55016002)(7736002)(8936002)(97736004)(9686003)(486006)(5660300002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0458; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hE5wOYjOyt+7ohFq7F4myGQpE4FNhmi6Oe2oEDJ5lP8iLGN2QippZhnVTUkKYpuFxTMUHqGO1MXuhemnGwCLsa5G1f2D2BG/m3jRnQzT6n/tNKD9NDi/JsRIMme6dLyswYJQ9lQZ5EHMA6TLNcGfCSwfoCwZPNK0pgfz7Prq3wW+DNBBuHMCYUk7AbbDw9wqDkRGXc5NeaUJNZL73BGA5TwqACFGT2FNbR7KlAo2zJ77xjmbJ4vjt2SoXbYjLVJ0tHZ18BNWQLVLQBxWsfBJry4nW5hcbc6Vm72y4Xa5xJprWCv6JYYLS3Tlf+JXsB6vIEf3W7jBqSRDCB+hXoz5Qjp8diLnpjcGolYbz3eAycG2gvI/3+oeU9KJ36w1fjNXX0ZYJnTfZz0ZSAGsZyzk38U5kdiQIwm+GuRrjCn0an8= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0460CD485E061E2AF4DF34C29C590LEJPR01MB0460DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ae4b2650-a8c9-4a52-c114-08d6b388f075 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 14:23:25.0196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0458 X-OriginatorOrg: telekom.de Archived-At: X-Mailman-Approved-At: Tue, 02 Apr 2019 13:31:14 -0700 Subject: [PANRG] draft-rass-panrg-mpath-usecase X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 14:23:34 -0000 --_000_LEJPR01MB0460CD485E061E2AF4DF34C29C590LEJPR01MB0460DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefan, the idea to route packets containing encrypted information via different pa= ths sound reasonable to me. This may be challenging for higher layers, but = well, one may be able to design them to cope with packets received from dif= ferent paths, I think. I've recommended to investigate available options rather that path detectio= n this morning. Some of these are: * An end system can be multihomed * There's multi-path transport, like MPTCP * If the IP-addresses can be varied, the packets will likely follow dif= ferent Equal Cost Multi-Path's (ECMP, search the Internet). Varying source = address will do. Multipath could mean: * Same fiber, different router interfaces/headers (imagine the LTE path= and fixed access sharing the same fiber at some part of a layer 0 path) . * Different parallel ports of a router, but same router to router hop * Different router hops (combined with different ports). What likely is difficult is to vary the AS path. That might work, if you ar= e multihomed with different networks. For a single domain, you may have to = use a proxy or a tunnel to reach a different section of that domain (but I = assume that there are multiple peerings to reach the destination AS - that = might not be the case). I'm not an onion routing expert. That may help too. You could try different paths with the methods described above and measure = delays to figure out different router paths (different ports between the sa= me routers a hard to detect). No matter what you do, and even with path awa= re networking, you'll not be able to figure out or avoid using the same fib= er by different networks. Please note, I'm not on the panrg list and readers there may receive this m= essage delayed. While I like your idea, my time doesn't suffice for an ongo= ing support. Regards, Ruediger --_000_LEJPR01MB0460CD485E061E2AF4DF34C29C590LEJPR01MB0460DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stefan,

 

the idea to route packets conta= ining encrypted information via different paths sound reasonable to me. Thi= s may be challenging for higher layers, but well, one may be able to design= them to cope with packets received from different paths, I think.

 

I’ve recommended to inves= tigate available options rather that path detection this morning. Some of t= hese are:

  • An end system can be multihomed
  • There’s multi-path transport, like M= PTCP
  • If the IP-addresses c= an be varied, the packets will likely follow different Equal Cost Multi-Pat= h’s (ECMP, search the Internet). Varying source address will do.=

 

Multipath could mean:

  • Same fiber, different router interfaces/headers = (imagine the LTE path and fixed access sharing the same fiber at some part = of a layer 0 path) .
  • Diffe= rent parallel ports of a router, but same router to router hop
  • Different router hops (combined with d= ifferent ports).

 

What likely is difficult is to = vary the AS path. That might work, if you are multihomed with different net= works. For a single domain, you may have to use a proxy or a tunnel to reac= h a different section of that domain (but I assume that there are multiple peerings to reach the destination AS= – that might not be the case).

 

I’m not an onion routing = expert. That may help too.

 

You could try different paths w= ith the methods described above and measure delays to figure out different = router paths (different ports between the same routers a hard to detect). N= o matter what you do, and even with path aware networking, you’ll not be able to figure out or avoid usi= ng the same fiber by different networks.

 

Please note, I’m not on t= he panrg list and readers there may receive this message delayed. While I l= ike your idea, my time doesn’t suffice for an ongoing support.

 

Regards,

 

Ruediger

--_000_LEJPR01MB0460CD485E061E2AF4DF34C29C590LEJPR01MB0460DEUP_-- From nobody Tue Apr 2 13:31:23 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BE120049 for ; Sun, 31 Mar 2019 20:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 2YhoZ-YTNgEZ for ; Sun, 31 Mar 2019 20:31:25 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DADF120005 for ; Sun, 31 Mar 2019 20:31:25 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id v32so8922719qtc.10 for ; Sun, 31 Mar 2019 20:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tpcQS4mQzPZf3FFz0qzQT2DDNddHnT1/FEQ1HHN9N+A=; b=WHD5LT6JEA4e7iWaHWK7ux8YR+bw5hHFP7yRzsekcBUgmFjGpq0F5iy+6uTigWMX9y 4YTYDXxrQ4ciGSvrMPilvmveFNtNmgU0IEeqlNeLG2oGu3/l0hLg6mPoHIAul7lqsBSx NOEOkzNfwUtO25yllHFKB5Sk49XvlOAtkG5j6RxYqYqAk3whFhbunT5mzOh+cpd4xyqp DI6HY+rZdX0yH/YEjGDT/EudQCU5OZqzl9nCQrnzMJYZTVrlKbaRzvHEVtHb6faKLEUl MmjJJXmBYPQSUSZulDQf6kqnRqw323STtrDZWgSOJskfpeISNB0ygjCnS0rdlKRrs24n Hkdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tpcQS4mQzPZf3FFz0qzQT2DDNddHnT1/FEQ1HHN9N+A=; b=bG9hv4Aj2yLLW6kfKC3rwMrp9IO/f0Rn2X6ku5cxAHwsUipLEP8S2guTieoTJwxgwg zedpxmi4s+GlaeJR8uOGxPcLg16mCv41nSy+Cu1oL99+ayUOQ0fT9thr9+dvauKcDjRz T4pt8jnBeSyR6tSdaEwtl1buMPxlAetj17+OpZnjQwKPOouDRzNn92EJOvQrWUQxotpW ZZbqaRlD54kA3GgnBbIniRGjogff2hqRYcKihPSlf7RZwiHunCjJ6ynfqcVMBCl3pYL3 hej5AwlUKzHpvxPZWv1YFyb0AvoHd/KwdZ8K+jvy36ovWFhrxxUj5LVuY6tJ7C8sqcO7 N0Dg== X-Gm-Message-State: APjAAAVkrFnVWljyqywhUzX//qmrhf+VrWmF45nlwKxgcIC5XC1XI9M2 YHi62ArdnQCTFGd5enKpwIMtJS9w33sD9gIt5kQAqNNyEQQ= X-Google-Smtp-Source: APXvYqxnDBjzI9zirEC0Im/u3f0l7RIX9xruLorgTZCi/IIdpk94uqI2LiQj7gVNG19owkn+zA2RzdtZA7enTtmRtqs= X-Received: by 2002:a0c:86f5:: with SMTP id 50mr48728749qvg.70.1554089483963; Sun, 31 Mar 2019 20:31:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 1 Apr 2019 05:31:13 +0200 Message-ID: To: panrg@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 02 Apr 2019 13:31:13 -0700 Subject: [PANRG] Flow labels in draft-irtf-panrg-what-not-to-do-02 X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 03:31:26 -0000 Hello, >From the draft wrt IPv6 flow label: "Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field." At this point, the majority of IPv6 packets in the Internet should have properly set non-zero flow labels. Non-zero flow label is set by default for Linux since 2014. iOS was setting it before that, and I believe Windows started setting flow labels not long after Linux. This is one of the few things we were able to turn on in the Internet without causing any major problems and it has zero negative performance impact. The impetus is on network devices to start using the information. e.g. a tcpdump unconnected UDP from my Linux host: 20:12:06.099837 IP6 (flowlabel 0x1b95a, hlim 64, next-header Options (0) payload length: 56) 3333::1 > 1113:1:0:0:8000::: HBH (opt_type 0xde: len=20) 58669 > 7777: [udp sum ok] UDP, length 24 Tom From nobody Tue Apr 2 13:31:30 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55AA12000E for ; Mon, 1 Apr 2019 14:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RRvS9Lcc9bVM for ; Mon, 1 Apr 2019 14:45:36 -0700 (PDT) Received: from huawei.com (dfwrgout.huawei.com [206.16.17.72]) (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 685E81204D5 for ; Mon, 1 Apr 2019 14:45:33 -0700 (PDT) Received: from DFWEML703-CAH.china.huawei.com (unknown [172.18.9.221]) by Forcepoint Email with ESMTP id 648499F4559E4; Mon, 1 Apr 2019 16:45:30 -0500 (CDT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by DFWEML703-CAH.china.huawei.com (10.193.5.177) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 1 Apr 2019 14:45:31 -0700 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.136]) by SJCEML701-CHM.china.huawei.com ([169.254.3.61]) with mapi id 14.03.0439.000; Mon, 1 Apr 2019 14:45:18 -0700 From: Yingzhen Qu To: "Ruediger.Geib@telekom.de" , "stefan.rass@aau.at" CC: Lin Han , "panrg@irtf.org" , "ietf@trammell.ch" Thread-Topic: draft-rass-panrg-mpath-usecase Thread-Index: AdTlbormHOVqAJilSy+eOsBwQ+x38ADYTJeA Date: Mon, 1 Apr 2019 21:45:18 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B011E1816@sjceml521-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.216.117] Content-Type: multipart/alternative; boundary="_000_594D005A3CB0724DB547CF3E9A9E810B011E1816sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 02 Apr 2019 13:31:14 -0700 Subject: Re: [PANRG] draft-rass-panrg-mpath-usecase X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 21:45:40 -0000 --_000_594D005A3CB0724DB547CF3E9A9E810B011E1816sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks for your interests in our draft and comments at the mic during Stefa= n's presentation. I didn't get a chance to answer your question during the presentation becau= se of the shortness of time. If I understand right, you were suggesting to = add different source and destination address to achieve multiple path, it i= s useful in some circumstances but I see some limitations. Let's take a sin= gle domain/AS as an example: * Adding more source and destination address, if IGP is used to calc= ulate routing, then you still end up on the same route because of SPF. * This will require change on hosts because you can't use one TCP or= MPTCP session. Acrossing domains is more complicated, but the 2nd point still applies. Thanks, Yingzhen From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Sent: Thursday, March 28, 2019 7:23 AM To: stefan.rass@aau.at Cc: Yingzhen Qu ; Lin Han ; pan= rg@irtf.org; ietf@trammell.ch Subject: draft-rass-panrg-mpath-usecase Hi Stefan, the idea to route packets containing encrypted information via different pa= ths sound reasonable to me. This may be challenging for higher layers, but = well, one may be able to design them to cope with packets received from dif= ferent paths, I think. I've recommended to investigate available options rather that path detectio= n this morning. Some of these are: - An end system can be multihomed - There's multi-path transport, like MPTCP - If the IP-addresses can be varied, the packets will likely follow = different Equal Cost Multi-Path's (ECMP, search the Internet). Varying sour= ce address will do. Multipath could mean: - Same fiber, different router interfaces/headers (imagine the LTE p= ath and fixed access sharing the same fiber at some part of a layer 0 path)= . - Different parallel ports of a router, but same router to router ho= p - Different router hops (combined with different ports). What likely is difficult is to vary the AS path. That might work, if you ar= e multihomed with different networks. For a single domain, you may have to = use a proxy or a tunnel to reach a different section of that domain (but I = assume that there are multiple peerings to reach the destination AS - that = might not be the case). I'm not an onion routing expert. That may help too. You could try different paths with the methods described above and measure = delays to figure out different router paths (different ports between the sa= me routers a hard to detect). No matter what you do, and even with path awa= re networking, you'll not be able to figure out or avoid using the same fib= er by different networks. Please note, I'm not on the panrg list and readers there may receive this m= essage delayed. While I like your idea, my time doesn't suffice for an ongo= ing support. Regards, Ruediger --_000_594D005A3CB0724DB547CF3E9A9E810B011E1816sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi  Ruediger,

 

Thanks for your interests in our draft and comments at the mic during = Stefan’s presentation.

 

I didn’t get a chance to answer your question during the present= ation because of the shortness of time. If I un= derstand right, you were suggesting to add different source and destination address to achieve multiple path, it is useful in s= ome circumstances but I see some limitations. Let’s take a single dom= ain/AS as an example:

·    &= nbsp;   Adding more source and destination address, if IGP is used to = calculate routing, then you still end up on the same route because of SPF.

·    &= nbsp;   This will require change on hosts because you can’t use = one TCP or MPTCP session.

 

Acrossing domains is more complicated, but the 2nd point st= ill applies.

 

Thanks,

Yingzhen

 

From:<= /span> Ruediger.Geib@telekom= .de [mailto:Ruediger.Geib@telekom.de]
Sent: Thursday, March 28, 2019 7:23 AM
To: stefan.rass@aau.at
Cc: Yingzhen Qu <yingzhen.qu@huawei.com>; Lin Han <Lin.Han@= huawei.com>; panrg@irtf.org; ietf@trammell.ch
Subject: draft-rass-panrg-mpath-usecase

 

Hi Stefan,

 

the idea to route packets containing encrypted infor= mation via different paths sound reasonable to me. This may be challenging = for higher layers, but well, one may be able to design them to cope with pa= ckets received from different paths, I think.

 

I’ve recommended to investigate available opti= ons rather that path detection this morning. Some of these are:<= /p>

-       = ; An end system can be multihomed

-       = ; There’s multi-path transport, like MPTCP=

-       = ; If the IP-addresses can be varied, the packets will= likely follow different Equal Cost Multi-Path’s (ECMP, search the In= ternet). Varying source address will do.

 

Multipath could mean:

-       = ; Same fiber, different router interfaces/headers (im= agine the LTE path and fixed access sharing the same fiber at some part of = a layer 0 path) .

-       = ; Different parallel ports of a router, but same rout= er to router hop

-       = ; Different router hops (combined with different port= s).

 

What likely is difficult is to vary the AS path. Tha= t might work, if you are multihomed with different networks. For a single d= omain, you may have to use a proxy or a tunnel to reach a different section= of that domain (but I assume that there are multiple peerings to reach the destination AS – that might= not be the case).

 

I’m not an onion routing expert. That may help= too.

 

You could try different paths with the methods descr= ibed above and measure delays to figure out different router paths (differe= nt ports between the same routers a hard to detect). No matter what you do,= and even with path aware networking, you’ll not be able to figure out or avoid using the same fiber by di= fferent networks.

 

Please note, I’m not on the panrg list and rea= ders there may receive this message delayed. While I like your idea, my tim= e doesn’t suffice for an ongoing support.

 

Regards,

 

Ruediger

--_000_594D005A3CB0724DB547CF3E9A9E810B011E1816sjceml521mbxchi_-- From nobody Wed Apr 3 03:19:57 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5E12008B for ; Wed, 3 Apr 2019 03:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 ioH2w-PhJUBZ for ; Wed, 3 Apr 2019 03:19:52 -0700 (PDT) Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (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 75C3A1200B2 for ; Wed, 3 Apr 2019 03:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1554286791; x=1585822791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rAYSNmC4hfGibaS3f9SzPjaXZ0dCTtXxKrPeiPlb3L4=; b=A3eaHkp1AKZ++FVgP8zr2bIX1S8mZy6QvL3xvjiLs6MfxTv2OLNdC+D8 OwTtTr8lMwa9E5Zq17C1obNVTYSqq+t/HymZT7GdAHzLrrYDwM6f94pl5 9tOKuBBZhn7St/oStzRz1FG/lP8jL7NSht19x3nXrLkiD0WKFhhStfwLp yhLmCIHk762SjROntmjLhspEiqiZofqdrLn8iF4gLkpLvEfKkMt/hIHCz 0SdnmnSYsLWNqZUYdarQQZh8MY+pHUmvcmh3tYAWQinirFqf4PRTe/jJ/ +t+ym4YSk6hFVB66DOFNtrmrVth6TvEIrkCxNd0KH5flQq+70lp3yc439 A==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 12:19:47 +0200 X-IronPort-AV: E=Sophos;i="5.60,304,1549926000"; d="scan'208,217";a="506253761" Received: from he105850.emea1.cds.t-internal.com ([10.169.118.24]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 03 Apr 2019 12:19:47 +0200 Received: from HE105872.EMEA1.cds.t-internal.com (10.169.118.69) by HE105850.emea1.cds.t-internal.com (10.169.118.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 12:19:47 +0200 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105872.EMEA1.cds.t-internal.com (10.169.118.69) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Apr 2019 12:19:47 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 12:19:45 +0200 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0458.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.19; Wed, 3 Apr 2019 10:19:46 +0000 Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::24cc:c867:203f:204d]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::24cc:c867:203f:204d%3]) with mapi id 15.20.1750.023; Wed, 3 Apr 2019 10:19:46 +0000 From: To: CC: , , , Thread-Topic: draft-rass-panrg-mpath-usecase Thread-Index: AdTlbormHOVqAJilSy+eOsBwQ+x38ADYTJeAAEwWZAA= Date: Wed, 3 Apr 2019 10:19:46 +0000 Message-ID: References: <594D005A3CB0724DB547CF3E9A9E810B011E1816@sjceml521-mbx.china.huawei.com> In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B011E1816@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.197] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a5ad84e-f081-42ce-4d73-08d6b81de5c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LEJPR01MB0458; x-ms-traffictypediagnostic: LEJPR01MB0458: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(136003)(39860400002)(189003)(52314003)(199004)(6306002)(81156014)(72206003)(478600001)(966005)(105586002)(19627235002)(14444005)(14454004)(53936002)(486006)(11346002)(75402003)(106356001)(81166006)(186003)(74482002)(3846002)(446003)(316002)(8936002)(6116002)(26005)(102836004)(71200400001)(5660300002)(86362001)(54906003)(97736004)(71190400001)(76176011)(790700001)(476003)(53546011)(9686003)(6916009)(236005)(55016002)(54896002)(7696005)(2906002)(7736002)(33656002)(68736007)(52396003)(66066001)(66574012)(4326008)(8676002)(256004)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0458; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 02yjua7Yw43ZlIohinmHlIg3x+qPwbR9B/iUJm3ZNwvmeBJnC+RxAYS2vwj1+l7CfLtZZNhwFZlInDNFY1OTzN+spG6wIEgj/CMkIwfPL7lv/DyCSmARey53nA+jmOQQsw5XED1w7Ym2Xn/XrXQ+LBvZo/SWr5XZaaaejlGScOEK6xIr90IAuPj5whGks4+jwHnM4FCFbei6L+29qXuNr8THPwI0AssaIF4GDLM9hzEiKfhBgsbvM1PreY+w5kvuEJj/2u9jVG+uwsaWD0uK+FwWKmx821FRGYgynIzyCXZJ1OLgXZUDGy1VZvCMjGznYcWvgXVRkj0ttJE17SKjL3eizidvrUMwgeuf6ByYqVXGD4a5vkeyAzfPdXp7J4WcgcW8EuLkJQHos50Obe8b71b20i4g5a67OL2ACutajDQ= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0460557D8F3CCEE86A9C46449C570LEJPR01MB0460DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a5ad84e-f081-42ce-4d73-08d6b81de5c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 10:19:46.7349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0458 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [PANRG] draft-rass-panrg-mpath-usecase X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 10:19:56 -0000 --_000_LEJPR01MB0460557D8F3CCEE86A9C46449C570LEJPR01MB0460DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yingzhen, my take from the presentation was, that forwarding along different paths is= a or the major design goal. If more than a single packet is forwarded that= way by a single transport relation, adoption of a transport protocol may b= e an issue. You write: * Adding more source and destination address, if IGP is used to calcula= te routing, then you still end up on the same route because of SPF. RG: the PANRG investigates the usage of different paths, not different rout= es, if I got that correctly. A layer 2 tunnel and a non-VPN layer 3 packet = sent on different accesses may be forwarded along the same SPF routed path,= if the CE routers are identical at both ends. As a general statement, I th= ink it would help PANRG to specify what a path is. I doubt that any network= provider will support a universal path infrastructure ping presenting ever= ything from layer 0 - layer 3. A fairly good method to determine whether different paths exist to me seems= to be measuring RTTs of packets exchanged between end-points connected to = one or more provider networks after address variation has been performed. T= he accesses shouldn't belong to the same access network section. On a singl= e access network section, there may be little or no path variation. * This will require change on hosts because you can't use one TCP or MP= TCP session. MPTCP is designed to use different paths by different addresses (and https:= //www.rfc-editor.org/rfc/rfc6182.txt mentions, that SCTP also supports mult= ipath & multihoming). So MPTCP is based on the principle of different paths= using different address-pairs already. Of course, if additional address- or IPv6 flow label variation is introduce= d, more paths might be used. This could result in packet re-ordering at the= destination. The transport and higher layers will have to cope with that. = Varying source addresses will require transport adaptation anyway, if TCP i= s used. The ACKs need to get back to the sender. Impacting forwarding path selection by different source and destination add= resses is a fair approach within a single domain, I think. In the case of I= Pv6, the flow-label is an input used for ECMP, see https://www.rfc-editor.o= rg/rfc/rfc6437.txt . Then the IP addresses may even be maintained and diffe= rent paths may be addressed by varying the IPv6 flow-label. Source address variation may fail, if uRPF is active, see https://tools.iet= f.org/html/rfc3704 , and the source address isn't assigned to the access se= nding the packet. uPRF may be configured at consumer accesses. Regards, Ruediger Von: Yingzhen Qu Gesendet: Montag, 1. April 2019 23:45 An: Geib, R=FCdiger ; stefan.rass@aau.at Cc: Lin Han ; panrg@irtf.org; ietf@trammell.ch Betreff: RE: draft-rass-panrg-mpath-usecase Hi Ruediger, Thanks for your interests in our draft and comments at the mic during Stefa= n's presentation. I didn't get a chance to answer your question during the presentation becau= se of the shortness of time. If I understand right, you were suggesting to = add different source and destination address to achieve multiple path, it i= s useful in some circumstances but I see some limitations. Let's take a sin= gle domain/AS as an example: * Adding more source and destination address, if IGP is used to calcula= te routing, then you still end up on the same route because of SPF. * This will require change on hosts because you can't use one TCP or MP= TCP session. Acrossing domains is more complicated, but the 2nd point still applies. Thanks, Yingzhen From: Ruediger.Geib@telekom.de [mailto:Rue= diger.Geib@telekom.de] Sent: Thursday, March 28, 2019 7:23 AM To: stefan.rass@aau.at Cc: Yingzhen Qu >; Li= n Han >; panrg@irtf.org; ietf@trammell.ch Subject: draft-rass-panrg-mpath-usecase Hi Stefan, the idea to route packets containing encrypted information via different pa= ths sound reasonable to me. This may be challenging for higher layers, but = well, one may be able to design them to cope with packets received from dif= ferent paths, I think. I've recommended to investigate available options rather that path detectio= n this morning. Some of these are: * An end system can be multihomed * There's multi-path transport, like MPTCP * If the IP-addresses can be varied, the packets will likely follow dif= ferent Equal Cost Multi-Path's (ECMP, search the Internet). Varying source = address will do. Multipath could mean: * Same fiber, different router interfaces/headers (imagine the LTE path= and fixed access sharing the same fiber at some part of a layer 0 path) . * Different parallel ports of a router, but same router to router hop * Different router hops (combined with different ports). What likely is difficult is to vary the AS path. That might work, if you ar= e multihomed with different networks. For a single domain, you may have to = use a proxy or a tunnel to reach a different section of that domain (but I = assume that there are multiple peerings to reach the destination AS - that = might not be the case). I'm not an onion routing expert. That may help too. You could try different paths with the methods described above and measure = delays to figure out different router paths (different ports between the sa= me routers a hard to detect). No matter what you do, and even with path awa= re networking, you'll not be able to figure out or avoid using the same fib= er by different networks. Please note, I'm not on the panrg list and readers there may receive this m= essage delayed. While I like your idea, my time doesn't suffice for an ongo= ing support. Regards, Ruediger --_000_LEJPR01MB0460557D8F3CCEE86A9C46449C570LEJPR01MB0460DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Yingzhen,

 

my take from the presentation w= as, that forwarding along different paths is a or the major design goal. If= more than a single packet is forwarded that way by a single transport rela= tion, adoption of a transport protocol may be an issue.

&nbs= p;

You write= :

  • Adding more sourc= e and destination address, if IGP is used to calculate routing, then you st= ill end up on the same route because of SPF.
    RG: the PANRG investigates the usage of different paths, not differe= nt routes, if I got that correctly. A layer 2 tunnel and a non-VPN layer 3 = packet sent on different accesses may be forwarded along the same SPF routed path, if the CE routers are identic= al at both ends. As a general statement, I think it would help PANRG to spe= cify what a path is. I doubt that any network provider will support a unive= rsal path infrastructure ping presenting everything from layer 0 – layer 3.
    A fairly good method to determine whether different paths exist to me seems= to be measuring RTTs of packets exchanged between end-points connected to = one or more provider networks after address variation has been performed. T= he accesses shouldn’t belong to the same access network section. On a single access network section, there= may be little or no path variation.
  • This will require= change on hosts because you can’t use one TCP or MPTCP session.=

MPTCP is designed to use different paths by different addresse= s (and https://www.rfc-editor.org/rfc/rfc6182.tx= t mentions, that SCTP also supports multipath & multihoming)= . So MPTCP is based on the principle of different paths using different address-pairs already.

Of course, if additional address- or IPv6 flow label variation= is introduced, more paths might be used. This could result in packet re-or= dering at the destination. The transport and higher layers will have to cope with that. Varying source addresses wi= ll require transport adaptation anyway, if TCP is used. The ACKs need to ge= t back to the sender.

 

Impacting forwarding path selec= tion by different source and destination addresses is a fair approach withi= n a single domain, I think. In the case of IPv6, the flow-label is an input= used for ECMP, see https://www.rfc-edit= or.org/rfc/rfc6437.txt . Then the IP addresses may even be maintained a= nd different paths may be addressed by varying the IPv6 flow-label.

 

Source address variation may fa= il, if uRPF is active, see https://tools.ietf.org/html= /rfc3704 , and the source address isn’= ;t assigned to the access sending the packet. uPRF may be configured at con= sumer accesses.

 

Regards,

 

Ruediger

 

 

Von: Yingzhen Qu <yingzhen.qu@= huawei.com>
Gesendet: Montag, 1. April 2019 23:45
An: Geib, R=FCdiger <Ruediger.Geib@telekom.de>; stefan.rass@aa= u.at
Cc: Lin Han <Lin.Han@huawei.com>; panrg@irtf.org; ietf@trammel= l.ch
Betreff: RE: draft-rass-panrg-mpath-usecase

 

Hi  Ruediger,

 

Thanks for your interests in our draft and comments at = the mic during Stefan’s presentation.

 

I didn’t get a chance to answer your question dur= ing the presentation because of the shortness of time. If I understand righ= t, you were suggesting to add different source and destination address to achieve multiple path, it is useful in some cir= cumstances but I see some limitations. Let’s take a single domain/AS = as an example:

  • Adding more sourc= e and destination address, if IGP is used to calculate routing, then you st= ill end up on the same route because of SPF.
  • This will require= change on hosts because you can’t use one TCP or MPTCP session.=

 

Acrossing domains is more complicated, but the 2nd= point still applies.

 

Thanks,

Yingzhen

 

From: Ruediger.Geib@telekom.de [<= a href=3D"mailto:Ruediger.Geib@telekom.de">mailto:Ruediger.Geib@telekom.de<= /a>]
Sent: Thursday, March 28, 2019 7:23 AM
To: stefan.rass@aau.at
Cc: Yingzhen Qu <yingzh= en.qu@huawei.com>; Lin Han <Lin.Han@huawei.com>; panrg@irtf.org; ietf@trammell.ch
Subject: draft-rass-panrg-mpath-usecase

 

Hi Stefan,

 

the idea to route packets conta= ining encrypted information via different paths sound reasonable to me. Thi= s may be challenging for higher layers, but well, one may be able to design= them to cope with packets received from different paths, I think.

 

I’ve recommended to inves= tigate available options rather that path detection this morning. Some of t= hese are:

  • An end system can be multihomed
  • There’s= multi-path transport, like MPTCP
  • If the IP-addre= sses can be varied, the packets will likely follow different Equal Cost Mul= ti-Path’s (ECMP, search the Internet). Varying source address will do= .

 

Multipath could mean:

  • Same fiber, different router interfaces/headers (imagine the LTE path a= nd fixed access sharing the same fiber at some part of a layer 0 path) .
  • Different parallel ports of a router, but same rout= er to router hop
  • Different router hops (combined = with different ports).

 

What likely is difficult is to = vary the AS path. That might work, if you are multihomed with different net= works. For a single domain, you may have to use a proxy or a tunnel to reac= h a different section of that domain (but I assume that there are multiple peerings to reach the destination AS= – that might not be the case).

 

I’m not an onion routing = expert. That may help too.

 

You could try different paths w= ith the methods described above and measure delays to figure out different = router paths (different ports between the same routers a hard to detect). N= o matter what you do, and even with path aware networking, you’ll not be able to figure out or avoid usi= ng the same fiber by different networks.

 

Please note, I’m not on t= he panrg list and readers there may receive this message delayed. While I l= ike your idea, my time doesn’t suffice for an ongoing support.

 

Regards,

 

Ruediger

--_000_LEJPR01MB0460557D8F3CCEE86A9C46449C570LEJPR01MB0460DEUP_-- From nobody Wed Apr 3 19:19:35 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE507120198 for ; Wed, 3 Apr 2019 19:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HR-TgSSx2Ahz for ; Wed, 3 Apr 2019 19:19:31 -0700 (PDT) Received: from huawei.com (szxga08-in.huawei.com [45.249.212.255]) (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 5B2371201B6 for ; Wed, 3 Apr 2019 19:19:31 -0700 (PDT) Received: from DGGEMA403-HUB.china.huawei.com (unknown [10.3.20.44]) by Forcepoint Email with ESMTP id AAE04582DDFC85F94530 for ; Thu, 4 Apr 2019 10:19:27 +0800 (CST) Received: from DGGEMA523-MBX.china.huawei.com ([169.254.5.23]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0415.000; Thu, 4 Apr 2019 10:19:19 +0800 From: "Zhouxingwang (Joe)" To: "panrg@irtf.org" CC: Liyizhou Thread-Topic: New Non-WG Mailing List: LOOPS Thread-Index: AQHU6W+GuP2uEpQQbEqrEy6CRFl/N6Yp8vdggAFOEhCAAAVuUA== Date: Thu, 4 Apr 2019 02:19:19 +0000 Message-ID: <720EED753402F64F964F672F51929CDD01DC3EA8@dggema523-mbx.china.huawei.com> References: <155422177532.6400.569642190649683451.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.27.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [PANRG] FW: New Non-WG Mailing List: LOOPS X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:19:34 -0000 To those might be interested, LOOPS (Local Optimizations on Path Segments) = mailing list was created. Thanks Joe -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IE= TF Secretariat Sent: Wednesday, April 03, 2019 12:16 AM To: IETF Announcement List Cc: cabo@tzi.org Subject: New Non-WG Mailing List: LOOPS A new IETF non-working group email list has been created. List address: loops@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/loops/ To subscribe: https://www.ietf.org/mailman/listinfo/loops Purpose: Performance enhancing functions in the network increasingly no longer can p= eek into and manipulate higher layer information, but now can be built on m= ore powerful platforms. That opens the opportunity to perform optimizations= such as loss recovery (retransmission, recovery via FEC) between the ingre= ss and the egress nodes of a tunnel that spans a path segment. LOOPS (Local= Optimizations on Path Segments) is an effort to start a working group that= defines a protocol for such a function and an information model for the da= ta exchanged between the tunnel ends, with bindings to multiple encapsulati= on schemes. More information can be found at https://github.com/loops-wg/. This list belong IETF area: TSV For additional information, please contact the list administrators. From nobody Mon Apr 8 14:18:42 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CC212010E; Mon, 8 Apr 2019 14:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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=gmail.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 uTs1dlTwGF_3; Mon, 8 Apr 2019 14:18:38 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B895C120089; Mon, 8 Apr 2019 14:18:38 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id u12so12334948iop.11; Mon, 08 Apr 2019 14:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Qoun6jXas9D9qXTLZhsbGDEs14A/yBH6P20Cy0s+7V4=; b=hHrI+sPysdYjxFBqt8tV52kWaEIcNiehlgQGivE7KXtjc9Yi4LxXzljJH+549PA2NZ Me76ocat1x+YrG9WXhzJ4R2niQC4rh4XoViaS6jK+eb81rWt7pia/F3uP4lFj6Jz+LJc c8i1Mz1dea8V5sJibl8qcAYpB1ndSAGi7nKQ+i3ZZUvR59YbATDJZ78gxm6JpNCdJeiR weWytCDdaxjzszlw+ur6z9SYYcio7B+XjC1Y8gMYDD5xWwtLXTmfLvG/0wzB/f1AAgxE uJSKgfqyD/XlsJ95PjRal0FIZx8BD3iPOv3IIuXQGHsvrUBkcGaAUVQEGP4LX+KCAAmG 7DWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Qoun6jXas9D9qXTLZhsbGDEs14A/yBH6P20Cy0s+7V4=; b=YzazOa3Bvl4P5b/OLbSV4btnyDlyYtOQKOhbY432155ZJp0wnNuociJ99L69lh+qON C6K3xmyCiw5GwmdYaiTfgSAHOQ9FHFRxge5CePTy35jvh1VCyzpjemyIb8Jq7pXH5nJ8 1EoYezPqs75I2+Pi11bNMuwZO08O9yDsjX/S1pAuvz1crwSubMYFzX+OnLkgaHLfW8Pm SuBzCcjDF179FW2FIQbkwFG2MxhWrUPdEn1SsKBHTVH3qvYH+3sOedaCSeBteyIX2LM7 Mgsig9gsJwjeSEuDbPkk7inQnOrXPsa3Z7TVm2EOO2FampraDTtkyHxpHmwjde8Wlbbe SCbA== X-Gm-Message-State: APjAAAUFucLArqo/KjBGqyj43OwXBlk72E2o41BBSSMUVuko31L5Vf1H P02bVRySy3IhRZDH5K2NAFR6f67OZLgnDD4k48+IslBcVwk= X-Google-Smtp-Source: APXvYqycVgCZjGej3t5wtl2BHmXUiw+W57ZQma7o5TrDaUDL723eAjeeUkmf9PseIvqh+ibIu0F9CSUOuUmdNH4thc8= X-Received: by 2002:a5e:c742:: with SMTP id g2mr21264233iop.56.1554758317607; Mon, 08 Apr 2019 14:18:37 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Tue, 9 Apr 2019 07:18:26 +1000 Message-ID: To: panrg@irtf.org Cc: panrg-chairs@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [PANRG] IETF104 PANRG meeting minutes published X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 21:18:40 -0000 Hello, The meeting minutes from IETF104 PANRG session have been published: https://datatracker.ietf.org/meeting/104/materials/minutes-104-panrg-00.txt Huge thanks to our minutes takers volunteers; Tommy Pauly and Dave Plonka! If you were presenting or said smth at the mic during the session please have a look (at least to make sure your name is not misspelled ;)) In case of any inaccuracy found in the minutes, please let the chairs know. -- SY, Jen Linkova aka Furry on behalf of PANRG chairs. From nobody Fri Apr 19 01:40:14 2019 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF231200E0 for ; Fri, 19 Apr 2019 01:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wlI0YZUGmzbp for ; Fri, 19 Apr 2019 01:40:10 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AF112008F for ; Fri, 19 Apr 2019 01:40:09 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 44lqD80WdVz8t4G; Fri, 19 Apr 2019 10:40:08 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 44lqD76sXWz3wbj; Fri, 19 Apr 2019 10:40:07 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0439.000; Fri, 19 Apr 2019 10:40:05 +0200 From: To: "Brian Trammell (ietf@trammell.ch)" , "panrg@irtf.org" Thread-Topic: Review of draft-irtf-panrg-questions-01 Thread-Index: AdT2i3uUWJnGRAHHSmiAVCRLlFVqIg== Date: Fri, 19 Apr 2019 08:40:05 +0000 Message-ID: <6678a69a-b753-4c0b-beee-9364a8d52e7e@OPEXCAUBM6F.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_6678a69ab7534c0bbeee9364a8d52e7eOPEXCAUBM6Fcorporateadr_" MIME-Version: 1.0 Archived-At: Subject: [PANRG] Review of draft-irtf-panrg-questions-01 X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 08:40:12 -0000 --_000_6678a69ab7534c0bbeee9364a8d52e7eOPEXCAUBM6Fcorporateadr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, all, As promised during the panrg meeting in Prague, please find below a first s= et of comments to this draft: * pdf : https://github.com/boucadair/IETF-Drafts-Reviews/blob/maste= r/draft-irtf-panrg-questions-01-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/= draft-irtf-panrg-questions-01-rev%20Med.doc Cheers, Med --_000_6678a69ab7534c0bbeee9364a8d52e7eOPEXCAUBM6Fcorporateadr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian, all,

 

As promised during the panrg meeting in Pra= gue, please find below a first set of comments to this draft:

·     &= nbsp;   pdf : https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-irtf-pan= rg-questions-01-rev%20Med.pdf

·         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-irtf-panr= g-questions-01-rev%20Med.doc

 

Cheers,

Med

--_000_6678a69ab7534c0bbeee9364a8d52e7eOPEXCAUBM6Fcorporateadr_--