RE: KRP ID Discussion.

"UTTARO, JAMES" <ju1738@att.com> Thu, 06 August 2020 13:16 UTC

Return-Path: <ju1738@att.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7533A0B91 for <rtgwg@ietfa.amsl.com>; Thu, 6 Aug 2020 06:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 otD2SoQsSpLd for <rtgwg@ietfa.amsl.com>; Thu, 6 Aug 2020 06:16:54 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 6F3E63A0B8E for <rtgwg@ietf.org>; Thu, 6 Aug 2020 06:16:54 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 076DBumi002232; Thu, 6 Aug 2020 09:16:53 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 32rfm5tph7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Aug 2020 09:16:53 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 076DGqCq012363; Thu, 6 Aug 2020 09:16:52 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 076DGnMH012335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Aug 2020 09:16:49 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id DFE004009E6C; Thu, 6 Aug 2020 13:16:49 +0000 (GMT)
Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (unknown [135.50.89.103]) by zlp30486.vci.att.com (Service) with ESMTPS id B8AFB4009E62; Thu, 6 Aug 2020 13:16:49 +0000 (GMT)
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 6 Aug 2020 09:16:49 -0400
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.2044.004; Thu, 6 Aug 2020 09:16:49 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: rtgwg <rtgwg@ietf.org>
Subject: RE: KRP ID Discussion.
Thread-Topic: KRP ID Discussion.
Thread-Index: AdZpymkU6yeQv22aRiK8v0sZb9QUgQBpfhmAAANoURAAHWhdgAABpnMAAACAAIAABbhWAAAID2ig
Date: Thu, 06 Aug 2020 13:16:49 +0000
Message-ID: <c93651c9195e44f8929efdf7470b2a23@att.com>
References: <AM7P194MB0723C0A04F5BDAC8BF9FF59EAE4D0@AM7P194MB0723.EURP194.PROD.OUTLOOK.COM> <CABY-gOOd2T7zJ4586NQsPTt0=r+7Ky1Wie1NpUyKBNVCc1xKpw@mail.gmail.com> <AM7P194MB07231036E6266340E07C7DF5AE4B0@AM7P194MB0723.EURP194.PROD.OUTLOOK.COM> <CAOj+MMFhVAAX1Y767tGw9jL7nfdPyoPmPNJDuLA6cME7VNN5fg@mail.gmail.com> <74D363BB-A26C-49DA-9FA3-E450C5A14A8C@gmail.com> <CAOj+MMGLEzyPx0GA9-xLbPn-VPrsXz+32ti-Za8eY+J_Layf+A@mail.gmail.com> <147C2BCF-C3EE-4C29-A72F-83F3C0AFBE78@gmail.com>
In-Reply-To: <147C2BCF-C3EE-4C29-A72F-83F3C0AFBE78@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.138.131]
x-tm-snts-smtp: 9A0598E210273960C2009BF8825D64D62AFD9D26FEFD690F32B19C6DA23D260A2
Content-Type: multipart/alternative; boundary="_000_c93651c9195e44f8929efdf7470b2a23attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-06_09:2020-08-06, 2020-08-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008060094
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/vnaIAZ4OkSjM8RoTXtElBMWZW5s>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 13:16:56 -0000

The intro section has the following line:

“The internet will be subdivided into logical regions or by the physical location of continents”

How will this routing protocol adapt when geo-political change occurs as it always does resulting in a different connectivity model ?

How will a governance in a given continent opt out or in to said constraints imposed by it’s location or logical region?

Thanks,
              Jim Uttaro

From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: Thursday, August 06, 2020 9:01 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: rtgwg <rtgwg@ietf.org>
Subject: Re: KRP ID Discussion.

Hi Robert,


On 6 Aug 2020, at 11:16, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Hi Stewart,

I hear what you are saying and politically speaking I understand your comment. Not that I would agree - but this does not matter.

Firstly, I should make it clear that I am not advocating this, and since you mention 2030 in the next line the 2030 project is definitely not proposing this.

My remarks are based on what I see in the world about me and what I hear from talking to people in the industry.



But just thinking on the technical level I do not understand it. Are you saying that maybe in 2030 it would not be legally possible to create a link of some form (physical or virtual) and run single IGP between US and Europe ? Or between EMEA and Japan ? Or EMEA to Africa ?

Well who knows. You can see as I do what the US administration is saying about “clean” networks, whatever that means. You will have also seen what the EC is saying about where personally identifying data can flow. You will have also heard in SPRING/6man about the US restrictions on how its traffic can travel around Africa. My crystal ball is no better than anyone else’s but the signs are not good that the best engineering solution will win against what the politicians require of the operators.



Are you saying that global operators would have to artificially divide their networks into chunks ? And who would control what goes between such chunks ? ITU-T ?


Look at what the politicians seem to be saying. All I know is that the operators have to obey their rules, that  the engineers have to design systems that meet the operators needs, and the politicians are apparently retrenching from globalisation to nationalism. That does not mean that I support such changes, I am just trying to understand the engineering implications of what seems to be happening.



What about new zoo of satellites just launched to precisely offer Internet without any geo boundaries ? Would we need to now map earth continents to orbit and create "fences" in the space as well ?

Setting aside the weaponisation of space that is being reported, this is an interesting issue and one that started me on this thought train.

About a year ago Mark Handley presented a paper looking at how the zoo would work without free-space optics, since that seemed to have been omitted from the first bloc of Starlink satellites. His conclusion was that the operator would need to use the earth terminals as relays and he speculated that since Starlink owned both the satellites and the earth terminals every earth terminal could be a relay. It was an interesting talk and worth looking up on Youtube. I was explaining this to a senior member of SG2 at a T-SAG meeting and it was at that point that I was told of the huge problems that exist in telephone numbering (which includes call routing) as a result of political considerations about which countries traffic can transit their network. It was suggested that this would apply to ground terminal transit traffic. Now, I have no idea how this will pan out, but it is not inconceivable that the ground terminal radio licences (which most governments strictly control) could specifically prohibited transit destinations.



Sorry but not only that would be end of the Internet but possibly end of Google, MS, FB and other global operators and enterprises too. Or maybe the idea is to kill open Internet and still allow enterprises to be global and take most of the transit ?

Do not shoot the messenger.

I do not advocate this.

I am simply thinking about the engineering consequences of what I see.

Something that I learned at business school was to always understand where the power is. Despite the huge size of the global operators, at the moment the power  is still with nation states, and many of them are getting concerned about the power of the big operators.

I have no interest in killing the open Internet. I have worked to support it for long enough. However that does not invalidate my concern about the trajectory of global politics and the engineering implications for the network.

Stewart



Best,
R.

On Thu, Aug 6, 2020 at 12:02 PM Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>> wrote:
Robert

I make no comment on the draft, but whilst what you say is currently true, the state of world politics seem to make the current decoupling of the various topologies that we enjoy at the moment less likely to continue than was the case a few years back.

The political actions of governments trumps (if you excuse the unfortunate pun) the preferences of the engineers and accountants.

ITU-T SG2 (numbering) has a list of Middle East cases of traffic routing issues based on politics, the EU GDPR rules, the developing countries' concern over traffic patterns, the actions of the current US administration, all take us in the direction of the application of geo and political considerations to traffic routing.

Regrettably, the writing is on the wall for restrictions to become normalised and built into the traffic planning rules, and that will push them into the routing system.

Stewart

> On 6 Aug 2020, at 10:15, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
>
> Khaled,
>
> Physical network topologies do not follow geo nor political boundaries. Any solution based on the above is simply not practical.
>
> Best,
> R.