Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

Andrew Alston <Andrew.Alston@liquidtelecom.com> Sun, 08 March 2020 06:29 UTC

Return-Path: <andrew.alston@liquidtelecom.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B833A0415 for <ipv6@ietfa.amsl.com>; Sat, 7 Mar 2020 22:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 A-lYqzGmhavc for <ipv6@ietfa.amsl.com>; Sat, 7 Mar 2020 22:28:59 -0800 (PST)
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 9FCA83A0414 for <6man@ietf.org>; Sat, 7 Mar 2020 22:28:58 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2058.outbound.protection.outlook.com [104.47.8.58]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-216-f6XWn4o5M5aQFBDZueiZvA-1; Sun, 08 Mar 2020 06:28:54 +0000
X-MC-Unique: f6XWn4o5M5aQFBDZueiZvA-1
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5464.eurprd03.prod.outlook.com (10.255.78.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Sun, 8 Mar 2020 06:28:53 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9]) by DBBPR03MB5415.eurprd03.prod.outlook.com ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.019; Sun, 8 Mar 2020 06:28:53 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
Thread-Topic: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
Thread-Index: AQHV84ENay90J8dLX0KMpi6XRkatwKg7jgmAgABzYYCAAAwXgIAAVN2AgAACCQCAAAHQgIAAA2UAgAAJoQCAAA4jAIABrsz+gAAOItM=
Date: Sun, 08 Mar 2020 06:28:53 +0000
Message-ID: <DBBPR03MB541538B6EE1766C19BEB4B9DEEE10@DBBPR03MB5415.eurprd03.prod.outlook.com>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@OPEXCAUBM43.corporate.adroot.infra.ftgroup><89402a30-129b-314f-90f1-ba6efcdd6a88@si6networks.com> <16536_1576089460_5DF13774_16536_366_1_53C29892C857584299CBF5D05346208A48D273AD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAO42Z2z2s92yitCC0eLrNO3dXe_EarRSUZq8GmJ=QRdZ59d0ag@mail.gmail.com> <64E8151B-DF45-4F30-A4AD-673E37A482DD@employees.org> <738133cf-1b87-90b3-614f-470b5546eedf@gmail.com> <CALx6S35=NWNu9iV7FU=zhmOwjB5T_WswyS13skpqfDfvL=G_jQ@mail.gmail.com> <1ea7ab65-7a07-5c78-aac7-bf202051a43a@gmail.com> <d1f32cb2-9f43-46cb-8585-319726e750b9@joelhalpern.com> <CAO42Z2wvCuj4YxBhmBAeh2yZdxi8uYy45o5gQNyEbHVGqu+_Eg@mail.gmail.com> <03a72a64-f7b7-e21a-b4b1-904fdec46203@joelhalpern.com> <CAO42Z2yY=KRbNjHwEofyGEFEYKcz0bEg73mjG=+c+RyRF8JRPw@mail.gmail.com>, <724735ae-61ee-6e66-376d-4c769ea8b942@gmail.com>, <DBBPR03MB54153298C1888DCB5D628FE1EEE10@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB54153298C1888DCB5D628FE1EEE10@DBBPR03MB5415.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [152.108.254.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 94a28f14-6cb8-4a49-33c0-08d7c329f8d7
x-ms-traffictypediagnostic: DBBPR03MB5464:
x-microsoft-antispam-prvs: <DBBPR03MB54649058A364FF588BDBF986EEE10@DBBPR03MB5464.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03361FCC43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39830400003)(366004)(346002)(376002)(199004)(189003)(81166006)(186003)(8676002)(81156014)(110136005)(54906003)(8936002)(33656002)(91956017)(64756008)(66946007)(66476007)(2906002)(7696005)(2940100002)(66556008)(76116006)(66446008)(45080400002)(26005)(52536014)(86362001)(53546011)(4326008)(71200400001)(55016002)(508600001)(5660300002)(9686003)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5464; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UVBXqi04hsKYjURQRe4+ajXSq/Z9OOix6/uuKpw2Mc0jicN+gPOlLse7aTX3nuOInDkapHuvsbiGWSxB6iwjmcjdReO7LWKbt5KcynNNY2i/LGxpG/vNr1vswLL5gItrFdXagu+qkkcCjcn9nXDWsaL4nlz3gd9nssfxLg5aMstWxAUXjRawWwR5AdQVjOqp8p9UQ0Ew0nythVq+j8+lk/ZtAvA+vWtHpeAQxxwKzHBdv9BfCVIPRZwrfiY4lzsPXEVa8KQaBkeOPBPGN0W7KeWxivqaqzORB+pGFTzGx/hFELZ6tFCoNQ0f0CrSCp+GIsLDp9NESnzwut1wUJGo9U56o2jUjZHrtoyDLXBi0MH4K07bPMu88VgB1Eq+4g2XjsCHbX9a8n3CIqjxyI+PfOk4DSRaxmf0/XjuXpIzPeCo8HlP+/u+WGP1NiAvhyyLRg1WshFav3WAz6LlN/dD3lzvaQF4BODAXV0emZYfiJRyQJDZ+xmm/dTmM2tbKtcdMIQCZsUnQ838QAwScTDYKw==
x-ms-exchange-antispam-messagedata: Iuo4H2z8il/O7Lc7wRNOEX1fKTkbwWM9b9K3wHmK0KxjSmC5MISYheiA3nxCxfElL8fEqPwjMGZ7ZhZnkJRiMKeuytkm9o7K3Qk/FCg+8Jky5L4i+Y5uOxwUi6JvAk+n4CGklag4JS3zTOwsesgmXw==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94a28f14-6cb8-4a49-33c0-08d7c329f8d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2020 06:28:53.0294 (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: 6d5uEDKxoPNeCahp4LG48Q8NfzZ9rGnplBP3+NUUl1OSrutUu0LoKd08zlgUc3Cp+mDktDB4MwWmlxJfGRM+62JbZDR3RH1iW6uE7rf4J0E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5464
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_DBBPR03MB541538B6EE1766C19BEB4B9DEEE10DBBPR03MB5415eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/40ekc1xBc-1twaJdaKRRhiWq7iA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 06:29:02 -0000

Sorry realized I had hit direct reply so adding relevant

Andrew

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Sent: Sunday, March 8, 2020 09:07
To: Brian E Carpenter
Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

Hi Mark, Brian

> RFC 4291:
>
> "2.1. Addressing Model
>
> IPv6 addresses of all types are assigned to interfaces, not nodes.
> An IPv6 unicast address refers to a single interface. Since each
> interface belongs to a single node, any of that node's interfaces'
> unicast addresses may be used as an identifier for the node."
>
>
> draft-ietf-6man-segment-routing-header-26:
>
> "4.3. SR Segment Endpoint Node
>
> When an SRv6-capable node receives an IPv6 packet, it performs a
> longest-prefix-match lookup on the packets destination address. This
> lookup can return any of the following:
>
> * A FIB entry that represents a locally instantiated SRv6 SID

The above issue with the fact that srv6 as a whole - and to a wider degree - mangles the ipv6 address semantics has been raised several times in spring by myself and others - and very studiously ignored - it’s been amazing how emails on these questions seem to magically disappear into spam filters.


> I'll bet you a beer next time I'm in Melbourne that the implemenations
> all assign such SIDs to the loopback interface. What else can "locally
> instantiated" mean in any vaguely Unix-like O/S?

Do I get to claim the beer if we are ever in the same place? :). I ask because I tested across a few platforms - and while most of the testing I did was on XR/eXR/XRv here is what I can say in the code I tested

