RE: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Andrew Alston <Andrew.Alston@liquidtelecom.com> Fri, 15 May 2020 13:16 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 968AF3A09DF for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 06:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 iid1TwH18zfw for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 06:16:18 -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 8ECAF3A09DA for <6man@ietf.org>; Fri, 15 May 2020 06:16:17 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp2057.outbound.protection.outlook.com [104.47.5.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-169-nx-qUfUiOjSMKl1AanS7Sg-1; Fri, 15 May 2020 14:15:07 +0100
X-MC-Unique: nx-qUfUiOjSMKl1AanS7Sg-1
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB6544.eurprd03.prod.outlook.com (2603:10a6:800:19c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30; Fri, 15 May 2020 13:15:05 +0000
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49%4]) with mapi id 15.20.3000.022; Fri, 15 May 2020 13:15:05 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Thread-Topic: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Thread-Index: AQHWKWFY0VQmWjGYlU+/A/V3kQssZqipHQYAgAADTmA=
Date: Fri, 15 May 2020 13:15:05 +0000
Message-ID: <VI1PR03MB5056A666FC51F1720527697DEEBD0@VI1PR03MB5056.eurprd03.prod.outlook.com>
References: <DM6PR05MB6348E9AD1E088792C2F10BB4AEBF0@DM6PR05MB6348.namprd05.prod.outlook.com> <8CC3F837-B4D6-4570-AF2F-37041839F391@employees.org> <21E9A957-1A31-4A11-8E78-5F7E382866D4@juniper.net> <48606063-622D-4A59-9A80-65C459F494BF@cisco.com>
In-Reply-To: <48606063-622D-4A59-9A80-65C459F494BF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2c0f:fe40:3:2:3102:61b9:c849:7ad6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f5629bc1-e44e-4a15-d7a4-08d7f8d1fc27
x-ms-traffictypediagnostic: VI1PR03MB6544:
x-microsoft-antispam-prvs: <VI1PR03MB65445F7B9C23741EE4DB4280EEBD0@VI1PR03MB6544.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04041A2886
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QLgYxODXVfmG03L6rbC8rP7K4NTQ9Oo5w1kHVTKLpg8vJS36uUXZ3gGYJ19T2OAvl5/awxjKdk6D8N2cy5uJvaaf2wr5rJh2en01Sx8BzDR5PfnBVi0At1SM9vfNpGSS8/lSSJM1F+OzWh5/40I3r0f/B9irj2lYp7Qx4f41mICaFnmvpItAG1UauGfrFvKkUsnWVb+0l4ybH29z6fIRQSzsGJxYgd+ZwrxLa2knhlbbfBhv1CwPX5R6vFDjl7a+lkqG6OyTwgHG+7+whtm/j+kMKxSKSATtPfS4NHajPkNnhehbL4K9UcdkoiiZfbB05BmWpZkYWVQgmmaJB2NHM3T/zlTHfZy0VJHVdBlL0Kba7EyD9659kIXWgSR8u7Ut5QgSFM/6gOeQegCbZ01p0DPHbRN3Z7HLtaypbdoeYUOvnegNlEx8RQET/J22C7ceI6YgaD4bjR7liMMSsXfkLw9ILJFo3lU4knU9EmEIci0YFjR/YkdLhkj0v2Tjn8bLVyh653/rSEvh7NweephchA==
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)(366004)(376002)(396003)(346002)(39860400002)(136003)(66446008)(110136005)(54906003)(8676002)(316002)(6506007)(8936002)(5660300002)(33656002)(186003)(53546011)(7696005)(76116006)(66946007)(166002)(71200400001)(86362001)(64756008)(478600001)(2906002)(66476007)(4326008)(52536014)(55016002)(9686003)(966005)(66556008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: WYNQDq4NgIa7RPciAnSWQkhrezHXaWCyXiTEXA6vcEjyYKLc/D7BXqZvcTJBu+36Z0mB1quACtFqe1P0ei+s+jpXPcQeWy8lU97mnHcu4KTPfkDzVqcKnPV0BecA0eC8L+jqxLLHbKTyqQURZHang+VZMlc+TQ4W2c/N2V1wXXd3E4DwGkJSEgxg6R/2CJiEMNabtKYfhryvNK9IzQN4kPNRcNRE8qB+RuV+MZmPqFCl10fQIxWcskntAhnlPrCZa8O/F9bJ3uLguj+bzJ9AnWtsT0L9TsOSVsYmv/9c9rGPVuVyNOLM4SK80cnvrpaEAnQuOcoX7y4FYXPbnSxrBln2ikOcO0H69G8bUVy9FobWtSF71ylMUhwf6/FZlt/e26JYbNIZ99cAYMcyX1/ACFBuRWdRlmZ0A6zoqwAoHmJdFj8qmR/iAFDh7zSn0Imj53f1RkjB5Vn2IrEUDZCPsVBqARmtr63diOBVr7mM/5UZHsbLj7VlehUenuto5aEEXgZqwHJoAdtYAyIKAhB6ndMOEdGqS3Hr+E5PmuYfGnQ=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f5629bc1-e44e-4a15-d7a4-08d7f8d1fc27
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 13:15:05.7188 (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: fFk5vg6B5fhpMCs4iSFooUjc1rpLM8TSlkpZJZ0WGK5hEMNbjqPnR/xSu9IgZn3RHqaFNbwHcbToVLCwQk/Drcd75Ql0XnMEvtHfy+fTRqI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6544
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056A666FC51F1720527697DEEBD0VI1PR03MB5056eurp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hrPUF1iaaHD9fdzIBlNNkm-29CA>
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, 15 May 2020 13:16:21 -0000

Zafar,

Let me give another perspective on this.

In Montreal – people screamed – no use case – a use case was provided – and for months after – people kept screaming – no use case – until they couldn’t scream it anymore because the mails showed clearly that use cases had been supplied
Then – we moved onto the “We need an architecture” – and you yourself misquoted a participant in 6man claiming they demanded an architecture – when they clearly didn’t – see the interim meeting minutes – and when it was claimed that this is a building block –
It became – omg its an rh0 replacement – and pick on that aspect of it.

(Those last 2 might be in different orders)

Then – there was this bizarre claim that a vendor “wanted” something despite the fact that they hadn’t said it.

What I can say is – rather that come with technical arguments against it – what I am seeing is smoke and mirrors – pulling things out of thing air – twisting words – trying to mis-portray things – and the only reason for that is – because there are no solid technical arguments against it.  I am SHOCKED that more people cannot see the smoke and mirrors and twisting of words going on here.

Because from my perspective – when someone runs out of ideas – they start making things up out of thin air – one after another – please – see my earlier email about obstruction and how its not helping any of us.

Lets debate the document on technical merits – what are your direct technical arguments against this – or are we continue to continue with misdirection?

Andrew


From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Zafar Ali (zali)
Sent: Friday, 15 May 2020 15:54
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>; 6man-chairs@ietf.org
Cc: spring@ietf.org; 6man@ietf.org
Subject: Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

Hi John,

You’ll recall what the 6man chairs said in Montreal and Singapore regarding CRH:

During Spring session [1]:  
“[Bob Hinden]  As 6man co-chair, would like to understand whether SPRING is interested in this work.”

Bob reiterated the same message during Singapore IETF [https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/>]
“Regarding the Spring related drafts … <snip> We did not see very much value in also discussing them in 6man.   Once items have been adopted in Spring, we think it is appropriate to adopt the IPv6 relevant parts, but that’s not yet the case now.”

Nothing has changed w.r.t. the competing solution review in Spring since Singapore.

Instead of following the chair’s direction, in Feb 2020 the authors of CRH just simply removed normative reference to the SRm6 to get 6man adopt CRH ahead of SPRING compression discussion..

To achieve the said goal, the authors of CRH draft first positioned it as a replacement of RH0.
Now RH0 has been removed from CRH draft.
There is no longer any architecture and use-case to justify adoption call for CRH.

It is clear to all that the current draft and adoption request is an attempt to circumvent the standard practice.

Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00<https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00>
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+       (10:44)

Thanks

Regards … Zafar

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:jgs=40juniper.net@dmarc.ietf.org>>
Date: Wednesday, May 13, 2020 at 4:02 PM
To: "6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>" <6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>>
Cc: "6man@ietf.org<mailto:6man@ietf.org>" <6man@ietf.org<mailto:6man@ietf.org>>
Subject: Adoption call criteria for CRH? [was: Re: CRH and RH0]

I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?

It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?

I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:

Bob: Thank you Ron. I think it's too early for adoption call.

Ron: What is needed to get to adoption call.

Bob: I can't answer right now.

Ron: Can I ask on list?

Bob: OK.

Ole: Related to what's going on in spring.

Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.

Regarding the SPRING-related process stuff:

I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]

But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?

Regarding the more general “what is CRH for anyway” stuff:

This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?

Thanks,

—John

[1] https://cuberule.com<https://cuberule.com>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------