Re: [spring] Question about SRv6 Insert function

Ron Bonica <rbonica@juniper.net> Fri, 06 September 2019 00:09 UTC

Return-Path: <rbonica@juniper.net>
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 AAD8A120043; Thu, 5 Sep 2019 17:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 YvqYPysVe6e3; Thu, 5 Sep 2019 17:09:41 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 03D1612002E; Thu, 5 Sep 2019 17:09:40 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8609cjl030614; Thu, 5 Sep 2019 17:09:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=TPiAdIReW0x1r+TiK9ia6p+u8TaEpN37f8iMYRtXdzA=; b=CvUQI/ImmPsKhX9G5lLKpjE2D83GdwNIAr8OFetPrHC9+qGrRPqBq+hFYidG9rw1g0oe r+zLhFylMLA7rDFn1eAhBtTy5U2AL8ftyW5/+gOn2eBRoj7AQ1OkkDJsjoEsrIOBhIZ9 eqW9/OX/u9+FM2hXa9caapjNyHQb6HMugR6zD0JzBnUlvthVP6bo5zYuJAJxQQpKqE5m o5Q95ZhM79h319Be/G3SaOaKHSHooWacQbswgNiu1X4+Bs2yAawSwXii4IIMpSZAjIHK x72eWqTBaLgYy2qsde4BcpxDY5SwhTk9tS8xAwiVuYIHykbyN47ksKRmukcubiWBeR2H uA==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2055.outbound.protection.outlook.com [104.47.33.55]) by mx0a-00273201.pphosted.com with ESMTP id 2utrcy2fc2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 17:09:38 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hRlIsIOne0P3vPlppJBegmW2rmoSCqwW5smvnGsOfrpboxeZk9RupQYcoy3c6FcTr0WnPPzU5SdqAVtBBIPGmrnvPgUaBwESYZoCNPHYOxWLI6M9zGL7jFGWdc8TQrmU2oa6wtY0QwEI3Esx9bBzZCCmXu+jjUQog0yZ1RaRKtbmGs83PlGBQZ8wQlvXtum6GarE19fP2olDqoeSNtSO1c7AJjSivCCPbiZoZEz+9ChoyB80oAJlFJYi2jXHd4el56VTk4VjWp1XbHV7GGB6dZtaVohAgm/bar9QjWSF2RrHyFn8hrmoGnCvsJUCqQRtCaN935dErGzjBlsMznWu9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TPiAdIReW0x1r+TiK9ia6p+u8TaEpN37f8iMYRtXdzA=; b=QLQ5OzhtGdAQJ2bgsbMNVAioXcI14rxa5qBwPCtnTpIK1WH+2HYnOPN3hILBoLR02d3u1nB2MzhC0Ec/Oq2THpEzJPdJDlmHOp8qAnLIsAxBPSStd3hZTRxD9bF9EUx24usaqOd9/OBhai8Xg7O3yifYYJ03cXe7uQhf7AcTXuWyzegW73r2wa0SrVVMIYPrXnj2lM7xp5sFW77JuryRV/Bjxsxa6R2rJg3vVSXYVyu2nKcbf55WzZ9eXfVXyZ+gC/mMNmgJrZcgcOjF2JOR8SuoMCqLYyJdVPsNkN1kTJfwVi1IHfn0jc4k0wPRb6wsS5/01cOjek91koqALSg3hw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from BYAPR05MB5463.namprd05.prod.outlook.com (20.177.185.144) by BYAPR05MB5799.namprd05.prod.outlook.com (20.178.49.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.5; Fri, 6 Sep 2019 00:09:27 +0000
Received: from BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a]) by BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a%4]) with mapi id 15.20.2263.005; Fri, 6 Sep 2019 00:09:27 +0000
From: Ron Bonica <rbonica@juniper.net>
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>, Fernando Gont <fgont@si6networks.com>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: [spring] Question about SRv6 Insert function
Thread-Index: AQHVYaiGkQrPBxFhV02Y8RCTv8yVq6cZzxWAgANe64CAAAKegIAAVJCAgABDXXA=
Content-Class:
Date: Fri, 6 Sep 2019 00:09:27 +0000
Message-ID: <BYAPR05MB546363BF8D7D1EC848EB3103AEBA0@BYAPR05MB5463.namprd05.prod.outlook.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> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <b83a7060-0517-c6ad-f6b0-bc9e61e4667f@si6networks.com> <A6FA74AC-F349-4F01-A86A-949870134779@cisco.com>
In-Reply-To: <A6FA74AC-F349-4F01-A86A-949870134779@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-09-06T00:09:25.9008551Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=7eb14d8c-5aad-4e56-b41f-8f0d50602a7b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6a9544ee-67eb-4be0-d67e-08d7325e7b91
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB5799;
x-ms-traffictypediagnostic: BYAPR05MB5799:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BYAPR05MB5799DCBF8477E8FB49DF468FAEBA0@BYAPR05MB5799.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(199004)(189003)(13464003)(54906003)(7696005)(2906002)(14444005)(256004)(25786009)(76116006)(99286004)(66446008)(66476007)(66946007)(64756008)(66556008)(6436002)(110136005)(229853002)(33656002)(71200400001)(316002)(71190400001)(478600001)(86362001)(486006)(11346002)(446003)(8936002)(14454004)(66066001)(81156014)(8676002)(26005)(476003)(186003)(5660300002)(81166006)(966005)(4326008)(55016002)(3846002)(6246003)(6306002)(53936002)(9686003)(305945005)(102836004)(74316002)(66574012)(7736002)(6116002)(6506007)(53546011)(76176011)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5799; H:BYAPR05MB5463.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: vob6UHn4qu79DqZA//7yLBdJvpwInrgX1woQUvn0nA2PJRC2EQNEXO3eQE0DFr7FiUx3uXuYj7jQZRLxbZ/xEkWaKDSZc1nyZO1IePgSrtnTIXYB/jx7bUI6o1N4PJBi66A7CdJzFyXA4NNzlSuM0aT3q+25vOmXo/wGJy9USPwJ0WRw93MwxTN/qkJRUchySn8DTdFKHNZWmdGHQORoBvIp6KuU67il+0PpQOyFZ6TCbcaU4pAub5YRf9aH2aOKILw+vumGztTTAgc5d+C3DxrUzjhWyCPeb4J9MkDtwHl5lZcsUhvYzN/u3fV3leM5UotoBewSs4xs4aBQI9XkWj/9GHuVQcVrFlKWpkEGacsrDZejGuxTJL+B1b4n8SP2b+ku8mCZwbaZ7AgZ/WEsxUdMLn/+2phb6bD5MrEzzIc=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a9544ee-67eb-4be0-d67e-08d7325e7b91
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 00:09:27.3686 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4ikK7IdV8312PgfpTMlkV0oyL4e7kiZ+Ufw8b2bcxCbFZ9fQyIgLZvv94ZCS9ciO4kp0fMZWVfvdoD9D8GvQ/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5799
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_11:2019-09-04,2019-09-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 spamscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909060000
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/47n8xNhLvKwKtSdKqh61fyoGIXY>
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: Fri, 06 Sep 2019 00:09:44 -0000

