From shraddha@juniper.net Fri May 3 02:33:34 2024 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B91FC14F609; Fri, 3 May 2024 02:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.669, 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_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="RcyXnUMs"; dkim=pass (1024-bit key) header.d=juniper.net header.b="hA36HDvX" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1PeJZ8KUKSK; Fri, 3 May 2024 02:33:29 -0700 (PDT) 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 9D487C14F616; Fri, 3 May 2024 02:33:29 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4438kFOK001015; Fri, 3 May 2024 02:33:27 -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=ONYVsBj1jJU5k6wl4rovII hJptInx+uNx/50HuylGwg=; b=RcyXnUMszdVtv4S6dJgWPYlKqlGjvQc58XDGvg RKaX50eR7IyIEM6p5mpa84ywKNoDPq6mZUsgsDWZwa7j1Khzy4zjQHotjnKaPrvQ nqm3nQpVYZy1ow145GMUqiRpVpQezRvmnFFkg9WRuUWPxDYMiRRkXhzRCAE9KkA2 YYeMIEOyDxhyxHRbfVBMWpXSSD33ArtjwasguuiBmKix77ARRBj9FckAdDccBBC7 AVivkhRfqio30/Fo9Qu/sOYDZcxwXuQytSHKQReh7neUy6+Ts6N0rBF/RO+51+40 NrDEFXfC1njH89olimz9WGP2mWPiGidjiUCpZvB7vwz/puGw== Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azlp17013021.outbound.protection.outlook.com [40.93.12.21]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3xry9dpbc8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 May 2024 02:33:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ch0fC+Py1PjeZSo59K4izG60C1dFS6/Fc1RlvW29sYf9g3IXMZGBmmDx7kB9wUTpZu4Cg7Badk+ehkUj7C4ibK78em/tqpaYMJWqJTCOKHva64pO9GFe/0I1uWp/J6MZ1BUSVm49Xx0saBXeaR/tDotLxMDXtRKXoSrwQRCdqI8nb0DPokpX/yrFmloEy10zUxKScD1JqzrO84OY4rpq9c3LlvNS8J0YP0nYBsYHHXi4DyhxbXos2bGwRSAiO34p+Ikd8ATkLW2a8pyLlQk5GGKnkic6fzfzwV8Sp1gLJkOIVXu4UoZzQhC0mRu5mUPtnMjGlt8sTWFd0s+/yoYrsQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ONYVsBj1jJU5k6wl4rovIIhJptInx+uNx/50HuylGwg=; b=W3I3Rr7zCd2FjqKCRqVgzC7iCCqbQLNllgDX7ZR5mk4miui0hm991j/8qw/jUqb211WztWxBw53BUQY+FVi9q7e57dv2SaliVw9S4W3zdh5Md+rhQvIGUtBX3htZfntS89rJFFP8SK4RiFCx/XRPWH9EOeN5n8Vgxi9oxypiUbACeiT1lypjlKZ4o7nfBbLs5BfHfFJHrGazIzdTPfihFsr7JpLeUMX6Lw6HeWkNtcMEUZ/9KDOGypR//CcKF6M0X4kQOsX3mDHmoorWuKDgz1FZINpyAnk3g37rINJSU3EyuXKQEiAhVEbaUTGnE0dI9A+EylxKPliGLL19wZb1YA== 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=ONYVsBj1jJU5k6wl4rovIIhJptInx+uNx/50HuylGwg=; b=hA36HDvXngdPtWfoDNsHZQSd+vBXyT7yvIgX97bI6GqOEg3/pqLMv4Goi9JyML1dTfeok3iV5TvzK7MM1b+Pa2r3vLYcrmrkfiA2GQalUTE89QJFoZWhy+9UE2im7nwmfezDd3SV1MZACCiyAYFTUh4HbdfCqi2LhAswVxLp/hs= Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by PH0PR05MB8767.namprd05.prod.outlook.com (2603:10b6:510:b2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.33; Fri, 3 May 2024 09:33:23 +0000 Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::9a48:3f33:3abc:59b0]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::9a48:3f33:3abc:59b0%4]) with mapi id 15.20.7544.029; Fri, 3 May 2024 09:33:22 +0000 From: Shraddha Hegde To: James Guichard , "draft-ietf-mpls-spring-inter-domain-oam@ietf.org" CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: Initial AD review for https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/ Thread-Index: AQHalKv/YPx3Kd+KukatVIqa+PMYobGFEIZg Date: Fri, 3 May 2024 09:33:22 +0000 Message-ID: References: In-Reply-To: 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_ActionId=80610cda-620c-4adf-8c7d-8864144ec365; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; 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_SetDate=2024-05-03T05:44:16Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CO1PR05MB8314:EE_|PH0PR05MB8767:EE_ x-ms-office365-filtering-correlation-id: 58557d0b-0c7d-4d72-7878-08dc6b54136f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230031|366007|376005|1800799015|38070700009; x-microsoft-antispam-message-info: =?us-ascii?Q?Z0R8WqrDCFqI8sZng2JBKMwemJwahC6yPt8jEXXvctEPJc/KQ/MNzUhy/PWX?= =?us-ascii?Q?Ox1Gshr/jTNSXpfPALE9Wfe4vOCvVRdyUsLAQjTP/3p5rtcj80oMSG1IX+9+?= =?us-ascii?Q?YMR/EKnrw7uWcvrEqshZI4EjnjH6DUuuQzIXSPwrR34JgxgUt0mz8n1SRtJe?= =?us-ascii?Q?503F6Zs4QvutYv0z8j6QA4DkMp3EykxFKE2frUq91CQ+hNsAEuidjGqYQIca?= =?us-ascii?Q?NjOisYQ+ijs3EI1+Si/r6bt2KGyOrmO01ozu32RiXN9SqCEiTiQ/vsYW7mzP?= =?us-ascii?Q?IYDQQUK8l8OJNvWiWXzHq2Idqv0P04SW2xWc6K5HoFVtM+PaIzV8/szrHRgw?= =?us-ascii?Q?NjYGq2MdrRJr/2XlvhlgnnYCz99kZFohQOtvnDnByDdAd7GWwJi5MFXJZQPB?= =?us-ascii?Q?bjtKkMF1jYQW7T/BOrMjyUcXZxUOrpz6t/FHHEmOo2ERZyi93Wjmc/2ewgXi?= =?us-ascii?Q?BVmlvywQPvsXEe94g9yYI0W6Nt+eQjR7Rd4dJOsN4QR6w2P+vJX17w+UK8VI?= =?us-ascii?Q?tkc/QTh4A9ChYk+NLJwT45UTipRG+h4ldd2cfIn2KlW/v6bT12OmUto0kTPA?= =?us-ascii?Q?+qbuEGaOQa9Wp9L6Bpnv9EL/VQ7krKqeSSCY0KZmeGIrVZDsVwsWBh57Icp/?= =?us-ascii?Q?zkB+uqpnP1cStlQSzI2gL5usnKO13T1nWQ9pC4F4txgJdS9u4UVblGaGHH9y?= =?us-ascii?Q?V9lYpUWQnTKLtOyEVBZcpnXp/BGL8GMpLJBZphbKcyl2f46ukcP7hrjT0Sfi?= =?us-ascii?Q?z+zrnhj2ngZ+TChRqv1e4TpfnpcqV5vonazkPopsS5pxG2hynfZ31qqO3SQM?= =?us-ascii?Q?ZM82mnpBDulufBc7jK07C8hbx9OXfT+6Fw0r4aP2bjAqtTkIv4NeS7BbDcDB?= =?us-ascii?Q?cLGD2zaR31QpxixKVx0X6hX9rCK9AaMJZ2uy+WxVeQGN5rUtdBTZetWTMO/G?= =?us-ascii?Q?AAm3K0hqLjv2fML+DclKaqAgFPKgE6iM4jw4v5VmD3Jm5+vnr9YNfgX0lYG2?= =?us-ascii?Q?xjauinwkVfHRl+UuIS+4wIS/WMZiWw5By9xmMeyo7f2Fo0Tg4BSMFqrngIpC?= =?us-ascii?Q?Kf+pboFTZkAsWtOzg3zMZ6CaPUxHYuNMOgvGao6pMa277ldyaD00KcW1CGXW?= =?us-ascii?Q?LaalkDT96kSezPBHgUx07hqdI2CPgA/4W4gIq/Tsjh7bmzIKkF7qsRnoma03?= =?us-ascii?Q?wtdcysoN1hGjbCsPGpr4mQEOQVDQII5NCYuzPKlSZk6yjr01KzsT2XradjHq?= =?us-ascii?Q?+CnCNtfJUvDUwhoWn/DHQSFDo6ZwBDGjesl/YejR7w=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR05MB8314.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(376005)(1800799015)(38070700009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9l3GM/t0T0S5Gnx8tGn0PXSZ1ypMvTMRTBj/IjHilZOiPB09R7I/26cpOZtf?= =?us-ascii?Q?8FnP7D23YlXLZh3aBELhW26yxr2kNh5fl5tSqA9uMj7wqzC2Cisg5uD97J4C?= =?us-ascii?Q?X72ATA5k2hLnJH/+q+BEORlKPBHa2BkiLrBS3YLdqBk6cibLcOM4A9TGabSS?= =?us-ascii?Q?9H4V2PWH4T/M07gdFpef7/DuPtwcCgKhsTxqGDVds5oLWILEQGO257oaM5FX?= =?us-ascii?Q?Us0NgYpDxFBMPH+FneYA+/79e+InNsYJRYdkLBWRLTt+mrj28Dgyqu7kvux6?= =?us-ascii?Q?NgrsMEHMC4UAwW4tgsLoBkw4P66fQsDwq+s8FtsbEiBsUpTTK/2qF3MgCcjq?= =?us-ascii?Q?NHsyL6PzkBsfKyrJBeWMhM6RpP0W22H7NS8yvGvWWX2URdXDB1SkH1JwCZSC?= =?us-ascii?Q?IEgjnb0oUlYEhs4oadpO4dbLKnBNCA3H4Zj4svC9YXyXrVOirJWMCdkaVr4M?= =?us-ascii?Q?25XZ2yzhhu+eO4PfQ7g81Q5njNe7efOBBcQrXlfxMnPkY+yErMW/jtT5OOdT?= =?us-ascii?Q?is2Uuz1tSwZY1myAVEqK2ypUN8digseqdlHh8gVnzqgf83vcvWdpRdNMa4qw?= =?us-ascii?Q?83dtu2W1tO2sQ7z8JQyrLRuULkIJjLks7Q4kmAEodmcsCc6ZFN202dv0IveQ?= =?us-ascii?Q?J2289GaUe6iRB2QIsUuZQu5I9/SDsLgouhSrV/mkHZaQ3/7H7Fc9pYxqqWrI?= =?us-ascii?Q?ZBNm8ciW/tDBIHHx775oUeYt3oB8/904TC2aFASZMuPWlk29OAS4i3lDaXa+?= =?us-ascii?Q?j1vx9A9cy6//VzagIy8J3RgFR09WTYJ4fXWBqaddxPFVuTcO9m+LdBnD9xgl?= =?us-ascii?Q?7jKFjeSW5enAi0XLXkBI+i6dG5NPdmdy7cQ5ZSkaPtKmM68NH+91YubBV9ch?= =?us-ascii?Q?KWSCiWCz8rEzsqTIxDy38lSjyDEhebGZfThVzbQAwaHzrXayzBEiRMIc3TiP?= =?us-ascii?Q?OD6CV8tLh9sRzRwUWklWjzm7HvQtIAC+FlHNaylVjin5iFFfkptXUuuTQWm/?= =?us-ascii?Q?EVLa+njBGoQkbqxiwzNat/qK+PCGpbuFFuerXuOyYct9dEOHQyDEVnt8AOxv?= =?us-ascii?Q?qclsTP07S/QLEUKZ/iEU1/C9treZKYVmX/YTlzYoFHR5a5ENmTPTh9pEX+Oe?= =?us-ascii?Q?7OEPR71fa/amkN5+e4Mq78eTwVv1Ycy9HetiX/cAhFcE/knZS0JLWBKFmWrO?= =?us-ascii?Q?UcGQKuAzE5IeojLVkHcv6H1Dm7vcE7XtaW+0Ve35FoUUYe/LtkFKZzyEMC59?= =?us-ascii?Q?jtxq5+E+kE0Yd3NpVEswNs2+CI0ITVBga7nIwT5i1zjgy17u/GkjO/mX5dkC?= =?us-ascii?Q?2MJ2SZVsu1j8SW2Zygxstmzb7Q+It+e/R5+hQnwANJMdIBNWCfvVi2J12kTf?= =?us-ascii?Q?sjPVmiGSwGMqEl1B+3OMreM2yeTXNiOXaE9itGmXIvLt3i+SWBXJiHPKSn6F?= =?us-ascii?Q?Wkth5ZIhdqE+n1iEj3+WSIfSjB0nkSNlMRsylgQnkvqPIMEZaBh1ykzSyGTV?= =?us-ascii?Q?3QK0DIDec8C1UkeNoZezVLeMczsvIKx6ptPk6Bv5z1qOn0CvABLVV1sPj4xT?= =?us-ascii?Q?xXQQOFhm1bpPxSnUQO9tXqHYffWGSa5u+RV8EcFD?= Content-Type: multipart/alternative; boundary="_000_CO1PR05MB83149668ABEA3EB3E525ADF3D51F2CO1PR05MB8314namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58557d0b-0c7d-4d72-7878-08dc6b54136f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2024 09:33:22.7184 (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: OaSJJL5udvw8WvM3KxPgdeuVgIrcP0xPUEvr5SEncWI2yYjvWRGoL7rJbACptfQPQ6ve+7J60bMXZAIX4XQCIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8767 X-Proofpoint-ORIG-GUID: txFFZ-HOqLSwAHVMe_jyZ7upxQLHL6N4 X-Proofpoint-GUID: txFFZ-HOqLSwAHVMe_jyZ7upxQLHL6N4 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-05-03_05,2024-05-03_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 lowpriorityscore=0 bulkscore=0 mlxscore=0 adultscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 clxscore=1011 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2404010003 definitions=main-2405030069 Archived-At: Subject: Re: [mpls] Initial AD review for https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/ X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2024 09:33:34 -0000 --_000_CO1PR05MB83149668ABEA3EB3E525ADF3D51F2CO1PR05MB8314namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi James, Thanks for careful review and comments. Pls find replies inline . Version -13 addresses your comments. Rgds Shraddha Juniper Business Use Only From: James Guichard Sent: Monday, April 22, 2024 5:28 PM To: draft-ietf-mpls-spring-inter-domain-oam@ietf.org Cc: mpls-chairs@ietf.org; mpls@ietf.org Subject: Initial AD review for https://datatracker.ietf.org/doc/draft-ietf-= mpls-spring-inter-domain-oam/ [External Email. Be cautious of content] Dear authors, I have completed my initial review of draft-ietf-mpls-spring-inter-domain-o= am-12 with the following comments: General Comment: - You use Segment Routing, SR, Segment-routing, terms throughout the docume= nt. Please choose one, perhaps expand Segment Routing (SR) on first use and= then simply use SR throughout the rest of the document. Done 20 The Routing (SR) architecture leverages source routing and tunnelin= g 21 paradigms and can be directly applied to the use of a Multiprotocol 22 Label Switching (MPLS) data plane. A network may consist of multip= le Jim> Insert 'Segment' before 'Routing' above. What are 'tunneling paradigms= '? Suggest to remove this as in its simplest form SR simply leverages sourc= e routing. Also, it is not necessary to expand on MPLS above as it is a wel= l-known abbreviation as per https://www.rfc-editor.org/materials/abbrev.exp= ansion.txt. I would simply= shorten the above sentence to "The Segment Routing (SR) architecture lever= ages source routing and can be directly applied to the MPLS data plane (SR-= MPLS).". Then start the next sentence 'An SR-MPLS network...'. Done 23 IGP domains or multiple Autonomous Systems(ASes) under the control = of 24 the same organization. It is useful to have the Label Switched Pat= h 25 (LSP) ping and traceroute procedures when an SR end-to-end path spa= ns 26 across multiple ASes or domains. This document describes mechanism= s Jim> Perhaps replace 'spans across' with 'traverses'? ok. 27 to facilitate LSP ping and traceroute in inter-AS/inter-domain SR- Jim> Replace 'inter-AS/inter-domain' with 'inter-AS and inter-domain' Done 28 MPLS networks in an efficient manner with a simple Operations, 29 Administration and Maintenance (OAM) protocol extension which uses 30 data plane forwarding alone for forwarding echo replies on transit 31 nodes. Jim> It is unclear to me what 'uses data plane forwarding alone for forward= ing echo replies on transit nodes' means. How else would you do it given th= e current state of the art for MPLS LSP ping and trace route? I would simpl= y end the sentence after 'protocol extension'. RFC7743 defines another way of solving the interdomain problem but in = this mechanism return traffic reaches control plane at anchor nodes and the= n gets forwarded. Since the mechanism described in this document uses forwo= rding plane only for return packet. This sentence was added to justify, thi= s propses a different mechanism. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", an= d 37 "OPTIONAL" in this document are to be interpreted as described in B= CP 38 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. Jim> Please remove the above requirements language section as it does not b= elong here. You have correctly inserted it as Section 1.2 after the introdu= ction section. Done 116 1. Introduction 118 Many network deployments have built their networks consisting of 119 multiple ASes either for the ease of operations or as a result of 120 network mergers and acquisitions. Segment Routing can be deployed = in 121 such scenarios to provide end-to-end paths, traversing multiple 122 Autonomous systems(ASes). These paths consist of Segment Identifie= rs 123 (SIDs) of different types as per [RFC8402]. Jim> I am not sure of the relevance of the last sentence above (?). Does th= e ability to carry different types of SIDs have any bearing on how OAM exte= nsions are defined in this document? If not then I would remove the sentenc= e or if it is relevant expand to explain why. Removed last sentence 125 [RFC8660] specifies Segment Routing with an MPLS data plane. 126 [RFC9087] describes BGP peering SIDs, which will help in steering Jim> This is not strictly true. BGP peering SIDs are defined in [RFC8402] a= nd [RFC9087] describes BGP egress peer engineering - how BGP peering SIDs m= ay be used and advertised using BGP-LS. Updated 130 +----------------+ 131 | Controller/PMS | 132 +----------------+ 134 |---AS1-----| |------AS2------| |----AS3-= --| 136 ASBR2----ASBR3 ASBR5------ASBR7 137 / \ / \ 138 / \ / \ 139 PE1----P1---P2 P3---P4---PE4 P5---P6--= PE5 140 \ / \ / 141 \ / \ / 142 ASBR1----ASBR4 ASBR6------ASBR8 Jim> Is the above figure as intended or is PE4 a typo? You have PE4 directl= y connected to ASBR5/ASBR6 - wouldn't this typically be a P router or is th= ere some nuance to have a PE directly attached to an ASBR that you are tryi= ng to convey? There is no special nuance related to PE4 described in the document. I would leave it as is because real world networks are far from text book t= opologies. 152 For example, Figure 1 describes an inter-AS network scenario 153 consisting of ASes AS1, AS2 and AS3. AS1, AS2 and AS2 are Segment Jim> Typo 'AS2' change to 'AS3' above. Done 205 The current document is focused on the inter-domain use case. 206 However, the protocol extensions described in this document may be 207 applied to indicate the return path for other use cases as well. Jim> I would add a sentence to make it clear that these other use cases are= out-of-scope for this document and therefore not further described. Done 221 capable. It is also applies to SR-MPLS networks where SR acts an a= n Jim> Remove 'is' and replace 'an' with 'as' above. Done 256 3. Reply Path TLV Jim> To be more specific, [RFC7110] defines the 'Reply Path (RP) TLV'. Plea= se correct the reference here and elsewhere in the document. Done 263 the reply mode is set to 5 (Reply via Specified Path), and Reply Pa= th Jim> Please update the above to make it clear that reply mode (5) is define= d in [RFC7110] Section 4.1. Done 290 4. Segment Sub-TLV 292 [RFC9256] defines various types of segments. The types of segments Jim> I would change the above to read 'Section 4 of [RFC9256] defines vario= us segments types. Also, it is very unclear, at least to me, why the segmen= t types in [RFC9256] cannot be re-used e.g. how does Type A [RFC9256] diffe= r from Type A (SID only) defined in this document? Is the intent to update = [RFC9256] with these new segment types? If not, why not? You appear to defi= ne your own segment types in this document but do not indicate why [RFC9256= ] differs and/or cannot be updated with the segment types that you want to = be used specifically for OAM. Reuse of RFC 9256 directly was discussed within the WG. The type lengt= h field is one byte in BGP where as is it it 2 bytes in the TLVs defined fo= r OAM. It was concluded to redefine the applicable segment type sub-TLVs fo= r OAm purposes by keeping the TLV definition inline with other OAM sub-TLVs= . 330 Length is 8. Jim> 8 what? Octets? Please specify what portion of the Sub-TLV is covered = by the length. done. Length is 8 octets. The length excludes the length of the the Type and Leng= th Fields 499 A-Flag applies to Segment Type-C and Type-D. If A-Flag appears wit= h 500 Type-A Segment Type, it MUST be ignored. Jim> The last sentence does not seem necessary as in a Type-A that is the R= ESERVED field that MUST be set to zero and MUST be ignored upon receipt. If= you agree remove the sentence. Flags field is there in Type A segment as well so if its set MUST be i= gnored.I feel its relevant. Not sure what I am missing. 504 SRv6 dataplane is not in the scope of this document. Jim> Is there a separate document for SRv6? If so please provide a referenc= e. I am not aware on any 574 code is "Use Reply Path TLV in the echo reply for building the next 575 echo request", the Reply Path TLV from the echo Reply MUST be sent = in Jim> Please make it clear in the text that the stated Reply Path return cod= e is defined in THIS document and not [RFC7110]. ok 580 7. Detailed Example 582 The example topology given in Figure 1 will be used will be used in Jim> Remove duplicate 'will be used' text above. Done 583 the below sections to explain LSP ping and traceroute procedures. 584 The PMS/Head-end has a complete view of topology. PE1, P1, P2, ASB= R1 585 and ASBR2 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are i= n 586 AS2. 588 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 589 used to flood SIDs in each AS. The ASBR1, ASBR2, ASBR3 and ASBR4 590 advertise BGP EPE-SIDs for the inter-AS links. Topology of AS1 and 591 AS2 are advertised via BGP-Link State (BGP-LS) to the controller/PM= S 592 or Head-end node. The EPE-SIDs are also advertised via BGP-LS as 593 described in [RFC9086]. The example uses EPE-SIDs for the inter-AS 594 links but the same could be achieved using adjacency-SIDs advertise= d 595 for a passive IGP link. 597 The description in the document uses below notations for Segment 598 Identifiers(SIDs). 600 Node SIDs: N-PE1, N-P1, N-ASBR1 N-ABR1, N-ABR2etc. Jim> There is no ABR2 in Figure 1 - I assume you mean ASBR2 - please correc= t the text. Removed N-ABR1, N-ABR2 606 Let us consider a traffic-engineered path built from PE1 to PE4 wit= h 607 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 608 for following procedures. This stack may be programmed by 609 controller/PMS or Head-end router PE1 may have imported the whole 610 topology information from BGP-LS and computed the inter-AS path. Jim> Is the above paragraph needed given that the next sections repeat the = example? If not please remove the paragraph. done Thanks! Jim --_000_CO1PR05MB83149668ABEA3EB3E525ADF3D51F2CO1PR05MB8314namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi James,

 

Thanks for careful review and comments.

Pls find replies inline <SH>.

Version -13 addresses your comments.

 

Rgds

Shraddha

 


Juniper Business Use Only

From: James Guichard <james.n= .guichard@futurewei.com>
Sent: Monday, April 22, 2024 5:28 PM
To: draft-ietf-mpls-spring-inter-domain-oam@ietf.org
Cc: mpls-chairs@ietf.org; mpls@ietf.org
Subject: Initial AD review for https://datatracker.ietf.org/doc/draf= t-ietf-mpls-spring-inter-domain-oam/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black;mso-ligatures:none">[External Email. Be cautious of content]

=  

Dear authors,

 

I have completed my initial review of draft-ietf-mpl= s-spring-inter-domain-oam-12 with the following comments:

 

General Comment:

 

- You use Segment Routing, SR, Segment-r= outing, terms throughout the document. Please choose one, perhaps expand Se= gment Routing (SR) on first use and then simply use SR throughout the rest = of the document.

<SH> Done

 

20=       The Routing (SR) architecture leverages source ro= uting and tunneling

21=       paradigms and can be directly applied to the use = of a Multiprotocol

22=       Label Switching (MPLS) data plane.  A network may consist of multiple

 

Jim>= Insert ‘Segment’ before ‘Routing’ above. What are = ‘tunneling paradigms’? Suggest to remove this as in its simples= t form SR simply leverages source routing. Also, it is not necessary to exp= and on MPLS above as it is a well-known abbreviation as per https://www.rfc-edi= tor.org/materials/abbrev.expansion.txt. I would simply shorten the above sentence to “The Segment Routing (S= R) architecture leverages source routing and can be directly applied to the= MPLS data plane (SR-MPLS).”. Then start the next sentence ‘An = SR-MPLS network…’. <= o:p>

<SH> Done

 

23=       IGP domains or multiple Autonomous Systems(ASes) = under the control of

24=       the same organization.  It is useful to have the Label Switched Path

25=       (LSP) ping and traceroute procedures when an SR e= nd-to-end path spans

26=       across multiple ASes or domains.  This document describes mechanisms

 

Jim> Perhaps replace ‘spans acr= oss’ with ‘traverses’?

<SH> ok.

 

27=       to facilitate LSP ping and traceroute in inter-AS= /inter-domain SR-

 

Jim> Replace ‘inter-AS/inter-do= main’ with ‘inter-AS and inter-domain’<= /p>

<SH> Done

 

28=       MPLS networks in an efficient manner with a simpl= e Operations,

29=       Administration and Maintenance (OAM) protocol ext= ension which uses

30=       data plane forwarding alone for forwarding echo r= eplies on transit

31=       nodes.

 

Jim> It is unclear to me what ‘= uses data plane forwarding alone for forwarding echo replies on transit nod= es’ means. How else would you do it given the current state of the ar= t for MPLS LSP ping and trace route? I would simply end the sentence after ‘protocol extension’. 

<SH> RFC7743 de= fines another way of solving the interdomain problem but in this mechanism = return traffic reaches control plane at anchor nodes and then gets forwarde= d. Since the mechanism described in this document uses forwording plane only for return packet. This sentence was added to j= ustify, this propses a different mechanism.

 

