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

Andrew Alston <> Fri, 29 May 2020 00:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2EA3A1027 for <>; Thu, 28 May 2020 17:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NfjmDgKZ00d7 for <>; Thu, 28 May 2020 17:41:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE50F3A1024 for <>; Thu, 28 May 2020 17:41:04 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-52-QYdUYhiAP9WEV6mVbktDaA-1; Fri, 29 May 2020 01:40:59 +0100
X-MC-Unique: QYdUYhiAP9WEV6mVbktDaA-1
Received: from (2603:10a6:803:bf::31) by (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 ([fe80::e433:d25a:4afe:ae67]) by ([fe80::e433:d25a:4afe:ae67%7]) with mapi id 15.20.3045.018; Fri, 29 May 2020 00:40:57 +0000
From: Andrew Alston <>
To: "Templin (US), Fred L" <>, Brian E Carpenter <>, 6MAN <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
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: <>
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:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; 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-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
Content-Type: multipart/alternative; boundary="_000_BCE8ACD848114CB6A80208DD8A9563B1liquidtelecomcom_"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



From: ipv6 <> on behalf of "Templin (US), Fred L" <>
Date: Friday, 29 May 2020 at 00:03
To: Brian E Carpenter <>om>, 6MAN <>
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:<>

Thanks - Fred

> -----Original Message-----
> From: ipv6 [] On Behalf Of Brian E Carpenter
> Sent: Thursday, May 28, 2020 1:40 PM
> To: 6MAN <>
> 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
> >
> > Administrative Requests:<>
> > --------------------------------------------------------------------
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:<>
> --------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests:<>