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

Robert Raszuk <robert@raszuk.net> Fri, 29 May 2020 07:55 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 1A8C03A0C81 for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 00:55:27 -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 o1-RPPvy1kTW for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 00:55:24 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 70B383A0A63 for <6man@ietf.org>; Fri, 29 May 2020 00:55:24 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id e2so1113834eje.13 for <6man@ietf.org>; Fri, 29 May 2020 00:55:24 -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=8NHMUs1oLb6ipIleyy6gJImM5ACVX3IP4Wo7YFT2hAc=; b=YHiQH0gyExOe5f/XtZpZbCI0dQdgnA9KSetWS7MYcIOTh0IWcEjSxZtIdyUsOmqBT5 qVwFq4IQq8jhOGqPTn9C/UV6WltlMs7ptelcLb0FnRzJlIh5c2CHdySAfAbUDpsbMTV+ 4zSxotio24JZYWFbkbkucF25w0hlpk6/mmOR2uBpj2jcx/fMVt0+oMEWVWrCacckuoIV eta7Tb4hEaivOFYosonkF7IHepS1D7pVD6hI1ySWM4FPuiMoYy10BxY/2KRtlBAklaS3 iOxkYXMFsEOWmmW2StGRsO3mRUh0kGSWxea9ANxY9m0TVBv83Y62C4LS4S6qa/xfpQlq VSkg==
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=8NHMUs1oLb6ipIleyy6gJImM5ACVX3IP4Wo7YFT2hAc=; b=ZFKyKN0lHaDo1xSDJh9jLXrZw/54rAW5JW8xHsuKqIgcdwq3ODb8b8O4/8lSz/kY2n ZDCDjpuPh/PmX5tmwufgo6Ow+cPlqb3to8eicoZWCSxluhCM6/3a1uqd9d1qXULgxj36 ihPFIVNpKYbs/yOt5Nwe6ia6hf7EgkFPujWcMkHpTt3+L+Jc6ieMwxg/7YYsW2myRm39 HfqAVNhBYrIPySG12hSEdbYao/NcSP2Yu6+kZ/Em6YRJWaYlKyiUOoY7KWM4cb+NXyga GDakD7XN0cF3gVUGpqzx/ePgAnJTInohw/eUxQVmyZqaKbrm941Bk6u0QgX2aEI0YrLh 5VMQ==
X-Gm-Message-State: AOAM532eYT3ZsysiW7+krAFQoylQ/SuNEkRYQa4P6r6xlJanQQnQ0VC7 kd2EL4Spuksbit2O/Hl+aUyc7VlvQh8Es2RHNZsEuQ==
X-Google-Smtp-Source: ABdhPJzs/qZ4hVrVwg5l1krNXWtjifKoiFq4VyAg6kZbXrnxoWBs4Zq+8CPY6N2s4rW08eHPfpc+n79QKkX15lDHPwo=
X-Received: by 2002:a17:906:17d1:: with SMTP id u17mr6399904eje.242.1590738921212; Fri, 29 May 2020 00:55:21 -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>
In-Reply-To: <BCE8ACD8-4811-4CB6-A802-08DD8A9563B1@liquidtelecom.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 29 May 2020 09:55:13 +0200
Message-ID: <CAOj+MMFR37NOSkfnT5ZUMDbtT3OKduh+DmQyi3bBsAvMsN7aYw@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="00000000000054637e05a6c4c469"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EaX6vDlBYQ2-M5_hCQbHhYOHPmU>
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 07:55:27 -0000

>  – 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:
>
>
>
>    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
> --------------------------------------------------------------------
>