33=     Requirements Language

 

35=       The key words "MUST", "MUST NOT&qu= ot;, "REQUIRED", "SHALL", "SHALL NOT",=

36=       "SHOULD", "SHOULD NOT", "= ;RECOMMENDED", "NOT RECOMMENDED", "MAY", and

37=       "OPTIONAL" in this document are to be i= nterpreted as described in BCP

38=       14 [RFC2119] [RFC8174] when, and only when, they = appear in all

39=       capitals, as shown here.

 

Jim> Please remove the above requirem= ents language section as it does not belong here. You have correctly insert= ed it as Section 1.2 after the introduction section. 

<SH> Done

 

116   1.  Introduction

 

118     Many network deployments have built their network= s consisting of

119     multiple ASes either for the ease of operations o= r as a result of

120     network mergers and acquisitions.  Segment Routing can be deployed in

121     such scenarios to provide end-to-end paths, trave= rsing multiple

122     Autonomous systems(ASes).  These paths consist of Segment Identifiers=

123     (SIDs) of different types as per [RFC8402].

 

Jim> I am not sure of the relevance o= f the last sentence above (?). Does the ability to carry different types of= SIDs have any bearing on how OAM extensions are defined in this document? = If not then I would remove the sentence or if it is relevant expand to explain why.

<SH> Removed last sentence<= o:p>

 