A.) The SIDs arent assigned to a loopback - and from what I could see the Loopback couldn’t come from the same range as the “locator”

B.) There are some very strange length limitations on the length of the locator - specifically, the documentation explicitly states that the SID block portion of the address cannot be less than 40 bits in length, and the node section can not exceed 24 bits.  It also states explicitly that only a single locator is supported and that is the block used by default for SID allocation.

C.) Use of this means that every device you add a SID to now has 2 entries in your FIB with the IGP domain - which is you are running lower end edge devices creates a problem - particularly if you are already segmenting with areas so specific design criteria in order to keep that IGP entry count down so as to allow for the use of lower cost edge

D.) If you look closely post implementing this - you find that there is a new route type on the devices referred to as SRv6-Local - and each function instantiates a new “Local” IGP route - as in they show up in a look at for example the ISIS routes but never propagate beyond the end point node itself (in a test we instantiated 2000 VRFs and found 2000 local routes appeared - none of which were associated with any “Interface” as such.

I will also say - I’ve been configuring and troubleshooting networks for a long long long time - and my only thought as I went through the testing I’ve been playing with up till now - for so many reasons - was “God help the NOC that has to troubleshoot this the day it goes wrong” :)

Can I say if this is all implementations out there - no - not at all - but this is what I found on the ones that I have tested so far.  Then again - the implementations I have tested so far also never use the SRH and seem to have no facility to enable anything that would mandate it - and every request for packet dumps from these platforms or for configurations that would cause an SRH to be applied have again mysteriously disappeared into the ether (I’ve asked for such both on spring and directly).  Happy to share packet captures of what is actually happening.

Does make me wonder though what all the people in the deployment draft have deployed though - because in my book - if you haven’t got an SRH - you aren’t doing SRv6 - you are doing something that is probably more appropriately placed in BLESS


Andrew