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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Fri, 29 May 2020 00:41 UTC

Return-Path: <andrew.alston@liquidtelecom.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 7E2EA3A1027 for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 17:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NfjmDgKZ00d7 for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 17:41:05 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE50F3A1024 for <6man@ietf.org>; Thu, 28 May 2020 17:41:04 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2168.outbound.protection.outlook.com [104.47.17.168]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-52-QYdUYhiAP9WEV6mVbktDaA-1; Fri, 29 May 2020 01:40:59 +0100
X-MC-Unique: QYdUYhiAP9WEV6mVbktDaA-1
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB4592.eurprd03.prod.outlook.com (2603:10a6:803:59::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Fri, 29 May 2020 00:40:57 +0000
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::e433:d25a:4afe:ae67]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::e433:d25a:4afe:ae67%7]) with mapi id 15.20.3045.018; Fri, 29 May 2020 00:40:57 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
Subject: Re: So where have all these new 6man WG people come from?
Thread-Topic: So where have all these new 6man WG people come from?
Thread-Index: AQHWNOJ5uH0AW1F/m0mmBNFYcFLc3ai99nwAgAAGDACAAG+eAA==
Date: Fri, 29 May 2020 00:40:56 +0000
Message-ID: <BCE8ACD8-4811-4CB6-A802-08DD8A9563B1@liquidtelecom.com>
References: <CAO42Z2xDygUXTGwVunGSTMkZGMF8VePrPaXLSAJg14vAJdca5A@mail.gmail.com> <44595462-bef1-c1e9-5aed-f7a296bcac9e@gmail.com> <40f65b9fe1ee47168c59336b4415718b@boeing.com>
In-Reply-To: <40f65b9fe1ee47168c59336b4415718b@boeing.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-originating-ip: [2c0f:fe40:3:3:a0a9:cf99:d78c:dff0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 953a8b6d-df80-45c6-adf2-08d80368f386
x-ms-traffictypediagnostic: VI1PR03MB4592:
x-microsoft-antispam-prvs: <VI1PR03MB4592378F2E82571BBB22096DEE8F0@VI1PR03MB4592.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 04180B6720
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Xsly8w5dfpu8QRPowbSWsTpa41PEm8f6B8UJhywpFypL0aRfRKl6BYsJzZYfZ8voME0SWiEa0P1Uq1vWc+fEuLkUELCFxJrY/z+MpQ2/XU2M+v/WIwWn0bLKetu0Yi0sDPgoR5XWg4oP46SeEQYFCoRHv+EiCE6RcjLe2xyhHEw1bEm2yekA8zcM1sIGidwX0M0N6lX5TQd1BZH9YNgu2oKWZCnC+DUka01QZPimeN7qH0I+ZnJEBiMFZpbOt1ld58uFX9azgyJKA9tuWFcnDhNLGFaYJuZgkpVP/vDyP+EqyczTbHYciFriu+eMyo2Y8AfsQVmRCNpT7gIJhjTvw8hVfWmIwPtEaaf7jID15HD9OggRNJx6myHQwAKMSZgjla7AvWQ3l0E1LyPZM4lDhQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(396003)(136003)(366004)(376002)(33656002)(66946007)(71200400001)(2906002)(36756003)(66574014)(166002)(2616005)(110136005)(5660300002)(6512007)(316002)(83380400001)(966005)(86362001)(53546011)(6486002)(64756008)(186003)(66556008)(76116006)(91956017)(66476007)(66446008)(8936002)(6506007)(478600001)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: fjIPt48KDe2hIgFQfnn9vTmB56eai1gxrEB035/0vFdgXagEY44SO7PRbqZLvXtDaN9mR4KYg88tJaG/lIfGO2SPQ5OM+1sacztDvDVvKR1MMtIZUe4xWbjcPPGTsdsqfJsiASJKJUn2mS8eJZxdLxIWC3KnRDxyq+8dcP6QhrfKtplY2bZX6DUKkvyQvQzQiUXzCS6KPNhS+6aMBcO4gY1kRi2AG0JuK/CPBtcD3pdx/OXAKd6+FvLD566MlSd/wblLqpf88elj4Mrc8+uRqTF/rH3vYZo6FMNtn+u4lJo/OlwWlnGbVrQnEINtueUzZWvzsDAv1Ayo/u0GZUryP3cvFCijwN1a8wzm2KPyiT/qq2YTuGo0ZH2LUFJ0wioO1dQm3mr39cQ/Q8OFJdYpHToYtrMyC2gj0S3LAzBv2gpPtGIBn1O5ZnKIsOZoJNkhrTeCI3lMrEA1Ln2Kt9h0F5B8eQ69ofPV1U0t06F0EPun34teKoWaTL4UoO6whHfB6ZoFwC0LlDogtYRoh2OolGQ2K89jXcSu6RYdp1ni3ts=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 953a8b6d-df80-45c6-adf2-08d80368f386
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 00:40:56.9257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cO8wGPZAS//v4coGM30q/UBdnaQcHQ3zNgiSNw4JJtEya2328/wET2SaewNBTtBAvKDIb2/5NFW6jAO/prTTLC9nhhAm7VC5DR7ucFfunoc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4592
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_BCE8ACD848114CB6A80208DD8A9563B1liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rnwHABIr7pmFugpAMwaVD5D7L74>
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 00:41:08 -0000

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/<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<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<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<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------