RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Ron Bonica <rbonica@juniper.net> Thu, 27 February 2020 18:39 UTC

Return-Path: <rbonica@juniper.net>
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 84EA13A053F; Thu, 27 Feb 2020 10:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=juniper.net header.b=nnC3k+m9; dkim=pass (1024-bit key) header.d=juniper.net header.b=Pyiomt/R
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 xt0tWekHRqvh; Thu, 27 Feb 2020 10:39:29 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 BDD353A046A; Thu, 27 Feb 2020 10:39:28 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01RIW6LS012613; Thu, 27 Feb 2020 10:38:08 -0800
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 : mime-version; s=PPS1017; bh=W/9kVJrN0F3RqjPyO/mivva22PCIdND9SjG+0CY6qKI=; b=nnC3k+m92TPkn/Q+ZhZNkJN63M9W+wY7TfXPHHjWzATduG/rSvtI7h2bBwwWT5WExztf C8doh1nORVGHso/nijEdbDKX7AeCWBMJMLN0qBwbbyM9x2nBDMHCrb7VBjzSjyw9Zze1 lJjZqDZco1JMgwTLSN9w6IaKEAGaAjNxTwciMuRNf474Va8qALd/f8C8ykZaUA281BLx EKoX0KkMZF3JITAEaDvvlts0ZsBcctjfKzK1qKAZwPHLYpMLyV0U+ysvFace5PH9HWQy Sc0Nv5yPY0RiRi65VrNqW5T3fq4gWeyO9INCdI+iPcUuc9EdpiX1WhN4orfoY/DW3DRX LQ==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2104.outbound.protection.outlook.com [104.47.58.104]) by mx0b-00273201.pphosted.com with ESMTP id 2yean99125-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Feb 2020 10:38:08 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P0bsHVYKWmHmQjQB5oI15TevInqRW0sUdOJKgjhrwEdy95/5eLQx5Ke/W4xcOEorEDv1DE5sLI3lhAk/4cB1GaEeny3BMBNRFDl3yrEfUj35qc2kM0Ovyw35dJ5AGOIHNJPyIeygd8ZmYsFXqJxnnwv+Ye3r3pJLmDQNhBjdZiZj6GnZNACOPaf3cyOoFc26jpFouRwJ2kdBRRN3+Wgwjv2Z9RFwJBcuX9X5oXRZ8EfvOfCEX/ttlTcY1lgMzBY+u0KX0mzV9TPHERPhr8wG0MlpDs87hMVciV4MauYKDVmMJkjvdQA0Ea59TyzfPfNNhIlcflyu2/UaAphtNti4zA==
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=W/9kVJrN0F3RqjPyO/mivva22PCIdND9SjG+0CY6qKI=; b=VXTLY+BxcUh/rfxakdF7VlSlAHInk8NM1hU4Y+StKTCUsKqm4HOOHJyASwPUyhmmhsQVjSa9LbrL4o10CzA0X1t5RmuNilp04vAypp3wW9gIjkgdsqh5aOWU3g9VaAUbJYcOPB+xRMEQ5PGTsaO0qTVa6fx4LTV0X0rB9+/mWoXDYT1jPS6jPEdsBvyEf3xE7zd2ZdUE9UVseRtvZr0uxXqR2CereYAFY3YmxBSXTE6B02VXBdd+kiOF3XD+vECQ2AbPp0YpIfZNzwUS0rflvHo6/vS7I383E43wsX6jRJfIChSBwoq5SaSOdvSBCLbBABeGPIb/ERlkysrAJYSZMw==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/9kVJrN0F3RqjPyO/mivva22PCIdND9SjG+0CY6qKI=; b=Pyiomt/RqqFZv3yeAT8CKUtvTQ1DRBrTCAMc2IsnK3E8b8rRCTkfXd1wP/eZ8BRwJc44y1ZbWBQUWdyAcSik9jHInwH7ivl6fAg/BUdAm8LO/1L1LuSvxvb2jMCbOeQlzSzOIHlo98Ul3GvUqfnGhnuOkTpVddTeJXUMP0KYuzc=
Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5980.namprd05.prod.outlook.com (2603:10b6:5:3d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.10; Thu, 27 Feb 2020 18:38:06 +0000
Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::cdd:ea54:f213:7e02]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::cdd:ea54:f213:7e02%5]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 18:38:06 +0000
From: Ron Bonica <rbonica@juniper.net>
To: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, "xiejingrong@huawei.com" <xiejingrong@huawei.com>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>
CC: SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
Thread-Topic: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
Thread-Index: AQHV6oS0wgZI2Ya6SUW/GeGpDkHR5qgpNZwAgAAKGoCAABGFAIAAzduAgABNWsCAAITLgIAAD+IAgAEHAgCAAApsUA==
Date: Thu, 27 Feb 2020 18:38:06 +0000
Message-ID: <DM6PR05MB634859429BEBC90FFA687936AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
References: <158248836511.1031.1350509839394231473@ietfa.amsl.com> <7481061F-75A5-4E4D-80AE-40E1F933E94A@cisco.com> <1BB7ED35-98EC-4A73-92A3-AD043D462CF7@steffann.nl> <CAO42Z2zOr_8Ptukf_WE8hWOUUH1vXFig-=fNWhNeweruibQDhw@mail.gmail.com> <DBBPR03MB541525FF72B82416A020B632EEEC0@DBBPR03MB5415.eurprd03.prod.outlook.com> <DM6PR05MB63489BE3D1C669C277D64906AEEC0@DM6PR05MB6348.namprd05.prod.outlook.com> <BEE51E09-0929-4F48-B5B3-6BAB23E07DAB@cisco.com> <CABNhwV3q4MAopb0oXSw4uHezfVLjMnvf8h4BzFY_q8LS7dCXVw@mail.gmail.com> <97141983-EDF7-4C1E-A8F1-4ADCD345BC5A@cisco.com>
In-Reply-To: <97141983-EDF7-4C1E-A8F1-4ADCD345BC5A@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=2020-02-27T18:38:01.9245826Z; 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=a4d717c1-e288-49e6-a031-d042eb515556; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [108.28.233.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ed3b668f-3743-40fa-2139-08d7bbb42fa0
x-ms-traffictypediagnostic: DM6PR05MB5980:
x-microsoft-antispam-prvs: <DM6PR05MB598035475B709E8E14DE3A81AEEB0@DM6PR05MB5980.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(189003)(199004)(6506007)(478600001)(33656002)(81156014)(52536014)(110136005)(66476007)(54906003)(86362001)(5660300002)(64756008)(2906002)(66446008)(53546011)(66946007)(81166006)(8676002)(26005)(66556008)(8936002)(316002)(186003)(76116006)(966005)(9686003)(7696005)(66574012)(71200400001)(55016002)(4326008)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5980; H:DM6PR05MB6348.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rTAYU7f2Tb+kXvjcCbTOfSVC/3Y41mPOgFVz0C8X/C/USPyYCDhYW3LdLHmdzUOVN7vSK8tIJTZpC+BsHnie0UXgJoMO7A8cDcf1UfPoIkC/7qtfcxzvFpQPbPVih1tCzzWqFGqyNKmboDH8nr1lSDV2kRS3dx4ld2KCsvpD6CfZpPoB+/ry0qwEKMDUgSYRU/cJ75zagRRHN1ZcTziUBGcQXt5yCBK1nWICCOWyv5GeTjEkoSPFIe5aZPqL9m5VMTZeRqSSKEb/CFX9vyyN7ZMyq7/JToZXfsb7ALIlczesy3rEfWFc2abHNjWFzUN2hgP3kVTfcs7YK0jic0Dl8BQjbuy4VaD+nqUSW0Q9lCTEEzGZkI0JPZqLGmQ0ZV438+MEKd4UzdcsegZMbToArPNvD1iW/4W16FqjdcxbAUT2iizSdjKi/vZXJtu/APuNrXlNSloNfGvyCxyG+eC+iO9Im20/vI+zFJ0wM1N1VcWygLKt/dJFh1bedO8btoou5QIhstuioL70oLbnJDUrZg==
x-ms-exchange-antispam-messagedata: U+DT5Ue979AFSgUjcdI2sx91Njy2qMURxb6RWjgno1D4E5+kBt5KDxJy1IB6eey5/aQzFVtsqRWLk6jKqGG818XMLxYeM8Iol0yq306RSf12P3asQPd/BGSyeNuoDBUS5oHg4kKIt2tI3GAsIGTW5g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR05MB634859429BEBC90FFA687936AEEB0DM6PR05MB6348namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ed3b668f-3743-40fa-2139-08d7bbb42fa0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 18:38:06.2905 (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: OzR31Iegj3oS96BUGuUrsj8q1mCCLyi8TzSQ1KHQ6KE3ZrQfOKZItqi47Y4Yu/Jb/YjMS9Uw25Y12CQGtwLa/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5980
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-27_06:2020-02-26, 2020-02-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002270131
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vUYFIX9nWiIlSV4Qo2apeNsuIq0>
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, 27 Feb 2020 18:39:33 -0000

Pablo,

The question at hand is whether PSP is so crucial to SRv6 that it is worth stretching the limits of RFC 8200 compliance. The emails that you site below say that it is for the following reasons:


  1.  Because PSP is already deployed
  2.  Because PSP unburdens the ultimate segment router from the task of processing and removing the SRH
  3.  Because PSP enables incremental deployment

The first argument can be dismissed out of hand. Just because something has been deployed doesn't mean that it adds value or even that it causes no harm.

The second argument is dubious. Given that the ultimate segment endpoint has to remove the outer IPv6 header and forward the packet, the additional cost of checking the Segments Left field and removing the SRH is minimal.

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/ and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:


  *   Can process a SID, received as an IPv6 DA, on the fast path
  *   Cannot process an SRH, even if Segments Left equal 0, on the fast path.

In this scenario, PSP keeps packets off of that device's slow path.

While I have sympathy for Dan's dilemma, I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.

Maybe a compromise is possible? Would it be possible to move discussion of the PSP out of the Network programming draft and into a separate draft that a) describes the use-case in which it is required and b) discourages its use in all other cases.

                                                                                                                         Ron



