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

Andrew Alston <> Fri, 29 May 2020 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC9433A0888 for <>; Thu, 28 May 2020 22:43:33 -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 xH45LA7c4UfN for <>; Thu, 28 May 2020 22:43:30 -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 50AF03A0887 for <>; Thu, 28 May 2020 22:43:29 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-160-RnQdqQU3OsWj9bHm7GI1ew-1; Fri, 29 May 2020 06:43:23 +0100
X-MC-Unique: RnQdqQU3OsWj9bHm7GI1ew-1
Received: from (2603:10a6:803:bf::31) by (2603:10a6:803:66::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Fri, 29 May 2020 05:43:22 +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 05:43:22 +0000
From: Andrew Alston <>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <>, "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+eAIAADq4AgAAS70A=
Date: Fri, 29 May 2020 05:43:21 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2c0f:fe40:3:2:10d8:72bc:3c2:fafc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3cc9ef38-0067-4a93-bab9-08d8039332f0
x-ms-traffictypediagnostic: VI1PR03MB3935:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:2399;
x-forefront-prvs: 04180B6720
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: r0SpEfVAqIF+30IzhuJ231+mxUdaIZhUqSu+NNGIC2V6kT9kh7fCIFRCUxm0QQeXfG1UWPRbJ14WqSaasHB7eLb3E64bEIX5y9ozLIH15QjvQDuNF9DJFhAIxyZ3ZC27DFa+q4j3RerGHftRpBUeNi1YSfwxBGAR9Y7TAjMQrs/HotbMGt9WXbEWHBlMeOY4xEMnin1YUFZfJ7zFB4ewHI4Ho/PykRTcFIeJs84EzNUTQAqzQOAJkC/HJsY6PhO/4Ktw/iOUAWb2IBlVUXKJHy+yB6hD7X9lMTyI/ifAeHLoVv5muOLeTtNlHlzJi2j6dzMtyPksjqKiWW8iN+Nm/dInTR2ETRQ/RQExTXCewneylF2zBKzrO82EOH+u4FLKlG11TA3ZjN+BTFgAWZH5Sw==
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(346002)(376002)(366004)(396003)(71200400001)(8936002)(7696005)(2906002)(8676002)(296002)(53546011)(316002)(186003)(966005)(110136005)(55016002)(6506007)(478600001)(9686003)(66446008)(5660300002)(83380400001)(33656002)(76116006)(66574014)(66946007)(86362001)(64756008)(166002)(66476007)(52536014)(66556008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: JxLGCxuwdeAYinSsl9PDbWZLSH44MX1zln/Y1f7XDKvKn+HhlNjYIcZbos+SaWVDNuAT21ML0AdYg/QF+E0NjL5ImJmNbVFuAUsbqhUuE7FEODdmt+VhY/5NyqmzDBBPhFtuKQ/Ap2qivY423gDvWMGMN3/rIWYTp7h3CO96d8jyyywh8vuR8HNzrd2F5lG6fZlXVwZ38NfmDT8rTwPewhblNVBFUNwSrvPy2Dhkai6L4EgIEGJHWNeQviFWEonkMKOuD1Kpk4pUpnq7pBbqyPR27DNBrEaAOYvukrS/JWK5/+qwF/BM3w7Y5lQHUJNuHnD+glgh7Z/Jn7xgWu4VPP/9KXIutz1n5ZZP6tyP3/Tcj5S+9ByVKfywRSAuyDZrrqCMACO7RkpIr8XRTJLn0bs+okE0p8twYWl1NJzvNyVWDFxH1o3P2xqnC8UOTfuQDd7chuwOHRrtbMvPoNV71AYOpD/52nuxBJcfNtln63qbon2MfarQh6SJFcoLmVfB8JFF9qUpC/xjuGxKY54AVCJo+fttOmLhqu0HgkwhZiU=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cc9ef38-0067-4a93-bab9-08d8039332f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 05:43:22.1438 (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: VZ4ftq1fC58t4rGeyvkuLozK32pJfKLA2TFPwosRDu7LN/ARTtbwVbgP0rIaSnBiZMgZbNR4uXL1AW7DlWOxsPhe7d6xy6PBm6DYyD8BF54=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3935
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056C86FB130197145F119E6EE8F0VI1PR03MB5056eurp_"
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 05:43:34 -0000

Actually – I was expecting this reply.

And no – RFC8663 does NOT accomplish what I want.

With 8663 – tunnels have to be built – normally manually.  With CRH – I have to do precisely nothing, because the routing is done on the DA over the non-MPLS supporting nodes and its stock standard destination routing.
That means – balancing works – no need to build tunnels – no need to construct anything – its simpler, its easier and it saves me one hell of a lot of hassle.

I also point out that – we aren’t talking about one or two rings here – we can be talking about 20 -  30 -  40 rings.  So which one do I build my tunnels over?  With CRH – I don’t have to care.



From: Henderickx, Wim (Nokia - BE/Antwerp) <>
Sent: Friday, 29 May 2020 07:33
To: Andrew Alston <>om>; Templin (US), Fred L <>om>; Brian E Carpenter <>om>; 6MAN <>
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 <<>> on behalf of Andrew Alston <<>>
Date: Friday, 29 May 2020 at 02:41
To: "Templin (US), Fred L" <<>>, Brian E Carpenter <<>>, 6MAN <<>>
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:

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.



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