Re: [spring] Beyond SRv6.

Andrew Alston <Andrew.Alston@liquidtelecom.com> Mon, 02 September 2019 16:04 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB48E1200D5 for <spring@ietfa.amsl.com>; Mon, 2 Sep 2019 09:04:04 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ojSFS8agitxs for <spring@ietfa.amsl.com>; Mon, 2 Sep 2019 09:04:02 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DB5120088 for <spring@ietf.org>; Mon, 2 Sep 2019 09:04:02 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp2058.outbound.protection.outlook.com [104.47.0.58]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-188-c0_GZdD4NeKU1oykyykc4g-1; Mon, 02 Sep 2019 17:02:47 +0100
Received: from VE1PR03MB5422.eurprd03.prod.outlook.com (10.255.112.208) by VE1PR03MB5312.eurprd03.prod.outlook.com (10.255.112.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 2 Sep 2019 16:02:46 +0000
Received: from VE1PR03MB5422.eurprd03.prod.outlook.com ([fe80::c456:2d7a:c516:486c]) by VE1PR03MB5422.eurprd03.prod.outlook.com ([fe80::c456:2d7a:c516:486c%3]) with mapi id 15.20.2199.021; Mon, 2 Sep 2019 16:02:46 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Nick Hilliard <nick@foobar.org>, Robert Raszuk <robert@raszuk.net>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Mark Smith <markzzzsmith@gmail.com>, Rob Shakir <robjs@google.com>, Fernando Gont <fgont@si6networks.com>
Thread-Topic: [spring] Beyond SRv6.
Thread-Index: AQHVSwgx1C0+06fAOEubArDypHiFT6cV4KUAgAAFcACAAZc8gIAABhWAgAAB94CAACwmAIAAgL6AgAAo2gCAAAykAIAAC3QugAAoOICAAGFNAA==
Date: Mon, 02 Sep 2019 16:02:45 +0000
Message-ID: <F790C219-B784-4FC2-8D1F-866B544067E7@liquidtelecom.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54630831722DE1D3E6C7F872AEBC0@BYAPR05MB5463.namprd05.prod.outlook.com> <abded144-7557-1093-874c-0f9ca708af6a@si6networks.com> <BL0PR05MB5458C00081B05584E77DB19DAEBF0@BL0PR05MB5458.namprd05.prod.outlook.com> <160e947d-790e-67fb-3366-fdc5f1d34f8c@foobar.org> <CAOj+MMGCfpUxu+Rfgpk4Nhbjp2_PeRb-JnHOi7Ru3Ov085WWRA@mail.gmail.com> <CAO42Z2w7yGUQUtE474h5pk0=iz+F5dwRHPHDbAscJqHQiP+WuA@mail.gmail.com> <CAOj+MMH-Vjpbz0=VSDHBMDnDBPDyOCLFzKYFJQO0_7YPPOZcJA@mail.gmail.com> <CAO42Z2zCKQdBydLdOFFAmkZJ3zvtN+mfT4UAtJyrncqCUqpDgg@mail.gmail.com> <CAOj+MMHmLsTCaa_x+GVsLiH5Y+kBu3MBVOTYhE3WpGt8W90c_g@mail.gmail.com> <e02139fe-a06e-7fc0-7d5c-dae1e4010ddb@foobar.org> <CAOj+MMFjpVtJED8vSm_hmXLE2uTwbCE=-pDYR3=Et1=+gTfnfA@mail.gmail.com> <4826bf17-7263-690a-8c61-1c5a27641ab6@foobar.org>
In-Reply-To: <4826bf17-7263-690a-8c61-1c5a27641ab6@foobar.org>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
x-originating-ip: [197.155.81.44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4109c876-65a6-419f-db44-08d72fbefec2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR03MB5312;
x-ms-traffictypediagnostic: VE1PR03MB5312:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VE1PR03MB5312B0BEDC3B15A08CFFF3F6EEBE0@VE1PR03MB5312.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(366004)(346002)(39860400002)(199004)(189003)(86362001)(14444005)(966005)(99286004)(76176011)(54906003)(6506007)(256004)(53546011)(6486002)(316002)(36756003)(6246003)(58126008)(4326008)(236005)(6436002)(478600001)(26005)(186003)(53936002)(71190400001)(71200400001)(8676002)(102836004)(66476007)(91956017)(76116006)(6512007)(110136005)(33656002)(11346002)(25786009)(14454004)(476003)(2616005)(486006)(446003)(66946007)(7736002)(10916006)(229853002)(66556008)(66066001)(64756008)(66446008)(3846002)(6116002)(606006)(8936002)(81166006)(81156014)(5660300002)(54896002)(6306002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1PR03MB5312; H:VE1PR03MB5422.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Qj6dLSX6rjE/IzUQfvUtj7Ru0WPbeHW83FaqlGOUFVb5qB+IffMKW/t145xzNWFrAuzIYSnvcw2MIBDlqvHm/N4tt6JwfSVpaASOfnYt90rN2wniJqjrHHF2LNwtThGeFvzIHTx6ojTBKYLssHXfR543ijJ8WIrOOxxEUDAJ4/k/RjQhWEvcUbiAVqIJ0g1h74PZbi7aQ4M8wYCOoQbWHJZC7dvKi4wdi9pRqjkc/fXyznYOdSi+fW6/tgs2ZAUDBKBmkaUCZHrEDp+8I77yiHJaoO6HZhnR7X45ra/qVMB5UckZpkYBoA2Lu6Bgrp7lahIsqJUXSV7NHo5h0Z1YYfA5NztkhkeZfcOXzsHvuZRKNQGE+MsB2cDHhgo4wmUq4uBy9hMgzbSxSYibuf5XKVf3gW3/EIfDTyl1dOZea0A=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4109c876-65a6-419f-db44-08d72fbefec2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 16:02:45.9869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EgPPrv/3yjje8gDZjhbHI9vnobSPe39LcVj5PXu2Yg4ORVV1asuyqa5gQdp6neS0a8UTSk6Yr8bQg+AQfwYnxjSJ1/8wseeViXrBITSS6z4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR03MB5312
X-MC-Unique: c0_GZdD4NeKU1oykyykc4g-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_F790C219B7844FC28D1F866B544067E7liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/a2McTX2uKujTkXvxKzUMESRtmGg>
Subject: Re: [spring] Beyond SRv6.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 16:04:05 -0000

Just another note on clashes – any company that deals with constant and frequent merges and acquisitions will know – uniqueness is paramount – unless you want integration headaches that will cause you weeks of sleepness nights.

And when you’re doing 3 or 4 M&A’s a year – this is very very very important

Andrew


From: spring <spring-bounces@ietf.org> on behalf of Nick Hilliard <nick@foobar.org>
Date: Monday, 2 September 2019 at 16:28
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Mark Smith <markzzzsmith@gmail.com>, Rob Shakir <robjs@google.com>, Fernando Gont <fgont@si6networks.com>
Subject: Re: [spring] Beyond SRv6.

Robert Raszuk wrote on 02/09/2019 12:49:
> Yes you are 100% correct.
>
> The decision to inject any prefix into someone's IGP (or BGP) is a local
> operator's decision.

It is, and most operators take pains to avoid injecting shared
addressing resources into their routing domains. These days it usually
relates to policy, but that policy is rooted in the painful reality that
building infrastructure intended for second or third party tenancy on
the basis of overlapping number resources is something that can and will
cause catastrophic architectural problems once clashes occur.

So again, I suggest that if it's the intention for the draft to proceed,
the authors will need to reach out to RIR policy working groups because
the additional number resource requirements required do not fit in with
the current ipv6 resource assignment and allocation policies currently
in place.

Nick

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>