From nobody Tue Aug 25 08:28:04 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD2F3A0DF6; Tue, 25 Aug 2020 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=bLbXzdTR; dkim=pass (1024-bit key) header.d=juniper.net header.b=GkuDTTar 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 P4n_Uc7LJ-H0; Tue, 25 Aug 2020 08:27:59 -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 4E5533A0E93; Tue, 25 Aug 2020 08:27:59 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07PFQglo014716; Tue, 25 Aug 2020 08:27:55 -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 : mime-version; s=PPS1017; bh=VhWhXJREDAPSFm7+1eAuNjFdUz78grr9o/AxI8Nx+As=; b=bLbXzdTRZVTXeQvQWJgpcjOpgRcQXNCukJZzaFg7Z7b1Z1BTRS1QQnzbSD13KcFB1Pia 464r8sQM+Y+VyDvhARIoQ+l/Y7tCMOJ+1WvxWRgzdum77my9tqhZc2OUkTZiU6zrjMKx gjmD2qCVRXsITwEBZQSNmLQWsY8gkl7+p4vL1U7XaaIC2kqAVSjXhzMmO6IjK44VG4Pt Y0CRnroVQYOtgKyO53BKGtIkfpccWQxj0SUhY+H5d1tWklX34Q27X4qf3E3dIkZmxE0D 4a0OQuFGphPVg98tkUHoG/3dLhJIZGIN6RAj+Domrz3Nwq98gonzAtq1Rr/SXKkEULQ4 9g== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2057.outbound.protection.outlook.com [104.47.36.57]) by mx0a-00273201.pphosted.com with ESMTP id 3332cnvmsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2020 08:27:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UVbZsOSS/ItTUEKrIDB6uJq2kT1PZvWZ8vKDOHRHwnDDSXNyRcFbbo54pCSzb6JH+CzQ1pb9Hz9JwFptRHKv7DGr+Sm7X8iYQB3Mlm8rPjNS41uvAJ9UWcG5geQ7eaccju5jbsG2zJcfhQLgAZMjTWTtqN4EnTMSadvtu6bV5nK/OYM9Ircy1TcGzHfXfOy7lBTF1ApE2028NXv948zQckz2PVaUaf3w/EYCKnQXHptMQc4OGsPcfKWnT1J097Kagx2P2nIZ1gAKhtkUAK3I1uRbmhZdTeXae1Rk33/uneMutKBTdOLsvxh8WTP92UOk1Zjf+HmA/HJcERlASrVKzg== 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=VhWhXJREDAPSFm7+1eAuNjFdUz78grr9o/AxI8Nx+As=; b=ltP4uSgeSekI0LiAew9zJGC4MF3QUHkbyn2XSUBjSgSt7HEMK21VeGTfCAkC1vIuXXHNAisR6IU+jQe6dwVwcOe4S03Vb0Hf3Gl2Bgvtl9OCmvc4aOBVH9FNNuisqI0G8D8OcKo4MmzIc3draXBCkiuC09VkmCIeeSreV/pEvfMYGD+zRLLLqNHWBW8XAtQQKxp5mYK6c5phRpPe67EEBJ0pcZjCuNG1YkDAWDWH07lsMOHoUV9S91Iud/tIqW13pOOd82uzxLf2qzEk7hPZR/0E9ck71T3cRIkUooOH881rk05avafxjVCCJdClunMBIIn3TxkPXU/8poj9AFZv+A== 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=VhWhXJREDAPSFm7+1eAuNjFdUz78grr9o/AxI8Nx+As=; b=GkuDTTaraLKDYW9TFvP++F552F7SYaaks0VI8BipT0Cc2S3wf9I2BX3LQR/PqyZZg9hyMKNh3bIT1/ViNM3WKJWAt9hVBv1Zio1XmQzQZ/82XoJRGM5kR+BBv6t4+F8M3GFs8xPFjBftOV7yKCRs4GkZM0quSoX9MuuzVCr8QgM= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3302.namprd05.prod.outlook.com (2603:10b6:910:51::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.13; Tue, 25 Aug 2020 15:27:38 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.021; Tue, 25 Aug 2020 15:27:38 +0000 From: Shraddha Hegde To: "olivier.dugeon@orange.com" , Peter Psenak , "tony.li@tony.li" , Robert Raszuk CC: Christian Hopps , "draft-ietf-lsr-flex-algo.all@ietf.org" , "Les Ginsberg (ginsberg)" , "lsr@ietf.org" , "lsr-ads@ietf.org" , "Acee Lindem (acee)" Thread-Topic: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo Thread-Index: AQHWdO5dvGlf+k99WUyGQOWY1SyMuKk898AAgACasICAAF/ZAIAAFlMAgAAFBoCAAAtMgIABONCAgAAFH4CAAZHMAIAAA+UAgAAlLICAB+yNgA== Date: Tue, 25 Aug 2020 15:27:38 +0000 Message-ID: References: <9094873B-3A03-4F48-B438-55AB0CA75396@chopps.org> <7D686875-46CA-4E3C-8F1A-3A02DB162499@tony.li> <30234_1597837344_5F3D1020_30234_107_1_595a0b47-eb26-8935-fe4f-429ccc725592@orange.com> <4d0b84a7-08b3-e2c6-f918-8009be2d6523@cisco.com> <2595_1597924729_5F3E6579_2595_13_1_7c66f628-46fc-c749-aa45-cb22f6e9e996@orange.com> <1fb53fad-b5ae-4d2f-3fde-180b62bc9645@cisco.com> <9988_1597933548_5F3E87EC_9988_13_3_15236ac6-520b-919b-ecec-c6c58b48b73d@orange.com> In-Reply-To: <9988_1597933548_5F3E87EC_9988_13_3_15236ac6-520b-919b-ecec-c6c58b48b73d@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-25T15:27:34Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3f0d5138-bd26-4fc0-9ad6-e457e7d7520d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [122.171.239.237] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a746ee89-97ce-43db-c089-08d8490b6681 x-ms-traffictypediagnostic: CY4PR05MB3302: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P2a523ibmqaj2iFkHi8jlr38OsVwuWaxCU6+T59+JBel+t33c1utnUtOOCueHmL6NmRzZf1S5Z6zpdacOwl0xo8Qbynta0lzAtTqNEVEV2kgRB5hs2Q1KrsSCQBgb/YZ3GXpJR+/FI01A1Ud9QJdWZoBQwrQCDfKeGTn1ghd8qvmSvQ736pvhQ9NUZjc7+CTbrk2TsGunhdNSZvGHfmJxWiGIJzp7UeZnW/5JQujRS2wZKEQjkFJ9njJXUsqVBWEjep5QmbF6fjij6YslJa44IRwIxY8rNPkjd5nl1B3iXE9pbLrK8rSyw5VWyxQhPtMTmTgYsfcGR48uClzJLuHp1GDFmaVrQ+gtNFJqsq1l05+3nKSboxwEbiaVSQvj6PUwEDhEEYGPG6KW0hMCMQXwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(39860400002)(346002)(396003)(166002)(86362001)(30864003)(55016002)(66574015)(66616009)(52536014)(83380400001)(66446008)(64756008)(66556008)(7416002)(66946007)(66476007)(478600001)(9686003)(76116006)(5660300002)(26005)(6506007)(110136005)(99936003)(8936002)(54906003)(186003)(2906002)(53546011)(7696005)(33656002)(966005)(8676002)(9326002)(71200400001)(316002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: c0e1YplvFuw4DLt6yMFokG6zzxp2v1DgPJs0q75ojbLB3EOJ1f1vTdPsZ78XmlRXAWEGTskFjcpGIFx9+Kq+wtRD6D0LEc8ciAWZ92UsvqIQaqqmb11jE8XCQ4HK9Zs6LZh5nGXTNIfKQ7jLDSgjxrOcHdnuO1PPwEROm0+nqiDxpEI8nhxid6CFS6UCO//u8XjswurExeTZ/5Y8toVIMaxlXK26NJ0NfJCHd1TnRvS8TOCVi3UFA+pRbZvXc+dv/1L5FItTCfUW6Qi4VKawdgEiRbc0vBdoZOhh6RMeXV4oj2z06GPRIelOSOf11eHVc713B5u6pj/5E8QMIPLBQci/++vAyJ2LCYBnCUhXfyvIAhaGD96OJkNbpojfyB/vi2WrExiwXBLiJhS80te79xTErff+LLhkYPnipswjWhk0DxgLbLm/eil1p0QMA6AZiI68eUAFeIOFvO60nYZCXlyOi0C1FOvAl4ljsmtMUtFuot2deyWfAFwiHHAfCfS4LIFUXeUgvqE3wPGtuuHfEUTYX0P6oSxLcaVUvMSvDjJ1mLAZboMGUDrL0uA0bofiC/m/u2bjGIFcP95uUtC3qrNHR0b/qoojHGN7+wXXFScRFDDTnj2fjH04JD3ltud3jf3Ld4j/hQaojIholEcXUA== x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a746ee89-97ce-43db-c089-08d8490b6681 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2020 15:27:38.4683 (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: pG+ARAjxxKt6XdI797hQBTt39z5VWZ3/cjSxEs0aCxDQ1o+0LCAmhtDY0dhKfMVe/p6XTnBXlnzKcInhmsEMQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3302 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-25_05:2020-08-25, 2020-08-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 spamscore=0 priorityscore=1501 phishscore=0 clxscore=1011 mlxscore=0 suspectscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008250114 Archived-At: Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 15:28:03 -0000 --_004_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_ Content-Type: multipart/alternative; boundary="_000_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_" --_000_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, draft-lsr-flex-algo-00 was created by combining draft-hegdeppsenak-isis-sr-flex-algo-02 and draft-ppsenak-ospf-sr-flex-algo= -00. When draft-lsr-flex-algo-00 was published as a WG document, it included a requirement for using te-app encodings that did not exist in either draft-hegdeppsenak-isis-sr-flex-algo-02 and draft-ppsenak-ospf-sr-flex-algo= -00. Juniper's currently released implementation of flex-algo uses legacy encodi= ngs, as opposed to te-app encodings. I would like the following text added to draft-lsr-flex-algo in order to record the history of these changes and to = make operators aware of possible inter-op problems that may arise due to the non-backward compatible nature of mandating ASLA encodings. =3D=3D=3D=3D=3D 11. Advertisement of Link Attributes for Flex-Algorithm " Earlier versions of this draft did not mandate the use of ASLA TLVs for e= ncoding the link attributes. There may be implementations that depend on legacy encodin= gs as defined in RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that look at onl= y ASLA encodings for flex-algo based on this version of the document will not interoperate w= ith versions that use legacy advertisements. " =3D=3D=3D=3D=3D=3D=3D=3D Rgds Shraddha Juniper Business Use Only From: olivier.dugeon@orange.com Sent: Thursday, August 20, 2020 7:56 PM To: Peter Psenak ; tony.li@tony.li; Robert Raszuk Cc: Christian Hopps ; draft-ietf-lsr-flex-algo.all@ietf.= org; Les Ginsberg (ginsberg) ; lsr@i= etf.org; lsr-ads@ietf.org; Acee Lindem (acee) Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo [External Email. Be cautious of content] Peter, Le 20/08/2020 =E0 14:12, Peter Psenak a =E9crit : Hi Olivier, On 20/08/2020 13:58, olivier.dugeon@orange.com wrote: Hi Peter, Thank for the new version. Le 19/08/2020 =E0 14:00, Peter Psenak a =E9crit : Olivier, [ ... ] So, to speed up the deployment, I would prefer a reference to a delay value= that could be advertise by means of RFC7471, RFC8570 and/or TE-App draft. = It is then up to the operator to ensure the coherency of what it is announc= ed in its network by the different routers. I know you don't like the app specific link advertisement, but I'm afraid w= hat you ask for is absolutely wrong. We defined the ASLA encoding to address a real problems for advertising the= link attributes. We allow the link attributes to be advertised in both leg= acy and ASLA advertisement for legacy application (RSVP-TE, SRTE) to addres= s the backward compatibility. Flex-algo is a new application, there is abso= lutely no need to use the legacy advertisement. Doing so would just extend = the problem to the flex-algo application. Regarding the new version you provided, new section 5.1 (for IS-IS) and sec= tion 5.2 (for OSPF) mention respectively RFC 8570 and RFC 7471 for the defi= nition of Min delay and TE metric which is fine for me. But, they also made= reference to draft isis-te-app, respectively ospf-te-link-attr-reuse to en= code these value. that's what people were asking for. And it is right because we are mandatin= g the usage of ALSA encoding for any flex-algo related link attributes. Here, it is confusing. I don't see how much more clear we can make it. Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric and M= in delay. you have to distinguish between two things: a) where Min delay and TE metric were defined - RFC 8570 and RFC 7471 b) how we encode it for flex-algo - isis-te-app, ospf-te-link-attr-reuse What I'm suggesting, is a clear reference to the RFC for TE metric and Min = delay definition as well as the encoding (especially for the delay) while l= eaving open the door to how the router acquire these values: legacy a.k.a. = RFC 8570 & 7471 or new draft a.k.a draft-isis-te-app & draft-ospf-link-attr= -reuse. no. This will not be done. We only allow ASLA advertisement for these metri= cs and other link attributes that are used for flex-algo. It is done for a = reason and I have already explained that. OK. Reading section 11 which clarify how metrics are convey, let me suggest= to make a reference to section 11 in section 5.1 and 5.2 instead of refere= nce to drafts. In fact, in section 17.1.2, you mention only reference to RFC 8570 & RFC747= 1 for the IANA definition which is fine for me. because in registry, we are defining a metric type, not how we are going to= advertise it for the link. OK. I would suggest the same wording for section 5.1. and 5.2 leaving operator = free about how it collect the values from the neighbour routers: legacy or = new method. please stop trying to make use of legacy RSVP-TE link advertisements for fl= ex-algo - it will not be allowed. This raise to me a simple question: Is it possible to use 2 different Flex = Algo with delay metric, one for App A and another one for App B ? if yes, h= ow can we link metrics advertise in ALSA A from metrics advertise in ALSA B= ? The draft mention only one bit for Flex-Algo. Regards, Olivier PS. I note a duplicate paragraph in section 12: "When computing the path fo= r a given Flex-Algorithm, the metric-type that is part of the Flex-Algorith= m definition (Section 5) MUST be used." thanks, Peter Regards Olivier PS. We have a pre-alpha implementation of flex algo using the legacy metric= s and I know that recent IOS-XR provided similar implementation of flex alg= o based on legacy metrics. regards, Peter Regards Olivier Le 18/08/2020 =E0 19:02, tony.li@tony.li a =E9crit = : Robert, Thank you, exactly. We just need a clarification of the document. I don't understand why this = is such a big deal. Tony On Aug 18, 2020, at 9:22 AM, Robert Raszuk > wrote: Les, I think this is not very obvious as Tony is pointing out. See RFC 8570 says: Type Description ---------------------------------------------------- 33 Unidirectional Link Delay 34 Min/Max Unidirectional Link Delay That means that is someone implementing it reads text in this draft literal= ly (meaning Minimum value of Unidirectional Link Delay) it may pick minimum= value from ULD type 33 :) If you want to be precise this draft may say minimum value of Min/Max Unidi= rectional Link Delay (34) and be done. That's all. Cheers, R. On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) > wrote: Tony - As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you are confused - nor why you got misdirected to code point 33. RFC 8570 (and its predecessor RFC 7810) define: 34 Min/Max Unidirectional Link Delay This sub-TLV contains two values: "Min Delay: This 24-bit field carries the minimum measured link delay value (in microseconds) over a configurable interval, encoded as an integer value. Max Delay: This 24-bit field carries the maximum measured link delay value (in microseconds) over a configurable interval, encoded as an integer value." It seems clear to me that the flex-draft is referring to Min Unidirectional Link Delay in codepoint 34. I agree it is important to be unambiguous in specifications, but I think Peter has been very clear. Please explain how you managed to end up at code point 33?? Les *From:* Lsr > *On Behalf Of *tony.li@tony.li *Sent:* Tuesday, August 18, 2020 7:44 AM *To:* Peter Psenak (ppsenak) > *Cc:* lsr@ietf.org ; lsr-ads@ietf.org ; Christian Hopps >; Acee Lindem (acee) <= acee@cisco.com >; draft-ietf-lsr-flex-algo.a= ll@ietf.org *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo Hi Peter, section 5.1 of the draft-ietf-lsr-flex-algo says: Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with other delay values (max, average). The problem is that that does not exactly match "Unidirectional Link Delay" or "Min/Max Unidirectional Link Delay", leading to the ambiguity. Without a clear match, you leave things open to people guessing. Now, it's a metriic, so of course, you always want to take the min. So type 33 seems like a better match. section 7.3. of ietf-isis-te-app says: Type Description Encoding Reference --------------------------------------------------------- 34 Min/Max Unidirectional Link Delay RFC8570 And it also says: 33 Unidirectional Link Delay RFC8570 This does not help. So, IMHO what we have now is correct and sufficient, but I have no issue adding the text you proposed below. What you have now is ambiguous. We have a responsibility, as writers of specifications, to be precise and clear. We are not there yet. BTW, before I posted 09 version of flex-algo draft, I asked if you were fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did not indicate otherwise. My bad, I should have pressed the issue. Anyway, I consider this as a pure editorial issue and hopefully not something that would cause you to object the WG LC of the flex-algo draft. I'm sorry, I think that this is trivially resolved, but important clarification. You also have an author's email that is bouncing, so at least one more spin is required. Sorry, Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr -- Orange logo Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- Orange logo Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- [Orange logo] Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,<= /span>

 

draft-lsr-flex-algo-00 was created by combining

draft-hegdeppsenak-isis-sr-flex-algo-02 and draft-pp= senak-ospf-sr-flex-algo-00. 

When draft-lsr-flex-algo-00 was published as a WG do= cument, it included

a requirement for using te-app encodings that did no= t exist in either

draft-hegdeppsenak-isis-sr-flex-algo-02 and draft-pp= senak-ospf-sr-flex-algo-00. 

 

Juniper's currently released implementation of flex-= algo uses legacy encodings,

as opposed to te-app encodings.  I would like t= he following text added to

draft-lsr-flex-algo in order to record the history o= f these changes and to make

operators aware of possible inter-op problems that m= ay arise due to the

non-backward compatible nature of mandating ASLA enc= odings.

 

=3D=3D=3D=3D=3D

11.  Advertisement of Link Attributes for Flex-= Algorithm

 

" Earlier versions of this draft did not mandat= e the use of ASLA TLVs for encoding the

link attributes. There may be implementations that d= epend on legacy encodings as defined in

RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implement= ations that look at only ASLA encodings

for flex-algo based on this version of the document = will not interoperate with versions

that use legacy advertisements. "

=3D=3D=3D=3D=3D=3D=3D=3D

 

 

Rgds

Shraddha=

 

 

Juniper Business Use Only

From:= olivier.dugeon@orange.com <olivier.dug= eon@orange.com>
Sent: Thursday, August 20, 2020 7:56 PM
To: Peter Psenak <ppsenak@cisco.com>; tony.li@tony.li; Robert = Raszuk <robert@raszuk.net>
Cc: Christian Hopps <chopps@chopps.org>; draft-ietf-lsr-flex-a= lgo.all@ietf.org; Les Ginsberg (ginsberg) <ginsberg=3D40cisco.com@dmarc.= ietf.org>; lsr@ietf.org; lsr-ads@ietf.org; Acee Lindem (acee) <acee@c= isco.com>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif">[Ex= ternal Email. Be cautious of content]

 

Peter,<= /o:p>

Le 20/08/2020 =E0 14:12, Peter Psenak a =E9crit = ;:

Hi Olivier,

On 20/08/2020 13:58, olivier.d= ugeon@orange.com wrote:

Hi Peter,

Thank for the new version.

Le 19/08/2020 =E0 14:00, Peter Psenak a =E9crit :

Olivier,

[ ... ]

So, to speed up the deployment, I would prefer a ref= erence to a delay value that could be advertise by means of RFC7471, RFC857= 0 and/or TE-App draft. It is then up to the operator to ensure the coherenc= y of what it is announced in its network by the different routers.


I know you don't like the app specific link advertisement, but I'm afraid w= hat you ask for is absolutely wrong.

We defined the ASLA encoding to address a real problems for advertising the= link attributes. We allow the link attributes to be advertised in both leg= acy and ASLA advertisement for legacy application (RSVP-TE, SRTE) to addres= s the backward compatibility. Flex-algo is a new application, there is absolutely no need to use the legacy advert= isement. Doing so would just extend the problem to the flex-algo applicatio= n.


Regarding the new version you provided, new section 5.1 (for IS-IS) and sec= tion 5.2 (for OSPF) mention respectively RFC 8570 and RFC 7471 for the defi= nition of Min delay and TE metric which is fine for me. But, they also made= reference to draft isis-te-app, respectively ospf-te-link-attr-reuse to encode these value.


that's what people were asking for. And it is right because we are mandatin= g the usage of ALSA encoding for any flex-algo related link attributes.

Here, it is confusing.


I don't see how much more clear we can make it.

Indeed, RFC 8570 and RFC 7471 also define the way to= encode TE metric and Min delay.


you have to distinguish between two things:

a)  where Min delay and TE metric were defined - RFC 8570 and RFC 7471=
b)  how we encode it for flex-algo - isis-te-app,
ospf-te-link-attr-reuse


