Re: What 's the process?

[Tony Przygienda <[e-mail]>]

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 <
[e-mail]> 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:
>       https://mailarchive.ietf.org/arch/msg/spring/KeWOkXeN9JPv8acD1oC99qjdsxU
>       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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>