From james.n.guichard@futurewei.com Mon Apr 22 04:58:42 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 094CAC14F618; Mon, 22 Apr 2024 04:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (1024-bit key) header.d=futurewei.com 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 4bT6UmOHIh4m; Mon, 22 Apr 2024 04:58:37 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2092.outbound.protection.outlook.com [40.107.243.92]) (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 80DA6C14CF1B; Mon, 22 Apr 2024 04:58:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W7tdwbU3969UUft7MwcYkh8S6dRgcNG50hZbLH4Gck2bM20rJ0OoyYvZgZDeLm7DenzoMYhodZ6CKNCz9pdEkX2G4wrf8jt4/uyrLkw24MJB8sMULOVpVRqYWDxBXGb8zm2DMnLXMrT436SK6nPC6y+5xRq0LuwH9pChhdpmr0VS5csnYgI9o1SXi2wODJdxiv0YApGEtRy9pFqNzNsm3Yg/C9cUihDAmm6dN6nU2CKSGni/p9tDHjSFXqIYD71xYoHqXK5Lp4CeDXFBSFUqIUxbJF2kIIM+c1KqD9L2++k2w7P5h3NiOYcrDZHeHa9ueRAkQF6WPvF1cA3zhjeZ9w== 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=VDOI65fJK9CJMdbqXHoKJepJOv30AWyPAVNeC4Z1QBY=; b=ZqUmK/pXWNjINgG1IF0fX8yyC5Tkv8+5acni53gorvxm1TWbG7FbYvyNhskgREnKEgWyGN6bZJYdlo+JLEc1qkVDZsKv8jXFzVeqQY8Cf7FI6WHCbQYGFt4aH6ksLmdnd+ZBAV5lbPlIrdcCyQE0VHQOXerTd9UOkkw2G+BHD8TCJdmPW0jQakf9gOAJ0ZSTQLMWo32kA6mDmkz/mHwUPgeeGSxdyOOHqbXxiI5bTP3Hgj+fr5/rBj5CbTZyEGXs2HOH4Zea6gaFaOY0ATji0jj0WPQyo1omjT9LGI3DoB5ffWgkMjEFHMgPb2qBAkz/plE8NTD0MqQlTA0CVM3baQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VDOI65fJK9CJMdbqXHoKJepJOv30AWyPAVNeC4Z1QBY=; b=ITFr7q6Gc7KnpWxXhR2XVGpoeRJTnbSKa6Z+Vd3hP2vFLsDE0VWchwwW/C0ej9gQD0OsVC0s5BXQejBjMkuXY/EOYphjcqln8y+kN4Dg4WMYVc588SZGLfrFmWeZYutDDobHnmM1Q3iifpPHp/zesfcarx0daUf73DJEjQG6b5A= Received: from MW5PR13MB5485.namprd13.prod.outlook.com (2603:10b6:303:190::9) by CH0PR13MB5154.namprd13.prod.outlook.com (2603:10b6:610:ff::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7472.44; Mon, 22 Apr 2024 11:58:26 +0000 Received: from MW5PR13MB5485.namprd13.prod.outlook.com ([fe80::2e78:76d4:8ed8:4091]) by MW5PR13MB5485.namprd13.prod.outlook.com ([fe80::2e78:76d4:8ed8:4091%7]) with mapi id 15.20.7472.044; Mon, 22 Apr 2024 11:58:26 +0000 From: James Guichard To: "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+PMYoQ== Date: Mon, 22 Apr 2024 11:58:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW5PR13MB5485:EE_|CH0PR13MB5154:EE_ x-ms-office365-filtering-correlation-id: 5b5b2871-5a36-4a55-c90c-08dc62c3848f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: =?Windows-1252?Q?awQ3xFzIVrb1Y3MaXex0S0EMnh+eA4wYLeDJ3KZlYqctfbYuOoNvAEsI?= =?Windows-1252?Q?wW4LgW2cwXL4pjj6dHU+qnOlCpLxrnaj/bqKQMM1qFHl0oWR7/OzyKvc?= =?Windows-1252?Q?2S5UexhdNo74pMr2h7SELPcwkltqMB/R6KC15/kA0+hNgeIQ57VWUF+D?= =?Windows-1252?Q?bcaCQTebIOMuWVw8AdpxrM4M09sT4Iepq4Mm5N5glwOXgr8NOh6McioJ?= =?Windows-1252?Q?uAviypMscF88J52dVbPXwBKbJ20tkOgavw/6z9rIJxua8qseLx4K4Z0R?= =?Windows-1252?Q?Ko+QI3+cKneYLv4MXZ3hxvvX7B8IciWpjqKdWQkiprlYrE8rkBLzwrHc?= =?Windows-1252?Q?N5idXdiNelYtbMHBIok63R+6f9DoRTxu7S6cd+Dp3T4Ne3M7HdXATFvj?= =?Windows-1252?Q?DX/VnCjBPhCqQ1WEDLETRHZ0wrzjsEMZEFnEgssmsOgUfwyEtF/60R2a?= =?Windows-1252?Q?y9EC02V84uk3qEXYJ9hvIAWeRAbf8Z4uSWZgB8bt/Z1JK3BPAxzrNfwB?= =?Windows-1252?Q?cMt1eaKRAh+ScfSyWIeedDMRvzxZvV/jAWC/uaHxIlL9IEtv+VvWseY+?= =?Windows-1252?Q?BIPSVsFYCgotv4F/JwCHlGZaiCnvaS0ukUhVNQHe/r72NYiZA7VnFX5k?= =?Windows-1252?Q?0M1t24uUJH1U0ZMXGSYzj7RZCCu0Eq2tU7hTF4WOpev5BVuCRuwYNSYa?= =?Windows-1252?Q?2HPfIdE7JZkickwgppn0+VOD/yRnb530s29SjSM0Xxk03NfpxDEMZuBi?= =?Windows-1252?Q?q7gMSd5a+lbca75VkaCvBYSIaOKQXfbw1qLYZhltln65WM7Mg+BAC+Ti?= =?Windows-1252?Q?CsE12f6/vgt8Z68VGq0wpppCsQYvllaMtM1UHKtziXCh2D5D2056cNZk?= =?Windows-1252?Q?ILn0dkECqXbvhrmjmvi2M1POV86efNWf3NzYXbmZql15yILG/CcaafUx?= =?Windows-1252?Q?DYuMOIkIYUJZk74xO4aSQrNS6eR6aa+BNRtVXHTXTrrism0Bw3VgKT86?= =?Windows-1252?Q?Bx6eyYfhUrxdZ2rjujm99NfiooEsvrntPBfaMjseBwAUywj2npPMvata?= =?Windows-1252?Q?d6DvOoLiZy5Nm5CNjHcb8ILR8w6dA9M8Ee7SNKo0Si9tRH0o7jT53qvy?= =?Windows-1252?Q?MR3HTRGU1uow/6OZqfggppZr4wn8IVEQFwDWJqM6JmVaB/7h3d60WJsq?= =?Windows-1252?Q?VvWTg36iTcibDpPJFvbiZIOoScLB7y3NPhP4Uk+oSk8l++5L190GgE8U?= =?Windows-1252?Q?WwDPg1UtMtvlD0gPZu2JIQ9UwsO6HSuUTuI81MMF+K/r+6j1vr0i0ccm?= =?Windows-1252?Q?ndDk8bJqdFyoU7DiH9cj71cjrIaC3LBNl/7qz8J6Mamgzuzgk0cjmTM1?= =?Windows-1252?Q?ckzJES28mrDfIw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW5PR13MB5485.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(376005)(366007)(38070700009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?DlxHGETDmGuzu1MUL15Q3BCjd79+1ES3xjWxnYxRdjntSeR1TbjJBpWd?= =?Windows-1252?Q?rxCgdWXUWHTeKCDb6VavuCNcX/U7mUmzKzRnLd2dMiJhVGAMRNNN+Nk+?= =?Windows-1252?Q?SXAe0rFfyqybPdinfQ1knMAxPwBQ36F69mi4R0s5TgSrtNjmw3icCzaQ?= =?Windows-1252?Q?ElzNhkTbNPngMNliJIARHVdW54Fnw/UpAPfapxXLMNA4NnBmZ57OBRnA?= =?Windows-1252?Q?4HyqNH3YGr9NhYUNlibZgOweOxu0sU+RSIK8IN8pYN2FqHz5QE7zOm35?= =?Windows-1252?Q?7F09ngchZpRSnIkoWRUg7nfzOlSCjUhCF7A/SnwSgXoV+BmiJamlfEIF?= =?Windows-1252?Q?WBq9uY8eH8oRh7vKrAHUEmRxpymunqauQZ+D8xVetiS8gqN1hCnYEiBi?= =?Windows-1252?Q?1to9eGttaibYYZ2Xg+ScOi5wG4eEijb0PumdwCuPgAbOE2WGqQ9FplCC?= =?Windows-1252?Q?olC/2DVH5/pAeFU5H+cAsKWFY974zQ0Q9ZwPxy1tJ+/+oLjWWial8fwh?= =?Windows-1252?Q?00591jWLRrbw5xqf2EXiiCTViMxsHQgyy9sgWRx4UziR4eH+PL9ejqJ6?= =?Windows-1252?Q?8qLniZv0YOY2huBYKC8CRAHZ36mbQFmaRKjhf4aUji7kmWv7NqRLPlf7?= =?Windows-1252?Q?xjQ7EgC0yzvJzGT5uxQOIibbyJiqXEoDZ9sNw5srl6Dqm9GiL+ZPlTtv?= =?Windows-1252?Q?MLvEcRoDOPrV//jvpI/sJgJF04Q8rczDLVhIeaBbBHHnLPd52y9yq7ce?= =?Windows-1252?Q?EKl6Mou90KBsWBYEnnIaPPzY8PVVIOdvRAztj/MtEFR00JlijRmSq5ia?= =?Windows-1252?Q?PzBd2rGweN1+O/wLgxISi465re+DLuVo7QeOgUJ6pmaJ8h9TOUH4Ll+P?= =?Windows-1252?Q?PZbe8IEEz/00O0pEBNxx4bARrP1AXPSdx6eApVs6sTONAP96dvLzW2wG?= =?Windows-1252?Q?D1iqlbsBW7TLcCa3YM0KvRvTd0ng8c3h0AmW2O42G/jk7L/Zg2MU/2VK?= =?Windows-1252?Q?+JcWOOWdVdA3s8qNpHjIlScqQDpoAR60d1g0arJhgF6WsTm2lcd+pk57?= =?Windows-1252?Q?w4NQqJUXFRobwquYGkLWITjRSkbTIyEkbtpP7i5qOabvF2qrrFV0BFBo?= =?Windows-1252?Q?Tt9+ZNh/beAdn6xxVdMqQa423g+uzXYaPotmgbuOcV26PIXSopyJMeQU?= =?Windows-1252?Q?KkL7vOlURYlQIJcc301xW+ZmvAArcxM+tdCb42kAMfXJFIuAQumTLfC8?= =?Windows-1252?Q?osvP3CSMc3rE1xx2qjjRn/i6sdVUwAz9q12xMqcDxUO2UgzcZqaWyWYw?= =?Windows-1252?Q?Kvc7rhOfQvvBpMSpUkKi1WgnjonJOjcCbtZWHjukhhLaxRZlAhFkCxWq?= =?Windows-1252?Q?iPqHNMRD41/6EnU4WRDfy1HUHRT62aAzrLjRkP5+z+Vh9HpjdQUxslRR?= =?Windows-1252?Q?i/mGyC3iJtKktVkyZklL2RqF1H+KcZvzRm8gsBmBnFuuv67FMduy+SXy?= =?Windows-1252?Q?jKmSBYZf3ShAnoT+rfJTF6YcA6k/WITU3GyVYfavs9m4H1KPeDqMHpgv?= =?Windows-1252?Q?F+nNUmci+3Qk1c8MIDanZ2sdo4cVbfQctI92oiRxw8L7R3cthchfbk3s?= =?Windows-1252?Q?J1OFc5xchnqKLD0IaZRX4oYYOc7LLvVSZc46n8jGi025I+Yf/P/ovuM/?= =?Windows-1252?Q?BFjgc3JLYsT6h1WlZhNzgIsaL+NEB9sxswhjhcuI1Vbj6zWphxh93pfk?= =?Windows-1252?Q?mnT3+MkjF+OfXnl7fbh+w6ZISik55hX0XH4FukJItC3yqZi8kVh+Ftuf?= =?Windows-1252?Q?p+Rh3w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW5PR13MB5485917C62AB0A867D34D19DD2122MW5PR13MB5485namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW5PR13MB5485.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b5b2871-5a36-4a55-c90c-08dc62c3848f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2024 11:58:26.1484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QSmo1BquNU+mcPwEJC+rDmveBmC4UL50PJcg+G4cL6bDg4npnQZPRL9uEP0QnK06ttqJLBIuwWfkVc4ACi+09g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR13MB5154 Archived-At: Subject: [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: Mon, 22 Apr 2024 11:58:42 -0000 --_000_MW5PR13MB5485917C62AB0A867D34D19DD2122MW5PR13MB5485namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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. 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 =91Segment=92 before =91Routing=92 above. What are =91tunneling= paradigms=92? Suggest to remove this as in its simplest form SR simply lev= erages source routing. Also, it is not necessary to expand on MPLS above as= it is a well-known abbreviation as per https://www.rfc-editor.org/material= s/abbrev.expansion.txt. I would simply shorten the above sentence to =93The= Segment Routing (SR) architecture leverages source routing and can be dire= ctly applied to the MPLS data plane (SR-MPLS).=94. Then start the next sent= ence =91An SR-MPLS network=85=92. 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 =91spans across=92 with =91traverses=92? 27 to facilitate LSP ping and traceroute in inter-AS/inter-domain SR- Jim> Replace =91inter-AS/inter-domain=92 with =91inter-AS and inter-domain= =92 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 =91uses data plane forwarding alone for forwa= rding echo replies on transit nodes=92 means. How else would you do it give= n the current state of the art for MPLS LSP ping and trace route? I would s= imply end the sentence after =91protocol extension=92. 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. 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. 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. 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=92t this typically be a P router or is = there some nuance to have a PE directly attached to an ASBR that you are tr= ying to convey? 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 =91AS2=92 change to =91AS3=92 above. 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. 221 capable. It is also applies to SR-MPLS networks where SR acts an a= n Jim> Remove =91is=92 and replace =91an=92 with =91as=92 above. 256 3. Reply Path TLV Jim> To be more specific, [RFC7110] defines the =91Reply Path (RP) TLV=92. = Please correct the reference here and elsewhere in the document. 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. 290 4. Segment Sub-TLV 292 [RFC9256] defines various types of segments. The types of segments Jim> I would change the above to read =91Section 4 of [RFC9256] defines var= ious segments types. Also, it is very unclear, at least to me, why the segm= ent types in [RFC9256] cannot be re-used e.g. how does Type A [RFC9256] dif= fer from Type A (SID only) defined in this document? Is the intent to updat= e [RFC9256] with these new segment types? If not, why not? You appear to de= fine your own segment types in this document but do not indicate why [RFC92= 56] differs and/or cannot be updated with the segment types that you want t= o be used specifically for OAM. 330 Length is 8. Jim> 8 what? Octets? Please specify what portion of the Sub-TLV is covered = by the length. 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. 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. 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]. 580 7. Detailed Example 582 The example topology given in Figure 1 will be used will be used in Jim> Remove duplicate =91will be used=92 text above. 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. 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. Thanks! Jim --_000_MW5PR13MB5485917C62AB0A867D34D19DD2122MW5PR13MB5485namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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.

 

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 =91Segment=92 before =91Routing=92 above. What are =91tunneling par= adigms=92? Suggest to remove this as in its simplest form SR simply leverag= es source routing. Also, it is not necessary to expand on MPLS above as it is a well-known abbreviation as per https://w= ww.rfc-editor.org/materials/abbrev.expansion.txt. I would simply shorte= n the above sentence to =93The Segment Routing (SR) architecture leverages source routing and can be directly app= lied to the MPLS data plane (SR-MPLS).=94. Then start the next sentence =91= An SR-MPLS network=85=92. 

 

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 =91spans across= =92 with =91traverses=92?

 

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

 

Jim> Replace =91inter-AS/inter-domain= =92 with =91inter-AS and inter-domain=92

 

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 =91uses= data plane forwarding alone for forwarding echo replies on transit nodes= =92 means. How else would you do it given the current state of the art for = MPLS LSP ping and trace route? I would simply end the sentence after =91protocol extension=92. 

 

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. 

 

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.

 

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. 

 

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

131                     &n= bsp; | Controller/PMS |

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

 

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

 

136                   ASBR2----ASBR3                ASBR5------ASBR7

137                   / &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;           /  &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= =92t this typically be a P router or is there some nuance to have a PE dire= ctly attached to an ASBR that you are trying to convey?

 

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 =91AS2=92 change to =91AS3= =92 above.

 

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.

 

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

 

Jim> Remove =91is=92 and replace =91a= n=92 with =91as=92 above.

 

256   3.  Reply Path TLV

 

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

 

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.

 

290   4.  Segment Sub-TLV

 

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

 

Jim> I would change the above to read= =91Section 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-u= sed 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. 

 

330     Length is 8.

 

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

 

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.

 

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.

 

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].

 

580   7.  Detailed Example

 

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

 

Jim> Remove duplicate =91will be used= =92 text above.

 

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.

 

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.

 

Thanks!

 

Jim

--_000_MW5PR13MB5485917C62AB0A867D34D19DD2122MW5PR13MB5485namp_--