Re: What 's the process?

Tony Przygienda <> Thu, 20 February 2020 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B014B1200F5 for <>; Thu, 20 Feb 2020 12:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Q3YiyJIvZQ3 for <>; Thu, 20 Feb 2020 12:02:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF3B01200FF for <>; Thu, 20 Feb 2020 12:02:33 -0800 (PST)
Received: by with SMTP id z8so6130749ioh.0 for <>; Thu, 20 Feb 2020 12:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uqjVjoUj7Zn0WLxJ7sMxRBtYByDE7+G+7jZTpCO7M6M=; b=i9Up4TDmnmFLU4wMFIRoY9aJ1V1ynKVViUtp7EKtZeWnVEybiZ6BH27063xk9chQOS vX7RcPnv7WjFeqeYTuP/GiY5dbF+YIN2FzieEw7pAJeQUtHRGZHur6+g3y4dD6XJAewq Bt3fkz6I277rxtyMRAUYrnDhAWqh/hi9NXd9BvVOALPHhlWNV5siUDsdQTCTO3p0Ycc1 a+1R1RkaJ3cYL2836+CL7Ks/WuiwqYmGX0fEEgv7e0kvOOf97DhOv6WDi1Mp/qAyHl8e wqnom1F89C+QHx+XZy8Su/lClkTdgnOJpN1Pss/dUhcuFC3p7ZPhbo9VEbiuTcfNmRAR Xg2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uqjVjoUj7Zn0WLxJ7sMxRBtYByDE7+G+7jZTpCO7M6M=; b=FTBAioLZtU67bnKUW2Rz2nQDYugj976F9+upLEmoyZShXN+FWz4FWeloj5UVubtH4L +YKaefE3dN9QbyDrSPDM67dHQlR9mE0Gkm0hf/WVRdqMTuLNtmZOQRBtfxELdFyCF8sv 4sMr8iRjIC2SPtgcC1ZF24e5ArNY6Bp4oj18fxKxq7SaT7tPze/sFfqb9qeVeT21qJwN Ob0Ipf849wuZfYKv85UduVAOpqKo43sz43XEoz2kit1Unb48h+yZNDddoFbKu1RKkFDU OKokNCp1XPj2hlEUxqrOkm+V0TY1cSqcm9FuWOf4jCgdnNjcXPV2K4CuQqyD26Vn4+bo xhRQ==
X-Gm-Message-State: APjAAAXX9sWAqsUSMGGf17Sr9NPqUq3jk1Iqw63gUWwJN3dS8c3XEPDe yR4F/v1Zn/oFfOM1E7Mt9gjJ/Hk8W4rL6ruU8gw=
X-Google-Smtp-Source: APXvYqwN5KRgL9ZwFqkrKqo+aVOuut6taFrfqVQmUoqqesU/NrjHPs7dTlFRP5rp0s2D3fqWCRXAJhYnYXmHExPxNBs=
X-Received: by 2002:a02:c78f:: with SMTP id n15mr27313775jao.100.1582228951090; Thu, 20 Feb 2020 12:02:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tony Przygienda <>
Date: Thu, 20 Feb 2020 12:01:34 -0800
Message-ID: <>
Subject: Re: What 's the process?
To: Andrew Alston <>
Cc: "Darren Dukes (ddukes)" <>, Ron Bonica <>, Ron Bonica <>, 6man WG <>
Content-Type: multipart/alternative; boundary="0000000000009549f8059f0762b2"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2020 20:02:37 -0000

Amen to Andrew's email as to technical terms ... As "procedural objections"
side-swipe: IETF is (still?) rough consensus, running code & ideally
deployment rather than ceremony and process lawyering ... And yes, ideally
not breaking standards published v6 drafts and hi-jacking address semantics
because they're "just bits" ...

I guess in shorter terms +1 for adoption here

--- tony

On Wed, Feb 19, 2020 at 6:20 PM Andrew Alston <> wrote:

> 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
>       1. In a way that is compatible with inter-domain traffic steering
>       (this works with CRH, we’ve proved it:
>       2. 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)
>       3. 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
>       1. 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
>       2. Anything that results in what I have heard as described as
>       routing by NAT in order to reduce the header size.
>       3. To violate rfc8200 through either the insertion or deletion of
>       headers in flight
>       4. To inflate the size of the IGP by separating our loopbacks and
>       our SID’s
>       5. To run into problems as concerns RFC7112 when the SID depth
>       becomes deep enough
>       6. 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------