125     [RFC8660] specifies Segment Routing with an MPLS = data plane.

126     [RFC9087] describes BGP peering SIDs, which will = help in steering

 

Jim> This is not strictly true. BGP p= eering SIDs are defined in [RFC8402] and [RFC9087] describes BGP egress pee= r engineering - how BGP peering SIDs may be used and advertised using BGP-L= S. 

<SH> Updated

 

130       &n= bsp;               +----------------+

131       &n= bsp;               | Controller/PMS |

132       &n= bsp;               +----------------+

 

134     |---AS1-----|                |------AS2------|            |----AS3---|

 

136       &n= bsp;           ASBR2----ASBR3                ASBR5------ASBR7

137       &n= bsp;           / &n= bsp;           \   &n= bsp;           /  &nb= sp;         \

138       &n= bsp;           / &n= bsp;             \ &n= bsp;           /  &nb= sp;           \

139     PE1----P1---P2                 P3---P4---PE4              P5---P6--PE5

140       &n= bsp;           \ &n= bsp;             /&nb= sp;           \   &n= bsp;           /

141       &n= bsp;           \ &n= bsp;           /  &nb= sp;           \   &n= bsp;         /

142       &n= bsp;             ASBR1----ASBR4              ASBR6------ASBR8

 

Jim> Is the above figure as intended = or is PE4 a typo? You have PE4 directly connected to ASBR5/ASBR6 - wouldn&#= 8217;t this typically be a P router or is there some nuance to have a PE di= rectly attached to an ASBR that you are trying to convey?