What I'm suggesting, is a clear reference to the RFC for TE metric and Min = delay definition as well as the encoding (especially for the delay) while l= eaving open the door to how the router acquire these values: legacy a.k.a. = RFC 8570 & 7471 or new draft a.k.a draft-isis-te-app & draft-ospf-link-attr-reuse.


no. This will not be done. We only allow ASLA advertisement for these metri= cs and other link attributes that are used for flex-algo. It is done for a = reason and I have already explained that.

OK. Reading section 1= 1 which clarify how metrics are convey, let me suggest to make a reference = to section 11 in section 5.1 and 5.2 instead of reference to drafts.


In fact, in section 17.1.2, you mention only reference to RFC 8570 & RF= C7471 for the IANA definition which is fine for me.


because in registry, we are defining a metric type, not how we are going to= advertise it for the link.

OK.

 

I would suggest the same wording for section 5.1. an= d 5.2 leaving operator free about how it collect the values from the neighb= our routers: legacy or new method.


please stop trying to make use of legacy RSVP-TE link advertisements for fl= ex-algo - it will not be allowed.

This raise to me a simple question: Is it possible to use 2 different Fl= ex Algo with delay metric, one for App A and another one for App B ? if yes= , how can we link metrics advertise in ALSA A from metrics advertise in ALS= A B ? The draft mention only one bit for Flex-Algo.

Regards,

Olivier

PS. I note a duplicate paragraph in section 12: "When computing the= path for a given Flex-Algorithm, the metric-type that is part of the Flex-= Algorithm definition (Section 5) MUST be used."


thanks,
Peter


Regards

Olivier

PS. We have a pre-alpha implementation of flex algo using the legacy metric= s and I know that recent IOS-XR provided similar implementation of flex alg= o based on legacy metrics.


regards,
Peter


Regards

Olivier

Le 18/08/2020 =E0 19:02, tony.li@tony.li= a =E9crit :


Robert,

Thank you, exactly.

We just need a clarification of the document.  I don’t understan= d why this is such a big deal.

Tony


On Aug 18, 2020, at 9:22 AM, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>&g= t; wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

       Type    Description        --------------------------------------= --------------
        33     Unidi= rectional Link Delay

        34     Min/M= ax Unidirectional Link Delay

That means that is someone implementing it reads text in this draft literal= ly (meaning Minimum value of Unidirectional Link Delay) it may pick minimum= value from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min= /Max Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf= .org <mailto:40cisco.com@dmarc.= ietf.org>> wrote:

    Tony –

    As an author of both RFC 8570 and I-D.ietf-isis-te-app, = I am not
    sure why you are confused – nor why you got misdir= ected to code
    point 33.

    RFC 8570 (and its predecessor RFC 7810) define:

    34          = ; Min/Max Unidirectional Link Delay

    This sub-TLV contains two values:

    “Min Delay:  This 24-bit field carries the mi= nimum measured link
    delay

          value (in microseconds) o= ver a configurable interval,
    encoded as

          an integer value.

       Max Delay:  This 24-bit field carries = the maximum measured
    link delay

          value (in microseconds) o= ver a configurable interval,
    encoded as

          an integer value.” =

    It seems clear to me that the flex-draft is referring to= Min
    Unidirectional Link Delay in codepoint 34.

    I agree it is important to be unambiguous in specificati= ons, but
    I think Peter has been very clear.

    Please explain how you managed to end up at code point 3= 3??

       Les

    *From:* Lsr <= lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
    *On Behalf Of *tony.= li@tony.li <mailto:tony.li@tony.li>
    *Sent:* Tuesday, August 18, 2020 7:44 AM
    *To:* Peter Psenak (ppsenak) <ppsenak@cisco.com
