Re: So where have all these new 6man WG people come from?

Robert Raszuk <robert@raszuk.net> Fri, 29 May 2020 08:35 UTC

Return-Path: <robert@raszuk.net>
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 D1D6F3A0CEB for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 01:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 72LoIejSqMyL for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 01:35:43 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6F03A0CEC for <6man@ietf.org>; Fri, 29 May 2020 01:35:43 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id z5so1274530ejb.3 for <6man@ietf.org>; Fri, 29 May 2020 01:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8HamfarUT7Z44ghqVUj130NGFXm3YDdpP3CysQAaKZ0=; b=bkEJr53fod7QVUoaz5oMGjjNaYEN8E866SV84UrI/95HYV6nMr6DGm8rV+a1xL0Dds YviI2vUp44TzuOPbhBqJINPazRDtUige1rn3ZD+kYGNkef7JJggoXhZm/mrRRk9y+1MY boM/LKuwhtGfLqE+qJgKj05NZoKk4xDER32niz7gVMh4jmLmOT5BkYxZo+wE6HFjySUV eI2GvlgUsD3ft8aFoJVKRW02TdatPLqG3E2p5KZgZY1VhgH5T/GNL5BZAOGbm37QBFZF Vpuz6oDXmiQohz7ka58nrXRgk6LAnwqeeUX+7gbo982KmBoscUO37SdrVCqyTb2vK3V7 9SbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8HamfarUT7Z44ghqVUj130NGFXm3YDdpP3CysQAaKZ0=; b=rW3bCg5m/zetmMmHqNsn/8VdMEnmPF0iYfUKW2z7dUYYF9l9ku+qb9iUwhq86XxTXj Tw81UM7wPfbZ6jIr4kgynplRnAzKD32phtV22JzXp32Gf/6lLDhSDo/pIhlbIMdWYP0s XHwXLWAOLE+HBO+MWJWnDe8iYVvO8YEyzqFgKtfzczy9wpZb+dl81aJAOMzUB1glCl5B MjLxHkGWDdmhoO2uppxNTA3+GjGbARC7oePTRb4uEAB39TKHNJjxSigJACn0f8cQd8VW 6nTEnfvwv9Ic/w/uYyGtZ1nNeiMzPPQmEZdOPLSNYR33XhjupwxAT4lDC8gkT7Ch/YTu uN5w==
X-Gm-Message-State: AOAM532JS7LYwmuPTl9LG7pAciIDUo0gEMJl508l1pwn+bhefp636DeO 8/VOyONEWpZRXDzcg5alOizsztJ9hZTEqxveiAivXg==
X-Google-Smtp-Source: ABdhPJyfS3c1uLPJNtL6SWVO52XsDPjaiejKq8pzAZ/P6FliKm0s9cJyZl7s8BHKNRXYhbNEzUKqGtTfh+n+shjeBM4=
X-Received: by 2002:a17:906:f747:: with SMTP id jp7mr6567893ejb.110.1590741341342; Fri, 29 May 2020 01:35:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAO42Z2xDygUXTGwVunGSTMkZGMF8VePrPaXLSAJg14vAJdca5A@mail.gmail.com> <44595462-bef1-c1e9-5aed-f7a296bcac9e@gmail.com> <40f65b9fe1ee47168c59336b4415718b@boeing.com> <BCE8ACD8-4811-4CB6-A802-08DD8A9563B1@liquidtelecom.com> <CAOj+MMFR37NOSkfnT5ZUMDbtT3OKduh+DmQyi3bBsAvMsN7aYw@mail.gmail.com> <VI1PR03MB505689344D9E33E6D9010604EE8F0@VI1PR03MB5056.eurprd03.prod.outlook.com> <CAOj+MMENXqhpdkAuHvPc1-o2fpPobFunac+brV_N+xrDFVuHiA@mail.gmail.com> <VI1PR03MB5056FB4F25ED2FA0CC5515A5EE8F0@VI1PR03MB5056.eurprd03.prod.outlook.com>
In-Reply-To: <VI1PR03MB5056FB4F25ED2FA0CC5515A5EE8F0@VI1PR03MB5056.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 29 May 2020 10:35:33 +0200
Message-ID: <CAOj+MMEV+R_uz=DPk9mf4O7Br47DjGAyjxZ0Gd7wUkY_pAjipA@mail.gmail.com>
Subject: Re: So where have all these new 6man WG people come from?
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000094a87605a6c5542c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zXUHswphtPqKceNdzvhaMlubpOE>
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: Fri, 29 May 2020 08:35:46 -0000