<SH> There is no special nuance re= lated to PE4 described in the document.

I would leave it as is because real worl= d networks are far from text book topologies.

 

152     For example, Figure 1 describes an inter-AS netwo= rk scenario

153     consisting of ASes AS1, AS2 and AS3.  AS1, AS2 and AS2 are Segment

 

Jim> Typo ‘AS2’ change to= ‘AS3’ above.

<SH> Done

 

205     The current document is focused on the inter-doma= in use case.

206     However, the protocol extensions described in thi= s document may be

207     applied to indicate the return path for other use= cases as well.

 

Jim> I would add a sentence to make i= t clear that these other use cases are out-of-scope for this document and t= herefore not further described.

<SH> Done

 

221     capable.  It is also applies to SR-MPLS networks where SR acts an = an

 

Jim> Remove ‘is’ and repl= ace ‘an’ with ‘as’ above.

<SH> Done

 

256   3.  Reply Path TLV

 

Jim> To be more specific, [RFC7110] d= efines the ‘Reply Path (RP) TLV’. Please correct the reference = here and elsewhere in the document.

<SH> Done

 

263     the reply mode is set to 5 (Reply via Specified P= ath), and Reply Path

 

Jim> Please update the above to make = it clear that reply mode (5) is defined in [RFC7110] Section 4.1.

