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

Greg Mirsky <gregimirsky@gmail.com> Fri, 29 May 2020 18:42 UTC

Return-Path: <gregimirsky@gmail.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 2B7513A0EDB for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 11:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.com
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 7H9Rdj_6rSMt for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 11:42:09 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 5640E3A0F31 for <6man@ietf.org>; Fri, 29 May 2020 11:42:09 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id v16so450442ljc.8 for <6man@ietf.org>; Fri, 29 May 2020 11:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T1ilJjQXnyc2kYjQ0yGXbSxFkk3X2zz8/KiibG6AtGs=; b=T0uiHiEQwwR46xmjbOGfLtpc9g2/0xsZNpYp22HPAieMqDIX0MAmph/nNQv2xs0Shz wDt1zjz7mFI7Ybd6m+5D8C93X/EAgCEbRRUW0a1qXTwkrBvUGVBR8moEHwZfTtwl+hzV R3csYvU7kl8IvKgPBaQtg9jBhLUGngXD8Vb9uXyYNzPe/t1cKgQXnFcPYtKB8UNEkUAx QcfxZxH4SiOHRC6qZqgyGT0RMsvEOViNEas4b4ELTnu2wNQ4Jk5WiWC7ZbBa69iwcTN5 CrouYznWwu9vYX8wasxxSYGIhFAf7+01kapzuwiKYZTEH9pckbklwuWWTDrjMyp9iicQ 3n6A==
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=T1ilJjQXnyc2kYjQ0yGXbSxFkk3X2zz8/KiibG6AtGs=; b=rE5eDih2Pwq/vEPsl60Qj3LaheXgncPlcB+Lrt9SHhKjyyG0Te9DQl59wKoSuvjOv8 qTlZDD9jVvqqfyd4g4MEWAw4csPPIiVFIL6vQRnGbMwvp5veTj5ZW3ny2oxe9NO/sCnR HLYQjE40LsAVO/6SfqYfCddLKh8CRc72UeGszee0/oz+mLj7sgxntAclhsK/e7TsJwa4 e4kgEmWHAA7HqQJPdnHo+0Ws3Y9lrado7iASrZoKitUffyA4q+mZGQd7BtnwNPxyRJJh s9a57se0l9Vwt2VMyAFdJih5B6rU1B/4zFpHJ0uoyc1twVvjNu2CuD23EKSEQJdBdkIf fEfQ==
X-Gm-Message-State: AOAM530IGdHAjnd84T/1iGlKnffjwWy2WWSFET0WEdnC37dZytrmS2xv 7Csm75yd8/a8JXa/pJNQj0k/89S6e+wEXXFKJrg=
X-Google-Smtp-Source: ABdhPJzilgQhvw6uzq2im/ckMiYVooSQEEYBj2HYcNBW8fyfihbDMXpfCqhZ3Pnv0MW11TzsdxKTBDsBD0RT9hsMrJ0=
X-Received: by 2002:a2e:a30c:: with SMTP id l12mr4969190lje.428.1590777725732; Fri, 29 May 2020 11:42:05 -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> <A19E5E27-EC4A-4B9C-BF05-4C62952CDAFF@nokia.com> <0F81A825-B235-40F4-9999-48BF9A77651D@nokia.com>
In-Reply-To: <0F81A825-B235-40F4-9999-48BF9A77651D@nokia.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 29 May 2020 11:41:54 -0700
Message-ID: <CA+RyBmWG=SSU5NauHvxqvX7RZqB0ryy-fyfO2TchSn9j2ZnyPA@mail.gmail.com>
Subject: Re: So where have all these new 6man WG people come from?
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
Cc: Andrew Alston <Andrew.Alston@liquidtelecom.com>, "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="000000000000424caa05a6cdcde6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lmMspqe5bzzb93rINdlthwlPbIk>
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 18:42:12 -0000

Hi Wim,
I would probably be troubled if IETF will start "choosing a champion" in
the technology field (not that I haven't noticed that being tried). I think
I'm more comfortable with "There're many ways to slice a bread" view and
IETF ensuring that it can be done in an interoperable way without breaking
other things around.

Regards,
Greg

On Thu, May 28, 2020 at 9:42 PM Henderickx, Wim (Nokia - BE/Antwerp) <
wim.henderickx@nokia.com> wrote:

> On top it would be a good signal from IETF to state this as it will help
> you get support for some vendors who don’t want to implement things. Trying
> to come up with a new protocol for the fact a vendor doesn’t support
> something I not good if there is a solution available. As such I believe it
> would be good that IETF brings this signal and does not adopt CRH for such
> scenario.
>
>
>
> My 2 cents.
>
>
>
> *From: *"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
> *Date: *Friday, 29 May 2020 at 06:33
> *To: *Andrew Alston <Andrew.Alston@liquidtelecom.com>om>, "Templin (US),
> Fred L" <Fred.L.Templin@boeing.com>om>, Brian E Carpenter <
> brian.e.carpenter@gmail.com>gt;, 6MAN <6man@ietf.org>
> *Subject: *Re: So where have all these new 6man WG people come from?
>
>
>
> Andrew, RFC8663 would do the job in the same way. On top you also will
> need to interwork with MPLS, so you have to do all kinds of mapping and
> encap with CRH to interwork with CRH. RFC8663 is a much better alternative
> for such environment
>
>
>
> *From: *ipv6 <ipv6-bounces@ietf.org> on behalf of Andrew Alston <
> Andrew.Alston@liquidtelecom.com>
> *Date: *Friday, 29 May 2020 at 02:41
> *To: *"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 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:
>
>
>
>    1. Relatively low end devices – but have sufficient forwarding
>    capacity to carry traffic between the metro nodes
>    2. 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
> --------------------------------------------------------------------
>