Juniper Business Use Only
From: spring <spring-bounces@ietf.org> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Tuesday, February 25, 2020 10:17 AM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Gyan,

As I (and other WG members) have explained in the past, PSP is not trying to provide any feature parity with MPLS.

It enables new use-cases that have been provided by other members in the list. [1], [2] and [5].
>From operational perspective it is not complex as explained in [3].
There is substantial benefit. Four operators have deployed PSP, which proves the benefit.
And additionally operators have expressed their value in [4] and [5].

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI


I don't see the point of starting a new thread from zero that discusses the same thing.

Cheers,
Pablo.

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Date: Tuesday, 25 February 2020 at 00:35
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt


PSP has historical context from PHP ( Penultimate Hop POP) in the MPLS world.

20+ years ago when MPLS we originally developed the concept of PHP implicit null reserved label value 0 was done to offload the burden of the egress PE FEC destination to pop the entire label stack before forwarding the native IP packet to the CE.

Hardware these days for the last 15 years or so are so advanced that the idea that you are saving processing on the egress PE has not existed for a long time.

Even  back then in both SP and enterprise space there were issues that arise related to PHB QOS egress queuing,  that occurs on the PHP node that had the MPLS shim popped, it cannot schedule on the topmost label via exp provider markings done on the ingress PE upon label imposition.