<SH> Done

 

290   4.  Segment Sub-TLV

 

292     [RFC9256] defines various types of segments.  The types of segments

 

Jim> I would change the above to read= ‘Section 4 of [RFC9256] defines various segments types. Also, it is = very unclear, at least to me, why the segment types in [RFC9256] cannot be = re-used e.g. how does Type A [RFC9256] differ from Type A (SID only) defined in this document? Is the intent to update [= RFC9256] with these new segment types? If not, why not? You appear to defin= e your own segment types in this document but do not indicate why [RFC9256]= differs and/or cannot be updated with the segment types that you want to be used specifically for OAM.=

<SH> Reuse of RFC 9256 directly wa= s discussed within the WG. The type length field is one byte in BGP where a= s is it it 2 bytes in the TLVs defined for OAM. It was concluded to redefin= e the applicable segment type sub-TLVs for OAm purposes by keeping the TLV definition inline with other OAM sub-TLVs.=

 

 

330     Length is 8.

 

Jim> 8 what? Octets? Please specify w= hat portion of the Sub-TLV is covered by the length.

 

<SH> done.

Length is 8 octets. The length excludes the length of the t= he Type and Length Fields

 

499     A-Flag applies to Segment Type-C and Type-D.  If A-Flag appears with

500     Type-A Segment Type, it MUST be ignored.

 

