RE: What 's the process?

Andrew Alston <Andrew.Alston@liquidtelecom.com> Thu, 20 February 2020 02:18 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 0D75D12029C for <ipv6@ietfa.amsl.com>; Wed, 19 Feb 2020 18:18:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OUE-9o9HwHZw for <ipv6@ietfa.amsl.com>; Wed, 19 Feb 2020 18:18:45 -0800 (PST)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.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 14ABE1201DB for <ipv6@ietf.org>; Wed, 19 Feb 2020 18:18:44 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2052.outbound.protection.outlook.com [104.47.12.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-147-Pd44ZUQgN1qAiFMsn7Sy4Q-1; Thu, 20 Feb 2020 02:18:37 +0000
Received: from DBBPR03MB5415.eurprd03.prod.outlook.com (20.179.47.79) by DBBPR03MB5416.eurprd03.prod.outlook.com (20.179.47.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Thu, 20 Feb 2020 02:18:35 +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.2729.033; Thu, 20 Feb 2020 02:18:35 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>, Ron Bonica <rbonica@juniper.net>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Subject: RE: What 's the process?
Thread-Topic: What 's the process?
Thread-Index: AdXmRp2+j8roA37CTn+ijAU1LR1JcgAZNNvAACkTwYAADxsE0A==
Date: Thu, 20 Feb 2020 02:18:34 +0000
Message-ID: <DBBPR03MB5415D1A6EEB3FA0C6C2CD3BEEE130@DBBPR03MB5415.eurprd03.prod.outlook.com>
References: <C7C2E1C43D652C4E9E49FE7517C236CB0290463E@dggeml509-mbx.china.huawei.com> <DM6PR05MB6348D001F5397DFF015BE22AAE110@DM6PR05MB6348.namprd05.prod.outlook.com> <735EF3B3-E3CD-4C44-B0F4-1439D490B62B@cisco.com>
In-Reply-To: <735EF3B3-E3CD-4C44-B0F4-1439D490B62B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2c0f:fe40:3:1:c8f6:e4b:a874:c11d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d99f4c62-3077-48d5-7249-08d7b5ab3066
x-ms-traffictypediagnostic: DBBPR03MB5416:
x-microsoft-antispam-prvs: <DBBPR03MB54167F2DDE36C95B4D78AFEBEE130@DBBPR03MB5416.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(396003)(346002)(376002)(39860400002)(136003)(189003)(199004)(9686003)(81156014)(8676002)(81166006)(8936002)(55016002)(33656002)(4326008)(5660300002)(2906002)(52536014)(66946007)(6506007)(66556008)(71200400001)(7696005)(64756008)(66476007)(186003)(76116006)(54906003)(110136005)(316002)(478600001)(966005)(86362001)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5416; H:DBBPR03MB5415.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3/b2eRZRPSBBc+GcL6Ig5Dn3AmttB7FVoz+5Ath2kEpEVdehTdmIhuwEkU6AxsR/Yk21brBd5p0bh4jfT6fDQLfD1FOqy59lPRT00DyJzPu8/9h6zcR6C5eV4QAQCr/Emflf0VKNE5bdurwxfg+yfCkdRLhaMIkSsPi80+uHKu37u606RHw6crzCDZHXAqSpTpOfSxyjFACkBabOhviaKa0n1MEWSfH6F4dlbAkbaPZu+aGn+tcndWiPIc2SD7IsY5poPg//p96JtFU9xr/dY7nP2If26jLeSLns9EqpnTztwImuvJzKpze1zikCeLKFyEt1Qx+5hu3Wie9pQhRxfA+jFRqpae3ZJARtnv5qIYgO9tU42N0Kz5U/VjbxRyR2mBzWWkpT3jEwWLzmujdHyz6FdXHv55/RQ7BUW0j8n6S+emQ2EqH60Ym1nRpZMNHm9E/lBxYlmJHv/U47u8ETaY22cOHMnpHK1hMF9rsfOUoeFtU3KYlC0gvxj+pxfHXXTFAqU2Az6jsz+iT8quFgEg==
x-ms-exchange-antispam-messagedata: 6kjyG7OqldoyMltOjkblyR6b0COujRijKb6UJcpBrbqiTI5HGxAkOpp9exovdGvw7v1J/KmQlVd1wDTIrffk3nMODluEInIW++ria3f8MNnByvwvPq894bLqiyXf12XIy2EcA5NWnFTXAZf8V09o4wmxoyOkTcNeo7sCgiWMm86NuKozwaGiVSIU017odwicjhcHXOACOgYckCoEYgV1sg==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d99f4c62-3077-48d5-7249-08d7b5ab3066
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 02:18:34.9741 (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: b6aZiljAQHBFx+YV/xBmcFwO2MIXY+ICgFiZG1yBlJc+b/Hlm6dxlHCPvDpkIKG1kCklxIzg3uA2OemBzb0UHizHBEkZ8SztEdeECfy/BX8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5416
X-MC-Unique: Pd44ZUQgN1qAiFMsn7Sy4Q-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_DBBPR03MB5415D1A6EEB3FA0C6C2CD3BEEE130DBBPR03MB5415eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AaK6S2IOjWGQWbOT3bvv53U7EMc>
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: Thu, 20 Feb 2020 02:18:50 -0000

Darren,

I've given a lot of thought to what I'm going to say next - and the fact that a lot of it is repetition of what I have said over, and over, and over again - much of which you have chosen to never respond to.  In that vein - I am going to take this in point form, and I encourage you to go back through the emails I have sent over the last year or more for expansion on each of these points, in a similar way to how people need to read RFC's before questioning their content.

Let us start with - what is the use case -


  1.  We need to be able to steer traffic
     *   In a way that is compatible with inter-domain traffic steering (this works with CRH, we've proved it: https://mailarchive.ietf.org/arch/msg/spring/KeWOkXeN9JPv8acD1oC99qjdsxU
     *   We need ways to steer traffic that allow us to do this with very deep stack depth - going as deep as 10 or 12 SID's - without the vast traffic overhead that would exist in the case of SRv6 - while at the same time maintaining the ability to track the packet through the header (which is accomplished through the immutable nature of the header)
     *   We need to be able to cross segments of the network that have no support for SR-MPLS in the context of IPv6 - and this is particularly important considering statements from certain vendors that they have no plans or desires to implement SR-MPLS as concerns IPv6 - despite supporting it for IPv4.


Now, with that said -


  1.  We do not need, want, or require
     *   Overly complex programmability - some may - that is simply not something we see a need for today - I don't begrudge those that do need it or wish to implement it
     *   Anything that results in what I have heard as described as routing by NAT in order to reduce the header size.
     *   To violate rfc8200 through either the insertion or deletion of headers in flight
     *   To inflate the size of the IGP by separating our loopbacks and our SID's
     *   To run into problems as concerns RFC7112 when the SID depth becomes deep enough
     *   To utilize any protocol that fundamentally redefines the semantics of an IPv6 address with all the unintended consequences this may entail

Next - let me address another point.  You constantly question the use case.  Let me state this, what is a use case.  It is that which an operator, or group of operators utilize a technology for, that they find beneficial and that enhances their network.  It is that simple.  In the context of the requirements above, we strongly feel that other proposals out there do not meet our needs, in any way shape or form.  We do however know for a fact that what is defined in the CRH draft - does - it works - its deployed - it exists - and it meets a need.  Now, just as I said we have no requirement of all the items in B, you may not see a requirement in your context for what we need out of CRH - that does not make our use case any less valid, it simply makes it irrelevant to what you believe is required by yourself, in the same way that what you have defined has no relevance of our network today.  That is not a bad thing - but - different things work for different networks in different environments.

Speaking for myself, I have no desire to see SRv6, the network programming draft or the rest stopped or work to cease on them.  I acknowledge that some people may have a requirement for things in those documents, however, those documents do not come CLOSE to addressing that which is required on our network, and instead, violate several key principles by which we operate, including the introduction of technologies which in our view are overly complex, excessively difficult to debug, risk redefinition of already existent standards without knowledge of the unintended consequences, and so the list continues.  CRH in and of itself is a new routing header - it meets a requirement that we have, and if we saw that requirement as a result of the studying of other documents and upon the realization that those documents did not meet that requirement at all, is irrelevant.

What I have not seen over the last while however, is you disputing the technical feasibility of the document.  Your arguments are pretty consistent regarding what you believe is about use case - except, when myself, and others, have clearly stated that we have a use case for something else, and indeed with the amount of time spent developing both the documents and the code, this argument is clearly contra-indicated through both these statements and that work.  Interestingly enough, it is also contra-indicated through the introduction of the micro-sid draft, because the moment you published that - which came after the initial publication of the CRH document, you acknowledged the need for header compression, and you acknowledged through the very existence of that document that there is a fundamental requirement to reduce the header size imposed.  If you dispute that, then I cannot understand why said draft exists.

Now, if you wish me to go and write yet another rfc draft to define why we need this - and in the absence of any such documents describing the use cases for various other documents, I will do so, however, I do not wish to waste the time of people to deal with yet another draft when the on these lists, and at the microphone, time and again, these things have already been clearly articulated, and ignored.

So let me be clear - SRv6 does not have a place on our network - it does not meet our requirements - it will never meet our requirements - it has no use case within our domain - CRH on the other hand - does meet our requirements, it has a use case, and it works.  And while for another operator, the inverse may be true, and for some, they may see benefit in running BOTH technologies, that does not negate either of the technologies.

Thanks

Andrew