Darren,

Your comment, and the discussion that elicited it, are very helpful. They remind us that draft-ietf-spring-network-programming are far from maturity. If the END.B6.INSERT and END.B6.INSERT.RED SIDs are to survive, draft-voyer-6man-extension-header-insertion must progress ahead of it.

And if neither END.B6.INSERT nor END.B6.INSERT.RED survive, one would wonder the PSP and USP flavors of the END and END.X are still needed.

These are among the many issues that merit discussion. 


                                                                            Ron

"All who wander are not lost." - J.R.R. Tolkien



                                     


Juniper Business Use Only

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, September 5, 2019 3:58 PM
To: Fernando Gont <fgont@si6networks.com>
Cc: spring@ietf.org; 6man@ietf.org
Subject: Re: [spring] Question about SRv6 Insert function

Hey Fernando, since you’re lost, here are some more waypoints to help you find your way ;)

- draft-ietf-spring-srv6-network-programming mentions SRH insertion in only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and all insert variants have an encapsulation variant defined.

- At IETF 101, the 6man WG confirmed that SRH insertion must be worked on before draft-ietf-spring-srv6-network-programming can progress to RFC - i.e. there are not surprises anywhere.

- draft-ietf-spring-srv6-network-programming added a normative reference to draft-voyer-6man-extension-header-insertion to document that fact.

Darren

> On Sep 5, 2019, at 10:55 AM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 5/9/19 17:46, bruno.decraene@orange.com wrote:
>> Fernando,
>> 
>> 
>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando 
>>> Gont
>>> Sent: Tuesday, September 3, 2019 1:18 PM
>>> 
>>> Hello, Suresh,
>>> 
>>> On 2/9/19 19:07, Suresh Krishnan wrote:
>>> [....]
>>>>>> So, we should probably explore the motivation for Option 2). If 
>>>>>> the motivation is not sufficient, we should probably standardize on Option 1.
>>>>> 
>>>>> My argument would be:
>>>>> Folks would do whatever they please with 1). If somehow they feel 
>>>>> the need to do 2), they should *refrain from even suggesting it*, 
>>>>> post an internet draft that proposes to update RFC8200 to allow 
>>>>> for the insertion of EHs, wait for that to be adopted and 
>>>>> published, and only then suggest to do EH insertion.
>>>> 
>>>> I have put down my thoughts on the future of header insertion work 
>>>> in a mail to the 6man list in May 2017. The mail can be found below
>>>> 
>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/i
>>>> pv6/4MevopH9_iQglUizhoT5Rl-TjRc__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0
>>>> hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzf2MV0sH$
>>> 
>>> This seems e bit misleading. What I would expect is that before any 
>>> work is published on EH-insertion, the IPv6 standard is updated to 
>>> allow for EH insertion. (plese see bellow)
>>> 
>>> 
>>> 
>>> 
>>>>> P.S.: Given the amount of discussion there has been on this topic 
>>>>> in the context of RFC8200, I'd like to hope that there's no 
>>>>> draft-ietf document suggesting EH-insertion or, if there is, the 
>>>>> relevant ADs and chairs make sure that's not the case anymore.
>>>> 
>>>> Yes. If a draft violates RFC8200 and it hits the IESG for 
>>>> evaluation, I will certainly hold a DISCUSS position until the violations are fixed.
>>> 
>>> 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.
>> 
>> draft-ietf-spring-srv6-network-programming has a normative reference 
>> to [I-D.voyer-6man-extension-header-insertion]
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-sp
>> ring-srv6-network-programming-01*section-13.1__;Iw!8WoA6RjC81c!Q1FacH
>> EtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzWANflGD$
>> 
>> As such, from a process standpoint, it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be itself published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG. So I don't think that we can say that it "just rely on the AD to keep the "DISCUSS" button pressed."
>> 
>> In my mind, this should also be a clear indication that the question of header insertion is (to be) within the control of the 6MAN WG. But you may have a different opinion.
> 
> Maybe my mental algorithm has a bug, but: what's the point of spring 
> working on a document that relies on something that 6man has so far 
> rejected?
> 
> You spend energy on the document and then... just sit on the I-D to 
> see if 6man adopts voyer-6man-extension-header-insertion? Ship the 
> document to the IESG for them to review? -- I'm lost, sorry.
> 
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDO
> HPUJzZjOoys5$

_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzZjOoys5$