Jim> The last sentence does not seem = necessary as in a Type-A that is the RESERVED field that MUST be set to zer= o and MUST be ignored upon receipt. If you agree remove the sentence.<= /o:p>

<SH> Flags field is there in Type = A segment as well so if its set MUST be ignored.I feel its relevant. Not su= re what I am missing.

 

 

504     SRv6 dataplane is not in the scope of this docume= nt.

 

Jim> Is there a separate document for= SRv6? If so please provide a reference.

<SH> I am not aware on any<= o:p>

 

574     code is "Use Reply Path TLV in the echo repl= y for building the next

575     echo request", the Reply Path TLV from the e= cho Reply MUST be sent in

 

Jim> Please make it clear in the text= that the stated Reply Path return code is defined in THIS document and not= [RFC7110].

<SH> ok

 

580   7.  Detailed Example

 

582     The example topology given in Figure 1 will be us= ed will be used in

 

Jim> Remove duplicate ‘will be = used’ text above.

<SH> Done

 

583     the below sections to explain LSP ping and tracer= oute procedures.

584     The PMS/Head-end has a complete view of topology.=   PE1, P1, P2, ASBR1

585     and ASBR2 are in AS1.  Similarly ASBR3, ASBR4, P3, P4 and PE4 are in

586     AS2.

 

588     AS1 and AS2 have Segment Routing enabled.<= span class=3D"apple-converted-space">  IGPs like OSPF/ISIS are

589     used to flood SIDs in each AS.  The ASBR1, ASBR2, ASBR3 and ASBR4

590     advertise BGP EPE-SIDs for the inter-AS links.  Topology of AS1 and

591     AS2 are advertised via BGP-Link State (BGP-LS) to= the controller/PMS

592     or Head-end node.  The EPE-SIDs are also advertised via BGP-LS as

593     described in [RFC9086].  The example uses EPE-SIDs for the inter-AS=

594     links but the same could be achieved using adjace= ncy-SIDs advertised

595     for a passive IGP link.

 

597     The description in the document uses below notati= ons for Segment

598     Identifiers(SIDs).

 

600     Node SIDs: N-PE1, N-P1, N-ASBR1 N-ABR1, N-ABR2etc= .

 

Jim> There is no ABR2 in Figure 1 - I= assume you mean ASBR2 - please correct the text.

<SH> Removed N-ABR1, N-ABR2=

 

606     Let us consider a traffic-engineered path built f= rom PE1 to PE4 with

607     Segment List stack as below.  N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4=

608     for following procedures.  This stack may be programmed by=

609     controller/PMS or Head-end router PE1 may have im= ported the whole

610     topology information from BGP-LS and computed the= inter-AS path.

 

Jim> Is the above paragraph needed gi= ven that the next sections repeat the example? If not please remove the par= agraph.

<SH> done

Thanks!

 

Jim

--_000_CO1PR05MB83149668ABEA3EB3E525ADF3D51F2CO1PR05MB8314namp_--