<mailto:ppsenak@cisco.com>&g= t;
    *Cc:* lsr@ietf.org <= a href=3D"mailto:lsr@ietf.org"> <mailto:lsr@ietf.org>; lsr-ad= s@ietf.org
<mailto:lsr-ads@ietf.org>; Ch= ristian Hopps <chopps@chopps.org
<mailto:chopps@chopps.org>&g= t;; Acee Lindem (acee) <acee@cisco.com=
<mailto:acee@cisco.com>>; draft-ietf-lsr-flex-algo.all@ietf.org
<mailto:draft-i= etf-lsr-flex-algo.all@ietf.org>
    *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-fle= x-algo

    Hi Peter,



        section 5.1 of the draft-ietf-ls= r-flex-algo says:


        Min Unidirectional Link Delay as= defined in
        [I-D.ietf-isis-te-app].

        We explicitly say "Min Unid= irectional Link Delay", so this
        cannot be mixed with other delay= values (max, average).

    The problem is that that does not exactly match “U= nidirectional
    Link Delay” or “Min/Max Unidirectional Link = Delay”, leading to
    the ambiguity. Without a clear match, you leave things o= pen to
    people guessing. Now, it’s a metriic, so of course= , you always
    want to take the min.  So type 33 seems like a bett= er match.





        section 7.3. of ietf-isis-te-app= says:

        Type   Description &nb= sp;            =             Enc= oding
             &n= bsp;            = ;            &n= bsp;            = ;Reference
        --------------------------------= -------------------------
        34      = ;Min/Max Unidirectional Link Delay    RFC8570

    And it also says:

    33      Unidirectional Link Del= ay RFC8570
