Re: Question about SRv6 Insert function
Ole Troan <otroan@employees.org> Thu, 05 September 2019 08:23 UTC
Return-Path: <otroan@employees.org>
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 CBE4C120B9A; Thu, 5 Sep 2019 01:23:11 -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, 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 JxKBRd2q23eQ; Thu, 5 Sep 2019 01:23:10 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326DD120058; Thu, 5 Sep 2019 01:23:10 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:c078:bc56:dd51:6a5d:33a8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id AF8D64E11A43; Thu, 5 Sep 2019 08:23:09 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C2CF41B8F99A; Thu, 5 Sep 2019 10:23:07 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Question about SRv6 Insert function
From: Ole Troan <otroan@employees.org>
In-Reply-To: <a7b5255b-8570-0e4b-da17-7557e7ca18c1@si6networks.com>
Date: Thu, 05 Sep 2019 10:23:07 +0200
Cc: Fernando Gont <fernando@gont.com.ar>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D971011-4B42-44F8-8BE0-5162DC1A3611@employees.org>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <18D85493-5FD4-4D26-B1A1-0931513DC847@gmail.com> <05b6474b-ecc2-fbf9-ac5e-d81157be8b90@gont.com.ar> <537C92D5-7355-45B5-8974-C74ED08B0E0F@employees.org> <a7b5255b-8570-0e4b-da17-7557e7ca18c1@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EwJMQ6suXQBvzDNaLzPN2WkmK-o>
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: Thu, 05 Sep 2019 08:23:12 -0000
Fernando, See my email to Ron. Just a short point with regards to your claim: "If you want to do it, the first step is to update RFC8200". Let's be clear that this is your own personal view and nothing more than that. Best regards, Ole > On 5 Sep 2019, at 02:34, Fernando Gont <fgont@si6networks.com> wrote: > > On 4/9/19 09:58, Ole Troan wrote: >> Fernando, >> >>>>> Since there have been plenty of attempts to do EH insertion or >>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has >>>>> had consensus that EH insertion is not allowed, I think it would be >>>>> bad, wastefull, tricky, and even dangerous to let a document go >>>>> through the whole publication process, and just rely on the AD to >>>>> keep the "DISCUSS" button pressed. >>>>> >>>>> Put another way: what'd be the rationale for having a draft-ietf >>>>> and have the corresponding wg ship the document with something that >>>>> clearly goes against IETF consensus, and that the relevant AD has >>>>> declared that wouldn't let pass? >>>> >>>> In short, this is not the case. I am *not* the relevant AD for the >>>> SRv6 Network Programming draft. If this document was in 6man I would >>>> have flagged it much earlier like I did for the SRH draft. >>> >>> Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for >>> the spec that's being violated". >>> >>> i.e., isn't there in the IETF process -- whether formal or informal -- >>> for this sort of thing to be flagged before documents get too far in the >>> publication process? ("Hey, this document in your area is actually >>> breaking a spec of one of my wgs" sort of thing...) >> >> I would prefer that we calmed down a bit on the protocol policing. > > Sorry, but this has nothing to do with protocol policing. It has to do > with respecting the consensus this wg and the ietf as a whole had on the > topic. i.e., that EHs must not be inserted in the network. > > We'd go into an interesting path to insanity if we publish specs, and > subsequently publish conflicting specs that simply ignore previous ietf > consensus. > > If folks want to do EH insertion, the #1 step is to publish a document > that updates RFC8200 such that the "EHs must not be inserted..." is > replaced with something else or eliminated. > > > >> We know that header insertion breaks unsuspecting source hosts if done by the network. >> It breaks (at least) PMTUD, ICMP errors and AH. >> >> What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal. > > That's what you and others may have said or thought. But the consensus > is what's in the standard (RFC8200). And the standard says that EHs > cannot be inserted in the network. If you want to do it, the first step > is to update RFC8200. > > > >> And some form of "doing on behalf of" is not necessarily problematic. > > It is rightaway problematic specs-wise when it violates a crystal-clear > requirement in RFC8200, that we arrived to after a very heated debate, > and lots of enegery and time from all the involved people. > > The fact that after all the long story behind publication of rfc8200 as > standard (and the ongoing srv6 document we're doing here, which was > adopted on the condition that it wouldn't do eh-insertion), we can live > with other wgs violating specs that we produced here with so much effort > and time, is kind of amusing. > > If folks want to allow EH-insertion (i.e., formally allowing middleboxes > to fiddle with packets), RFC8200 should be updated, and the work should > be done in 6man. > > I don't think it's SPRING's call how the IPv6 protocol works. > > > >> It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds. >> >> Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text. > > My #1 concern (not that I don't have others) is one related to fairness > of the standardization process. I don't think we should simply > rubberstamp anything a big vendor wants to sell, no matter how big the > vendor is, or how much money may be involved. > > And if this working group (and the IETF as a whole) published a spec on > which there was consensus, ignoring the spec and doing whatever one > pleases is not the way to go. Firstly, make e the case for updating > RFC8200. Then come up with the proposal to fiddle with packets in the > network. > > P.S.: I've never been into the camp of protecting X (whether rfc8200 or > any other document) as if it was religious text. Quite ironically, I > have experienced such religious opposition in 6man itself (for instance, > your argument of "don't fix slaac-renumbering because ipv6 has not been > designed to support flash renumbering" seems pretty much a religious > argument against work that would not result in any major modifications > to any of the protocols involved -- as opposed to EH insertion). > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- Question about SRv6 Insert function li zhenqiang
- Re: Question about SRv6 Insert function Ole Troan
- RE: Question about SRv6 Insert function Ron Bonica
- Re: Question about SRv6 Insert function Mark Smith
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Re: Question about SRv6 Insert function li zhenqiang
- Re: RE: Question about SRv6 Insert function li zhenqiang
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Ca By
- RE: Question about SRv6 Insert function Ron Bonica
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Behcet Sarikaya
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Ole Troan
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Ole Troan
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Alexander Vainshtein
- Re: Re: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: Re: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: Re: [spring] Question about SRv6 Insert funct… Robert Raszuk
- Re: Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Andrew Alston
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Andrew Alston
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Ole Troan
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: RE: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: [spring] Question about SRv6 Insert function Brian E Carpenter
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Mark Smith
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Brian E Carpenter
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- SRH scratch space (was Re: [spring] Question abou… Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Mark Smith
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Mark Smith
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Bob Hinden
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Bob Hinden
- Re: [spring] SRH scratch space (was Re: Question … Brian E Carpenter
- RE: [spring] SRH scratch space (was Re: Question … Xiejingrong (Jingrong)
- Re: [spring] SRH scratch space (was Re: Question … Alexandre Petrescu
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] Question about SRv6 Insert function Pablo Camarillo (pcamaril)
- Re: [spring] Question about SRv6 Insert function Pablo Camarillo (pcamaril)
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] SRH scratch space (was Re: Question … Gyan Mishra
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu