Re: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt

Shraddha Hegde <shraddha@juniper.net> Mon, 12 July 2021 12:21 UTC

Return-Path: <shraddha@juniper.net>
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 6E9913A1274; Mon, 12 Jul 2021 05:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.888
X-Spam-Level:
X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=C7J717PR; dkim=pass (1024-bit key) header.d=juniper.net header.b=TK2NPf6n
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 ZvOnd6k1Rzls; Mon, 12 Jul 2021 05:20:59 -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 F01043A126D; Mon, 12 Jul 2021 05:20:58 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16CCICSp030588; Mon, 12 Jul 2021 05:20:50 -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=FMB33nMjDor7kQVKWCh/u7jdIYLjWVo2M+4uy8d4XwQ=; b=C7J717PRkIS1KBxxv2dsj+FWj6BP7T8jSHPMepiG2tetk987s+3pBtl6q7A7pFDv38Cw JixYP1vIWDCs2msWGeXaLhT/ss0XE7HjerjcNFMAvgYpOT3iTyKSiSMheoAzyjqFCl2c PrVppj0lP/dMUa6ToXmaLCob5lHbTckGRxrEWY6sGQA/w/eF1skTMSneDAkzYRmaNBRo LfUT4zubHDTVyii96O2mrW8fLO+3YoYKYsowY4Gflr4zeBBetyHHZKA7dRQ2l1slUvC8 5/NX0V9HfaF55UdBIrC2zaCLA8qBqrJs3zU4Z9aNCZNp7tWZtVPrh0aBWWEVVdea+fA/ Aw==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2171.outbound.protection.outlook.com [104.47.57.171]) by mx0b-00273201.pphosted.com with ESMTP id 39rk08g94k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 05:20:49 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MTvWcXsQ5yNNWm1IBJbHevxLurqV3KZwX2+SHjkRdIyjXUVd5DGCBHjDQRilDMcjKwcPPKU/AHzs+CzUjiDsynFPulXEbW+g0ThXll1v4miUNxBHUoNdINpFDhHcyQ8LZNVfhMuA+uJv4rtUO0w+kltsOms9KDTokAK85iIsIcDayow+T0Egkc9XytzHL6c991Is7ePLCi+fj4bqDVIAWJQXBV7T02AtdXhuce0JuM6N/76NRBB3urtFrDmPCj9FCwcuI8Vek/6EKO7Id5jInnhrK/14jn72Plt1RSUtex8giQaTsWjpaNAv/b3xDWWTJPOyF8jBJPPYzrmBbbWMkA==
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=FMB33nMjDor7kQVKWCh/u7jdIYLjWVo2M+4uy8d4XwQ=; b=MoPQguKDFfqMDeWAk2xOTrc/02PeL/Y0ZewhitY56GAyskfQ8Oxt5B7f/kqzjYOxv3ARC+WWYv3wtnPAFiuZZGEFkJCwdU226IX0Am7pVsnmM6DHb8ukWzUtqPispf1ay8iyJEdF1FIAUFu2PZNnyxE08q1rfIb2szb+z95v3CiekXk3zsR0sZTxeF5UXWYlGe3osZBH4B5UsFZVu5V4/mICz1ArkH+KxjhVgRm3p0MEc/r8QiD2BelqsN9mqy1PQbYDYKmg2lJ/7NpEFIDxMEUWKETVOHikz0AtOkZHASfButM/l0o29dv88sca20afCpPkTRhooTXEputz6qglwA==
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=FMB33nMjDor7kQVKWCh/u7jdIYLjWVo2M+4uy8d4XwQ=; b=TK2NPf6nZW9s07zbjAIEDFBx6CLyoivfbRzUanZlTNRapjDQ/uwJnaUMOM35d8KrdiMBUJJh+JrlhMK4uz35g0n0GDIwJPLgDrOKOLzY87t3gaamluyaHLaoz/wrnYkl56pqeGmX6nFrhYoATnkoPRy7v+myMykCBwtIZBPwGpY=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3544.namprd05.prod.outlook.com (2603:10b6:910:54::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.12; Mon, 12 Jul 2021 12:20:46 +0000
Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::e89d:19b2:fcb6:8288]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::e89d:19b2:fcb6:8288%7]) with mapi id 15.20.4331.019; Mon, 12 Jul 2021 12:20:46 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>, "mach.chen@huawei.com" <mach.chen@huawei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "huubatwork@gmail.com" <huubatwork@gmail.com>
Thread-Topic: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
Thread-Index: AQHXYLMGcHP4v/TC8kujg5SgKLK6G6sUgImggArQQYCAIBq3cA==
Date: Mon, 12 Jul 2021 12:20:46 +0000
Message-ID: <CY4PR05MB35768DEAE83BD7A53EA82451D5159@CY4PR05MB3576.namprd05.prod.outlook.com>
References: 202106140819542507138@zte.com.cn, BN6PR05MB3569A9553DD5E449ED5B203AD5309@BN6PR05MB3569.namprd05.prod.outlook.com <202106220951199465042@zte.com.cn>
In-Reply-To: <202106220951199465042@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-07-12T12:20:42Z; 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=770760b0-b9bf-4f5b-971e-f022055f9516; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: ztetx.com; dkim=none (message not signed) header.d=none;ztetx.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c55929d5-2ddb-4853-80c0-08d9452f7a39
x-ms-traffictypediagnostic: CY4PR05MB3544:
x-microsoft-antispam-prvs: <CY4PR05MB354453C8EF18DAD2F6EDFC07D5159@CY4PR05MB3544.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7sJvBR68M2nPXAZeDQwJNg6TdJE1MEuVDSuHJ6Q1lA8o5Qa2rLfSA85ZOsAzyNaKcQRTf5eUe9zOT25EgebYU3qOr3/9OjgmAIoKnbbbz/QeBSHD6a07n5SaZBAfvBjPUY0XMSS3LJiUuTI7DxU/bOTJUdqgC0WnC3OtNBCnIylaCt1KA8hfBCPKC5kyzw+jdl+HHA2+ClRD/HB/TUthSZNr87SGQx5UUVUkOmSQeppuUiogjNRsDOHqLIfog+x0DKob7QBUu2W5KDXakLbyqEVXHCDRZWv1IjBPpFLKGq2DiHnDaVfnslF+ADQCRChrU10gY9OOCSg1rDqy6IkhzSsqXbRgnU91TdTlo5++LnH27R/ZG8erbWOtWVfqneSRAOuyyaK8G3OPo54k1nrpUzARAMlGuVUIn/aAkL39wYf0P6J7vV8SIX2cRrb4MwJEGcpjGGrf1cg3iCnFKn7rsBx9KwMvXOCy0D23y8e+x9l6h23gj4Uzn+OhZ/JBMEksEL0JE8qK+R8Oifz9Kmzy3RecomsP0D2Sj31axfsfwZkbABiD+Hhjtpj5MpJB0DfIwXfmsr5PBMG8UpDgFuos2XkQAA7qAm0iDHibQDIy64Cji4OxlQfTEvbzJnF/btNmNH3Nqq8Z65UMj0s+rqe1KPeD8HINJruo/+6Nb4VfuENQA2LariMe75SQfZ3hEJ5aO+YjJFEdq618r/IUQ4BI3w==
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)(39860400002)(366004)(376002)(396003)(346002)(136003)(15974865002)(2906002)(66556008)(66446008)(52536014)(99936003)(66574015)(64756008)(54906003)(26005)(66946007)(66476007)(33656002)(316002)(8676002)(38100700002)(4326008)(186003)(122000001)(86362001)(76116006)(71200400001)(966005)(9686003)(5660300002)(30864003)(478600001)(66616009)(8936002)(55016002)(7696005)(53546011)(6506007)(83380400001)(6916009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: qo9/lXQ8f7mTqyIzpe8NtIjmh6oO9no2gRYdDvAwWPImq6y57WSHq4BBfIAHlImvj1TT/8cwiNYV9nE2nLReRjE8LTuYSFsh4DUWg42dyVNvob6w6iB5HzyGF7IRHEdpqd0Dn47/sHB8EN2/3xxAi8LdiJNc+q8l5dPMEfT6ulQIv7GoQZjDHQ9RqqiVO+SJrj8pt2es6vn0DuhzCsbBnQW5bTCnq2WvcqR5wQ+alcUIdsj6mP6vGRL0l9fXTuooV+7+zZftzQO2c9sjkjqkMp1zUvuWejFWw9+DZbz+RfiM45dZU/+R0qRxkdHAAplPXYnJElDTEwltRsO21Taz2lu8gRgfiCrxNCW1DZgYnvRmk7Y+cpXrze2WfTcEAAy6w0y0+7WX2PYAhGrnTMovD0ZkgrdjaEcZTch6jZNzAsNYvHeDSJtPwqI0ycE/YQZi1hN/qR5Jks4ra9LcQWFCJ9jRXj8My3e4HSMe0dJbs8ADdZ4FZs5iLis4IvcJHK/Tbc2xDjfwqUhNDqTu+mgSw6m8iERVrwZVK1NYPGa5Culh7fvxS7fcnbQXgkfKWAHB2vXd0f+4TxJCFzO/h+3aky7cBATJA37Jld/WAeWK1+jX2XBxy0xTFbxZbFQj7X2MSIQL8zm1I3RN8XUCb68AHyzVagKAGuNpp9qUbjZ/4xqHvaD13l8rIE0okOyDlkJw9m/aosL14bGcnFlQPv+8rD3BuzfA5T2McHMT2SdKZvKqJNsyT7GEVKt6loS8HXxF+05CHP5e73RcsCx1TN40tHphloAYaULI9BFIVjV5995xXrtDGZDRfPdsiYLyJIerBctLVuHsdBrpHTZXHL6pyrCrPsLijbSc3uFSTAD5JGG1KgskAqu9dwiRF2j0GPBAv7NdCqX9NiPmvEO46L6ipzwETjZ5g+pvySUsFZv7FKdrW80jTgFOl8R5BqYKDQf/dFw0AGy6AuIKOqWe7pjajgRAeYwZsP8DsfKcyca40fZDq8O+ELZvjGTulJc2cUZRKFMqr2H1NN0Za8DvcPADZjmcYT1GNvsCHU3HCAmvQHlEykgd9DCcw/lIsBKRil2ISyAtwx0lP026P/Gkn4JNHHCw4MI6Q/vtOBrAnrxE/XIo7dKiy1X1SpQ1R+HQBSh5Q1c7Gh9W8SFgMeJzr+QwpgVJP0jszqxtoHaDyItsg/9Nj2l/VySa1HKhc2w8D0biByTF0NS2/cjKdJC20sMBnxnwamBJ+K1dqkFhv6vMjEyDzuHh1Wj7AQNRrWi1XH55XEjtiHxj3RFty23Ibxz6ruFRiKBOKjjN+KvD2TdMAwMFp/rnUkP9wu5oj+ikdvoq
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_CY4PR05MB35768DEAE83BD7A53EA82451D5159CY4PR05MB3576namp_"
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: c55929d5-2ddb-4853-80c0-08d9452f7a39
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 12:20:46.4515 (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: Ma/oYyON5O9++4hxbfz30LUETtOQ7RuA7kcUHSYQlpmUSqovqVGEqIooqe5+sto1oa6VID2KAMZ48xOmdaKa5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3544
X-Proofpoint-ORIG-GUID: fSBHEgRhifNMguO8rjHUM3xx88Gvjrr3
X-Proofpoint-GUID: fSBHEgRhifNMguO8rjHUM3xx88Gvjrr3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_05:2021-07-12, 2021-07-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=0 impostorscore=0 clxscore=1011 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120096
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Fl__sGmLHTLpHPG-o9fch9aA4Qo>
Subject: Re: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2021 12:21:07 -0000

Hi Greg,

Thanks for your comments.

Snipped...

GIM>> I see that the new text again characterizes RFC 7743 as requiring that an ASBR passes an echo reply to the control plane. Firstly, taking a packet out of the fast path processing does not automatically mean that it is punted to the control plane (what is the control plane of a networking system?). Also, the new text suggests that the mechanism described in the draft "simplifies operations to a greater extent in SR networks". It is not clear how that is achieved. Is that the result of transporting an echo reply over the MPLS data plane rather than, as defined in RFC 7743, IP network? If that is what you see as the advantage, could you please expand on why and in which case transporting the echo reply through MPLS simplifies operations in a multi-domain SR network?
<Shraddha> In terms of simplified operations what I meant was any MPLS capable node can be used in return path and not necessarily an echo-reply relay capable node.
If every node is echo-reply relay capable, there is no big advantage for operations. I agree with that. I have removed that sentence and also modified the statement regarding control plane.
Pls check the latest version and let me know if it looks good now.

GIM>> As I've noted earlier, it is not clear how ASBR responds if the local policy prohibits it from participating in the described traceroute mode.
<Shraddha> That’s a good point. I have added this scenario and introduced a new return code in the reply path TLV to indicate this. Basically if ASBR's local
Policy does not allow it to send return path TLV, traceroute procedure for dynamic path building will encounter error and other means such as static
Return path through supporting ASBR need to be used by the operator.


GIM>> I think that the new text requires thorough analysis of how the Downstream Detailed Mapping TLV is handled by the remote domain. You would agree that exposing the inner topology to an external system poses a severe security risk.
<Shraddha> The procedures in this document are expected to be used across multiple domains that are under same administration or closely co-operating administration. 
                        Exposing internal domain details to a legitimate source is not a problem but these procedures can be used by an attacker to get internal
Domain information which is a security risk. I have updated security consideration section and pointed to RFC 4379 that proposes possible security mechanisms. 
Yes I agree that there is scope for more discussion on this topic and probably more comprehensive security measures to be added.
Have posted latest revision and attached the diff here in this thread.


Rgds
Shraddha



Juniper Business Use Only

-----Original Message-----
From: gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com> 
Sent: Tuesday, June 22, 2021 7:21 AM
To: Shraddha Hegde <shraddha@juniper.net>
Cc: mpls@ietf.org; i-d-announce@ietf.org; mach.chen@huawei.com; adrian@olddog.co.uk; huubatwork@gmail.com
Subject: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt

[External Email. Be cautious of content]


Hi Shraddha,
thank you for helping me with detailed clarifications. (Apologies for using plain text mode but we've noticed a problem our mailer exposes in the mailarchive). Please find my follow-up notes in-lined under GIM>> tag.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: ShraddhaHegde
To: gregory mirsky10211915;
CC: mpls@ietf.org;i-d-announce@ietf.org ;mach.chen@huawei.com;adrian@olddog.co.uk;huubatwork@gmail.com;
Date: 2021/06/14 22:25
Subject: RE: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}" _ue_custom_node_="true"> Hi Greg, Thank you for the follow-up.
Pls see inline for replies.
-----Original Message-----
From: gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com>
Sent: Monday, June 14, 2021 5:50 AM
To: Shraddha Hegde <shraddha@juniper.net>
Cc: mpls@ietf.org;  i-d-announce@ietf.org; mach.chen@huawei.com; adrian@olddog.co.uk;  huubatwork@gmail.com
Subject: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
[External Email. Be cautious of content] Hi Shraddha and Authors, thank you for updating the draft. I've reviewed the new version and couldn't find most of my comments addressed. Could you kindly help by pointing to the specific changes in the draft that, in your opinion, address my comments @  https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mpls/wmd0wbToaCEtDhgd2gFcX2HzG90/__;!!NEt6yMaO-gk!Rw6JdmD9WO__g0GzLwDiRtgamBQBekpwXb-QKJzwwfZB14cHNoFoYk7utpZBQaKX$  ?
<Shraddha>
Comment: I couldn't find a sufficient technical explanation for introducing a new mechanism for the inter-domain ping/traceroute in addition to the one described Addressed in section: 1 Introduction
Diff:
GIM>> I see that the new text again characterizes RFC 7743 as requiring that an ASBR passes an echo reply to the control plane. Firstly, taking a packet out of the fast path processing does not automatically mean that it is punted to the control plane (what is the control plane of a networking system?). Also, the new text suggests that the mechanism described in the draft "simplifies operations to a greater extent in SR networks". It is not clear how that is achieved. Is that the result of transporting an echo reply over the MPLS data plane rather than, as defined in RFC 7743, IP network? If that is what you see as the advantage, could you please expand on why and in which case transporting the echo reply through MPLS simplifies operations in a multi-domain SR network?
Comment: Three types of SID sub-TLVs are defined, but only use of one is mentioned in the document.
Addressed in section: 8
Diff:
Comment: I couldn't find an explanation of the relationship between IPv4/IPv6 Node Address and SID in Type 3 and Type 4 sub-TLVs, respectively
            Also, in which scenario the SID field in Type 3 and Type 4 sub-TLVs is recommended?
Addressed in section: I would recommend reading  sections 6, 7 and 8 to get the complete description of how Type 3 and type 4 can be used.
Diff:
GIM>> The new text suggests that a local policy controls whether an ASBR cooperates with the described traceroute mode. I can assume that the policy would, for security reasons, prevent ASBR from participating. I couldn't find an explanation in the draft of what happens in that case.
Comment: And further, traceroute mode is called out of the scope of RFC 7743. I've read the explanation of traceroute in the draft, and I don't think it is a work Addressed in section: section 7.2
Diff:
As I've noted, I am not sure what is referred to as "the control plane" in the draft in describing the solution defined in RFC 7743. RFC 7743 itself does not, as I understand it, require that an Echo Reply is sent to the control plane  at any step.
<shraddha> RFC 7743 describes how to relay the echo-reply in section 4.4.
The relaying node receives the echo-reply packet with destination set to relay node. Then the relaying node need To examine the "Relay Node Address stack TLV" to find the next relay node or the initiator and send either relayed- Echo-reply or a normal echo-reply based on whether there are further relay nodes to be visited.
My understanding is that this complex operation of finding the next relay node from the packet and replacing That into the destination address of the packet would require packet to be sent to control plane and cannot be done in forwarding plane.
GIM>> I think that when some processing is done outside of the fast path that is not necessarily means that that function must be completed in the control plane (which is still not clear what the "control plane" means in the context of this draft). I can imagine that that extra processing is done as bump-in-a-wire as the rate of echo replies is controlled.

 Also relay node receives the packet with destination address set to the relay node. The normal behaviour  of a router for self addressed packets is to send the packet to control plane, the draft does not talk about
GIM>> Though that might be the case, implementations are using special cases to optimize some scenarios.

Any forwarding plane behaviour change with respect to self destined packets.
If you have an implementation that does that, perhaps we can look at whether that is indeed the property of the solution or is implementation-specific.
<shraddha> I would like to understand if you have an implementation where the  relayed echo-reply processing on the relay node is done in forwarding plane. The RFC does not specify explicitly that  relay node processing is to  be done in forwarding plane also does not Provide enough details that would be needed to process the "relay node address stack TLV"  in forwarding plane.
Also, I'm still concern with the specification for traceroute mode in the draft. I have a couple of additional notes to add:
- RFC 7110, as well as RFC 7743 (I've pointed that out in my first comments), has traceroute outside the scope; <Shraddha> This draft has addressed traceroute and provided enough details on how traceroute procedure Works. Let me know if you have specific questions on traceroute procedure.
GIM>> As I've noted earlier, it is not clear how ASBR responds if the local policy prohibits it from participating in the described traceroute mode.

Do you have a concern with this draft addressing traceroute? As long as this draft provides a workable Solution it should not matter whether previous RFCs in the area addressed traceroute or not!
- RFC 8029 (Section 4.3) recommends using the Downstream Detailed Mapping TLV. I couldn't find that TLV being mentioned in the draft. If you believe that TLV must not be used, could you list reasons for not using the Downstream Detailed  Mapping TLV?
<Shraddha> Downstream Detailed Mapping TLV is very much used.
Section 6.2 specifies no changes to RFC 8029/RFC 8287 procedures.
The change is only in processing additional reply path TLV when it comes in echo-request And also in adding this Return path TLV while sending echo-reply.
" The responder MUST follow the normal FEC validation procedures as described in [RFC8029] and [RFC8287] and this document does not suggest any change to those procedures."
If  it is not clear enough, I can update the text as below " The responder MUST follow the normal FEC validation procedures and echo-reply building procedures as  described in [RFC8029] and [RFC8287] and this document does not suggest any change to those procedures."
Let me know if that works for you.
GIM>> I think that the new text requires thorough analysis of how the Downstream Detailed Mapping TLV is handled by the remote domain. You would agree that exposing the inner topology to an external system poses a severe security risk.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: ShraddhaHegde
To:  mpls@ietf.org;i-d-announce@ietf.org ;Mach Chen;gregory mirsky10211915;adrian@olddog.co.uk;huubatwork@gmail.com;
Date: 2021/06/11 01:34
Subject: RE: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
Hi All,
New version of draft-ninan-mpls-spring-inter-domain-oam is posted addressing comments from MPLS-RT review.
Pls take a look and let me know if you have further comments.
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: mpls  On Behalf Of  internet-drafts@ietf.org
Sent: Friday, June 11, 2021 2:00 PM
To: i-d-announce@ietf.org
Cc: mpls@ietf.org
Subject: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt
[External Email. Be cautious of content] A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching WG of the IETF.
Title           : PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks
Authors         : Shraddha Hegde
Kapil Arora
Mukul Srivastava
Samson Ninan
Nagendra Kumar
Filename        : draft-ninan-mpls-spring-inter-domain-oam-03.txt
Pages           : 21
Date            : 2021-06-11
Abstract:
Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane.  A network may consist of multiple IGP domains or multiple  ASes under the control of same organization.  It is useful to have the LSP Ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains.  This document describes mechanisms to facilitae LSP ping and traceroute in inter-AS/inter-domain  SR networks in an efficient manner with simple OAM protocol extension which uses dataplane forwarding alone for sending echo reply.
The IETF datatracker status page for this draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ninan-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TuJNnI5%7B0%7Dlt;br>
There is also an htmlized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5VMFXpJm%7B0%7Dlt;br>
A diff from the previous version is available at:
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5QEnIeV0%7B0%7Dlt;br>
Internet-Drafts are also available by anonymous FTP at:
https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5T0hqLuk%7B0%7Dlt;br>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TdmWWCx%7B0%7Dlt;br>

Juniper Business Use Only