<https://tools.ietf.org/html/rfc8570>

    This does not help.



        So, IMHO what we have now is cor= rect and sufficient, but I
        have no issue adding the text yo= u proposed below.

    What you have now is ambiguous. We have a responsibility= , as
    writers of specifications, to be precise and clear. = ; We are not
    there yet.



        BTW, before I posted 09 version = of flex-algo draft, I asked
        if you were fine with just refer= encing ietf-isis-te-app in
        5.1. I thought you were, as you = did not indicate otherwise.

    My bad, I should have pressed the issue.



        Anyway, I consider this as a pur= e editorial issue and
        hopefully not something that wou= ld cause you to object the WG
        LC of the flex-algo draft.

    I’m sorry, I think that this is trivially resolved= , but important
    clarification.

    You also have an author’s email that is bouncing, = so at least one
    more spin is required.

    Sorry,

    Tony

    _______________________________________________
    Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr



_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

-- 
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com = <mailto:olivier.dugeon@orange.com>

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

 

-- 
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com = <mailto:olivier.dugeon@orange.com>

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

 

--
3D"Orange

&nb= sp;

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_-- --_004_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=219; creation-date="Tue, 25 Aug 2020 15:27:36 GMT"; modification-date="Tue, 25 Aug 2020 15:27:36 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAABmJLR0QA/wD/AP+gvaeTAAAACXBI WXMAAA3XAAAN1wFCKJt4AAAAe0lEQVRYw+3YoQ2AMBBG4b+EAVBYfFeBhHkYgxEYgTmKRmFIQJKw QVngQgiiqXhPnvrEnTkXB0VlXKHMAwgQIECAAAECBAgQIECAAAEC/F9pTqtG8n1ayTpL9/4RWHup G9MCr80EsoMA87zic5GmNq3kCObY8QIGCPC9B8bwEkbe325MAAAAAElFTkSuQmCC --_004_CY4PR05MB35765A65104AA46FD755CE73D5570CY4PR05MB3576namp_--