Andrew,

You need to understand the difference between service and transport.

Removing MPLS from transport is happening left and right - and this is what
I said. It brings no value. It only brings problems.

No one states to remove MPLS from services - and this is what generates
revenue.

Kind regards,
R.

On Fri, May 29, 2020 at 10:31 AM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

> Drop MPLS all together…
>
>
>
> Errr Robert – I would respond to this with more detail – but – I’ve seen
> some pretty bizarre and out there comments that show a total fundamental
> lack of knowledge of what’s on the ground or what providers like ourselves
> do – and this one truly takes the cake.
>
>
>
> No value?  That’s why using the technology generates us billions of
> dollars of revenue every single year?
>
>
>
> Sorry – this is beyond hilarious
>
>
>
> Andrew
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Friday, 29 May 2020 11:03
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com>
> *Cc:* Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Brian E Carpenter
> <brian.e.carpenter@gmail.com>om>; 6MAN <6man@ietf.org>
> *Subject:* Re: So where have all these new 6man WG people come from?
>
>
>
> I say drop MPLS all together ... no need ... no value.
>
>
>
> For application which require encap use IP encap IPv4 or IPv6.  Hint:
> RFC7510
>
>
>
> Simplify rather then keep patching and complicate further.
>
>
>
> On Fri, May 29, 2020 at 9:58 AM Andrew Alston <
> Andrew.Alston@liquidtelecom.com> wrote:
>
> Robert,
>
>
>
> What part of – dual break – only path left is through the rings was not
> clear here?
>
>
>
> In the scenario that I mentioned – my path of last resort goes through a
> non-MPLS capable ring.
>
>
>
> There are no other paths left in the case of dual breaks at that point
>
>
>
> Andrew
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Friday, 29 May 2020 10:55
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com>
> *Cc:* Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Brian E Carpenter
> <brian.e.carpenter@gmail.com>om>; 6MAN <6man@ietf.org>
> *Subject:* Re: So where have all these new 6man WG people come from?
>
>
>
>
>
> >  – you don’t wanna be routing through those rings unless you truly have
> to – but – it is a path of last resort.
>
>
>
> Normally that requirement can be satisfied in any network by proper
> setting of link metrics in IGP or proper route preference in BGP.
>
>
>
> There is no need to roll TE of any sort there. It will just complicate the
> network - regardless of TE flavor.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, May 29, 2020 at 2:41 AM Andrew Alston <
> Andrew.Alston@liquidtelecom.com> wrote:
>
> I want to add another use case to this, and it’s pretty critical to some
> of my thinking
>
>
>
> Imagine this scenario –
>
>
>
> P -> PE <ASBR> -> Metro
>
>
>
> In the metro – you have a bunch of metro aggregation nodes – imagine them
> connected something like:
>
>
>
> A ßà B ßà Cßà D
>
> |           |           |          |
>
> E ßà F ßà G ßàH
>
>
>
> (I’ve included a png in case the formatting of this gets messed up)
>
>
>
> Now – say hypothetically there are rings of building handoffs that start
> and stop at separate metro nodes – so a ring that goes from D through H –
> say 10 devicse deep.   Those devices are:
>
>
>
> a.      Relatively low end devices – but have sufficient forwarding
> capacity to carry traffic between the metro nodes
>
> b.      Support MPLS on V4 – do not support it on V6 (and never will,
> since there is on LDPv6 on those devices, and well, LDPv6 was pretty much
> still born anyway imho)
>
>
>
> Now lets say I get a dual break – C to D and D to H – the only
> communication path left – as the path of last resort is one of the metro
> rings D through H – and yes – that’s a last resort – you don’t wanna be
> routing through those rings unless you truly have to – but – it is a path
> of last resort.
>
>
>
> In an MPLS world – V4 MPLS traffic will keep flowing – via the rings –
> using the last resort path. In a V6 world – I have a problem.  In an V4
> MPLS world – despite the fact that I do not have support SR-MPLS – I have
> SRMS which will allow me to actually run effective SR through the ring.
> There is no SRMS that I know of for V6 – or if there is – it’s certainly
> never been implemented by any vendor I have ever seen.  I could static
> backup tunnels over the metro rings and shove my v6 traffic over those –
> except – that means retaining V4 on the rings.  Alternatively – I could go
> either SRv6 (and I’ve stated many times why that doesn’t work for me in any
> way shape or form) or – I can use CRH – because the intermediary devices do
> not have to know anything about it.
>
>
>
> Bottom line – for those who wish to say “Qu'ils mangent de la MPLS” –
> guess what – this doesn’t work for us in this scenario.  CRH does.  I point
> out that replacing the thousands upon thousands of devices in the metro
> rings – also makes no logical sense whatsoever.
>
>
>
> So basically – there are cases where – I need to be able to run
> functionality over islands – I need to be able to do it without V6 MPLS
> support – and I need those devices to be able to pass the stuff
> transparently.  I do not wish to be creating static tunnels – I do not to
> break loose based steering because it has to flow through the path of last
> resort – and I have zero interest in running SRv6.  CRH – works in this
> scenario – it’s been tested – extensively.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> *From: *ipv6 <ipv6-bounces@ietf.org> on behalf of "Templin (US), Fred L" <
> Fred.L.Templin@boeing.com>
> *Date: *Friday, 29 May 2020 at 00:03
> *To: *Brian E Carpenter <brian.e.carpenter@gmail.com>om>, 6MAN <6man@ietf.org
> >
> *Subject: *RE: So where have all these new 6man WG people come from?
>
>
>
> Brian, please don't delete the message about a concrete use for CRH in
> real-world
> applications (planes, trains automobiles) with backing documentation:
>
> https://mailarchive.ietf.org/arch/msg/ipv6/g43uTZFNVyLV3y-kvrDn8Qktk1Y/
>
> Thanks - Fred
>
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> > Sent: Thursday, May 28, 2020 1:40 PM
> > To: 6MAN <6man@ietf.org>
> > Subject: Re: So where have all these new 6man WG people come from?
> >
> > I have concluded two things.
> >
> > 1. Most people have completely failed to understand the meaning of
> "adoption" in the IETF WG context. I and at least one co-author
> > will be submitting a draft about that to the gendispatch WG soon.
> >
> > 2. When I hear a choir singing, it is the same as hearing one voice.
> >
> > My personal decision at this point is to delete all messages about CRH
> adoption unread, except for the message we will soon receive
> > from the WG Chairs stating the rough consensus of the adoption call,
> which ends on 2020-05-29. I do feel sympathy for the Chairs who
> > must read and evaluate everything.
> >
> > Regards
> > Brian Carpenter
> >
> > On 28-May-20 23:23, Mark Smith wrote:
> > > I've been an active participant in the ipng, 6man and v6ops IETF
> working groups since 2002.
> > >
> > > While I've only been to one IETF meeting in person since then (106,
> sponsored by the Internet Society), over that time I've come to
> > recognise the names of many of the regular and active participants in
> these IPv6 working groups.
> > >
> > > I do not recognise many of the names of people who are objecting to
> the 6man working group adopting the CRH draft.
> > >
> > > Those who have been active 6man participants in recent years would
> know that even an ID adopted by 6man, written by Bob and
> > Brian, that had a number of revisions, didn't survive WG last call, and
> that occurred while Bob was (as he still is) one of the 6man WG
> > chairs.
> > >
> > >
> > > Regards,
> > > Mark.
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>