Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 27 April 2019 15:04 UTC

Return-Path: <adrian@olddog.co.uk>
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 86B4412027A; Sat, 27 Apr 2019 08:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 dDN9qdSz_EmS; Sat, 27 Apr 2019 08:04:24 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C127120195; Sat, 27 Apr 2019 08:04:24 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3RF4Kx7007164; Sat, 27 Apr 2019 16:04:20 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 56D2822044; Sat, 27 Apr 2019 16:04:20 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 417F022042; Sat, 27 Apr 2019 16:04:20 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3RF4GEE023858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Apr 2019 16:04:18 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Robert Raszuk' <rraszuk@gmail.com>
Cc: spring-chairs@ietf.org, 'SPRING WG' <spring@ietf.org>
References: <22596_1552502971_5C8950BB_22596_34_1_53C29892C857584299CBF5D05346208A48A18771@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <17228_1556107963_5CC052BB_17228_259_1_53C29892C857584299CBF5D05346208A48A90703@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <003c01d4fcdd$59e6b1d0$0db41570$@olddog.co.uk> <CA+b+ERmAe_Yp+g7dnVvM_NWJdo4GT+QBkeA-KD-dyybu8_qFew@mail.gmail.com>
In-Reply-To: <CA+b+ERmAe_Yp+g7dnVvM_NWJdo4GT+QBkeA-KD-dyybu8_qFew@mail.gmail.com>
Date: Sat, 27 Apr 2019 16:04:15 +0100
Organization: Old Dog Consulting
Message-ID: <006c01d4fd0a$7c868d00$7593a700$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01D4FD12.DE4AF500"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKiuZZ85wkSAmxndBno69hsKyy+2gKnS9woAZ3mRgkCHHBxEaSBkKVg
Content-Language: en-gb
X-Originating-IP: 87.112.228.68
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24578.000
X-TM-AS-Result: No--25.691-10.0-31-10
X-imss-scan-details: No--25.691-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24578.000
X-TMASE-Result: 10--25.691400-10.000000
X-TMASE-MatchedRID: hwsFDxVJcFnxIbpQ8BhdbOYAh37ZsBDC1kqyrcMalqWsafcFLFlU1OuD Mfic3iGlsl/Z/K9F5YfOUdXJKeWa6BxgewaS64+lxWVUEDiMVuXRahuPwaQ1Wrl+jVyLzmC75bW DW7fmAqGjkoEn/gUJLSWsmcr876eyjQyf9QArOhS3UCG/IQp2PpCobo6XQuiXWSw/UjSfbBKpUy ionL7As2sjvOI8vywNeYv9A31OZBS+/DppUgeV19OEZs/2oH3cbv16+gil4jdaW2Ktn+I8/gbl7 9j0a6cvLb+kQGWWixK2U3/zNNxM1nHMXURFxRSfKZFOaQbj6h/p8lxWp2elln/Lb02dPs4DERqB iXGj3g/PXLWRe+pCxb5D/wnFOv2OIW+cbD7Ubb1+H/Q3vgskAm2yXuVfuC5SzEiVVagx81bXrpd vf8fDg8j7UgEgBlpxe0HF0ouRBVhHW+94FA8JF8K1Ib9JAALxrogFtKd/P7eW+zaNLK605OygQW dkAVMs0Nt5/j+aSDEUI4s17Ql301mKiy1F9pgLQesjq8XPMbt3Bf9JIqsoeA8YwboCQc88TpCjy rDxEWtGfJ4XSK6qrqdCIx24gQ82CiwghyPO0y4SDAzxRL+lManvPLpXAU/WSwcZtVb90bADpLlZ JCSlu4RXPWBWtXbGikIrrhkh8x+7lpQUW6UvzyI9MxSOQ6CSLVEjAx3HjK6YI2SdJezB/7QREYZ m2yynNQtn/DQ9imA2dP5Jp+V/8ZcFdomgH0lnFEUknJ/kEl5ZDL1gLmoa/JiPn2g4sHYaYXlfnK 7BOiGQMyQxL0SO7eAdWb3yJgklWhkg9Gx8tMQWM99ewzOan+51dopjKlNb
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Zc_xhLU_LARW98RWzsVUZfzlq-A>
Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming
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: Sat, 27 Apr 2019 15:04:35 -0000

Hey Robert,

 

Thanks for your response, but I think you are not taking my requests at face value.

 

> I think you are on a very slippery slope here :) Hope you are

> double diamond skier ! 

 

As it happens. But perhaps that is not wholly relevant.

 

> With point you are making here you are questioning encoding of any

> information in the last octets of IPv6 address as it does not meet definition

> of the interface address. 

 

Am I questioning that, or am I pointing out that this is not consistent with current definitions and so it might be a good idea to get everything lined up and agreed.

 

> Well for one let's observe that interface can be both physical and logical

> entity and as such especially being a logical one can be tight with a 

> service switching vector in any network element. So even based on all

> IPv6 related RFCs you have quoted it does not violate any. 

 

This is certainly one way around the concern. If we define “interfaces to functions” (such as an interface to a VRF) then we may be done. That would be relatively easy to achieve with a simple section in the network programming draft.

 

> Then in one shot you are dismissing sound project like TeraStream

> or even recent pretty interesting proposals like draft-li-6man-service-

> aware-ipv6-network.

 

I am dismissing nothing. I am not even commenting on the technologies. I am seeking to get our document set to be consistent. 

 

> And if you look at 6man list you see that there was some discussion

> about this draft and no one questioned the point of potential "abuse"

> of semantics of IPv6 address as such.

 

Then (I assume) there is no issue to confirming this particular point and to getting all of the ducks lined up.

 

> Therefor till that happens I think there is nothing blocking SPRING to

> proceed with adoption of draft-filsfils-spring-srv6-network-programming. 

 

Maybe you missed Bruno’s post? The draft has already been adopted by the SPRING WG. There is no question of blocking that step. 

 

Just to repeat (since it has apparently been repeatedly missed in reading my emails on this topic, and was even the cause of some heat in a face-to-face conversation I had in Prague) I am not seeking to block anything. What I want to do is get everything aligned. I want to be sure that we have agreement early rather than having a “fight” late in the day when pressures will be more severe.

 

I simply don’t understand any reluctance to bring this discussion into the open and make sure we understand how the architectures and terminology line up.

 

Thanks,

Adrian