A workaround to this issue was to set explicit null label value 0 and use pipe or uniform mode to tunnel the customer payload to the egress PE FEC destination called UHP ultimate hop node with topmost label intact.

The concept of implicit null PHP concept did not bode well in the MPLS world so I don't see why that feature parity would be added to a next gen protocol that would be the future MPLS replacement.

I agree with taking some of the good features and knobs from MPLS, but why take the ones like implicit null with is really an archaic feature.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Ron,

This is the 5th time that we have this discussion in the past five months.

I consider those three questions as closed based on the previous discussion.
https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$>

Cheers,
Pablo.

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>
Date: Monday, 24 February 2020 at 16:27
To: Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>, Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>, Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Folks,

We may need to ask the following questions:


1)      Does PSP violate letter of RFC 8200?

2)      Does PSP violate the spirit of RFC 8200?

3)      Is PSP a good idea?

The 6man WG, and not SPRING, should answer the first two questions. So I will avoid them an explore the third.

At first glance, PSP adds no value. Once Segments Left has been decremented to 0, the Routing header becomes a NOOP. So why bother to remove it? I see the following arguments:


1)      To save bandwidth between the penultimate and ultimate segment endpoints.

2)      To unburden the ultimate segment endpoint from the task of processing the SRH

3)      To unburden the ultimate segment endpoint from the task of removing the SRH

The first argument is weak. Routing headers should not be so large that the bandwidth they consume is an issue.

The second argument is also weak. Once the ultimate segment endpoint has examined the Segments Left field, it can ignore the SRH. The ultimate segment endpoint must be SRv6-aware, because it must process the SID in the IPv6 destination address field. Given that the ultimate segment endpoint is SRv6 aware, it should be able to process the SRH on the fast path.

The third argument is even weaker. The ultimate segment endpoint:

-          Has to remove the IPv6 tunnel header, anyway

-          Being closer to the edge, may be less heavily loaded than the penultimate segment endpoint.

Can anyone articulate a better justification for PSP? If not, why test the limits of RFC 8200 over it?

                                                                                                           Ron





Juniper Business Use Only
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Andrew Alston
Sent: Monday, February 24, 2020 5:06 AM
To: Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>; Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I agree with the sentiments expressed below

Andrew


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Mark Smith
Sent: Monday, 24 February 2020 00:50
To: Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org<mailto:pcamaril=40cisco.com@dmarc.ietf.org>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt


On Mon, 24 Feb 2020, 07:47 Sander Steffann, <sander@steffann.nl<mailto:sander@steffann.nl>> wrote:
Hi,

> We have published a new update to draft-ietf-spring-srv6-network-programming. This revision simplifies the counters as per [1], clarifies the upper layer header processing as per [2] and removes the reference to the OAM draft [3].

I still oppose the segment popping flavours in section 4.16 without updating RFC8200.

I would expect that defying Internet Standard 86/RFC8200 means this ID needs to have Experimental rather than Standards Track status.




Cheers,
Sander

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYkKy0jPv$>
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>