Re: [spring] Question about SRv6 Insert function

Suresh Krishnan <suresh.krishnan@gmail.com> Wed, 04 September 2019 03:58 UTC

Return-Path: <suresh.krishnan@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00212008A; Tue, 3 Sep 2019 20:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rjJUNN9wq0VL; Tue, 3 Sep 2019 20:58:48 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E60C1200C7; Tue, 3 Sep 2019 20:58:48 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id c9so6834226ybf.2; Tue, 03 Sep 2019 20:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LtwKQWrpzbn4W/oUVPe0xcxv4A8ZmHk7mrry+zpll4M=; b=XHNdnF/vhBlczi8GMbETlgqGLZ4pJx3A8SdgiaJh5F7iJ52bsJDTi4q223CTTycRj5 X0FGTfiBNdyWhbT5c74igWVrfXYo8fwXlGVgrxKpuaCL2MYQKLyLiD5Gzs+kii/7aowi i3S7oNFmOOfLF7Xqj2r9Lz1b3jdK6pr+WIklPorne8l97CZrUi12OH6yiFyCgx/p52hH O38MyFC5FwNjBJQvZj7yE48bNrNZhdeBZhUmKWQ7puPEEeUwT5u8nrMpB7tZdArGyVs+ sjANRpFnFNcaLyzMnHo9uIc3X1EWU3KJQpkdLCSA7oEkRRnXaG03NuwOEkLGAo7uuFx+ Ja5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LtwKQWrpzbn4W/oUVPe0xcxv4A8ZmHk7mrry+zpll4M=; b=WTGmiqrK+TK1rOhCcn/zfquQ+rccFCNnV6KSuC3g2OcIZs2xPj4L2ip2vOwrwIrk8C pFuW3LhMhLx2zgvXpRchiM8c3to03K8yEj3KDLnlwTEsO2nlgU85r2w1HB68uY/T9bWM O+L6PjF4vgZjCeqi9cSlcOu/afNBqMteCJtHEto+oqxO1WoDBwX+uSg5YjcfO5mPdQyH 1pWbrRiCUanfF/E6LojLEEhObXlR/t79TA9NBKZn0T+BqQPNrYpr5+IpQyhZi0i+VPJ+ ji5iI3wzmaqwEzrjkYLI6H2vJKmBPhyFFIubVA9LjgCMDYjHNsmdYQj2wJ61qKtoRUMZ mtew==
X-Gm-Message-State: APjAAAU7XmnL4POzFitCUImKxfLzEfvYrrHYN9rtWpYomoYFIrF0M/rC +G01iXVEP376laOdFv23vAc=
X-Google-Smtp-Source: APXvYqyh9Oub6qAyqs1MT/tbR3MBZ4xZcdwPLkwNLFbyApIpna6QGCGYIAyP2Ag4DxNhVDO7dox2gg==
X-Received: by 2002:a25:a2c1:: with SMTP id c1mr28106838ybn.177.1567569527546; Tue, 03 Sep 2019 20:58:47 -0700 (PDT)
Received: from [10.0.0.2] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id c80sm2056243ywa.3.2019.09.03.20.58.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Sep 2019 20:58:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Suresh Krishnan <suresh.krishnan@gmail.com>
In-Reply-To: <05b6474b-ecc2-fbf9-ac5e-d81157be8b90@gont.com.ar>
Date: Tue, 3 Sep 2019 23:58:45 -0400
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, li zhenqiang <li_zhenqiang@hotmail.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>, "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B24AF5C1-5AD9-400E-AD78-069D61563458@gmail.com>
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>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/zfr-dCuSHSJRjE2NkJbfjuWoCi4>
Subject: Re: [spring] Question about SRv6 Insert function
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 03:58:52 -0000

Hi Fernando,

> On Sep 3, 2019, at 10:50 PM, Fernando Gont <fernando@gont.com.ar> wrote:
> 
> On 4/9/19 05:23, Suresh Krishnan wrote:
>> Hi Fernando,
>> 
>>> On Sep 3, 2019, at 7:17 AM, Fernando Gont <fernando@gont.com.ar>
>>> wrote:
>>> 
>>> Hello, Suresh,
>>> 
>>> On 2/9/19 19:07, Suresh Krishnan wrote: [....]
> [....]
>>> 
>>> 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…)

Nothing official. This is one of the main reasons that we have IESG evaluation (to find any cross area issues). That said, nothing stops an AD from doing this as a WG participant in the other area, but the real question is whether the issue still exists when the document hits the IESG. 

Thanks
Suresh