Re: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

Deepti Rathi <deeptir@juniper.net> Fri, 20 August 2021 06:04 UTC

Return-Path: <deeptir@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 B0CBF3A0332; Thu, 19 Aug 2021 23:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=tIMClpKA; dkim=pass (1024-bit key) header.d=juniper.net header.b=BmEYyw9k
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 1mWJR6wpivQd; Thu, 19 Aug 2021 23:04:47 -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 CB7B83A02F9; Thu, 19 Aug 2021 23:04:46 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17K64cv1014008; Thu, 19 Aug 2021 23:04:38 -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=vxw38f/j0QBNkSv5ECrln3JwVyOrLoaI5+aWNMT85qI=; b=tIMClpKAqxOOLjN66wWiTULdT5ccy9YfYnYuzwmmCkOiqDGxjnMndymIVeMLTV0avZMc oS96/eII8aLHZ3L2ot/YgRvz8vzsg+E1WG7pu2joMxMNkrpwS/I8ydE5algJ7cA+nk+n xtHbICLmaTpcD3r9j3SDw9AFfvUR9glbH3q2cpWUhZ7MZpnAXijNz8KqFcV2I01qM2QQ 1uieDboVYZRl9C2hkbbLArBAUH5VCzo6e4Ql5ng1COKTq1/VPrWD1EiZZz7kC/es7i1e WBTYiuCCg1YQ857FwO6AKch2gitukMp9FdVZO1x/fvcOrWsvXx/6JIcVEEwdl6c6jTMN sQ==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2048.outbound.protection.outlook.com [104.47.66.48]) by mx0b-00273201.pphosted.com with ESMTP id 3aj1v2gfyd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 23:04:37 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PuylM7y3/MS/1K6IuIj0XwUa7Eh64UOVGnEi3eKvKzDwcY++/yrd8LBEwSGzWtp6tPk1Gf0b5sfu64IKdrCVXrhpg+gonKxBCNMCLpC6dM6WCfMdAKLB9r6VmFP/fVVsUUbCewqmkQG1yiLcJ34HIpIQRXOAoCCTBBP1LP2R8U244W01KKqwKNsX28iYmX0YAFQ0+1Ea8/QMx78PkrNaQl2GZEFkYhpu3xuii4xyQdqoHqrULQLC8V08SpL9FLMSnLxJDkgjk35ir1+Rm0RPdgZRBWv+IG/eQhmVaTTvujtvmRupuTvD2OoRVCxoUXB3YMtT491bduwUPHoOreaZvA==
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=vxw38f/j0QBNkSv5ECrln3JwVyOrLoaI5+aWNMT85qI=; b=B8r5mvP+13Z/u7AxPjxfbuIayKCYU8R/01aFHSTHxvqtbIRzowXgeTt+g+nxH6r0Zr2F8Wr7ln3jJfNUON0nHXsC1sFs17dmPEmgWyR1+12nAZdjPS5KB+eXBpy8aY9DA15ZjCUsSASfE+x/Gv+w/9yqQTWU6sfSmjvhWoM3tzJZ7KeHSFbJH0Jnaek5JdNVGoFMVlbugqHHNt2AaMVcCGYOl9VC1foRE5L+6SIv1Yo/wL0g6enMTxl92rzmS4yS2dF/KI8igBTqIVFMLCpU2wIT4dd2SbEE9JJJCEhvLRInvRkV6AewDFyGpRwDZ2Qmn7RHWO/ubiVT3tOo5uBhjw==
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=vxw38f/j0QBNkSv5ECrln3JwVyOrLoaI5+aWNMT85qI=; b=BmEYyw9klYKeB1ABPrJQkZGs+JUfCvku0UDYrBhBw+ZfTbiNXT+W6dC0vhXHibCtIgb9pXDbx9aQU5ktKQSO98K7oNEazx7PoBCShPAOKYJIeP7ZoWGl8Ccbv5vv8pZfB7lw00tlb3JR1YuJMqENjb56MI1fWW8LQKNBjrORM1o=
Received: from MW4PR05MB8810.namprd05.prod.outlook.com (2603:10b6:303:12d::12) by MWHPR05MB2895.namprd05.prod.outlook.com (2603:10b6:300:5f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.17; Fri, 20 Aug 2021 06:04:28 +0000
Received: from MW4PR05MB8810.namprd05.prod.outlook.com ([fe80::69c0:d94f:3933:751e]) by MW4PR05MB8810.namprd05.prod.outlook.com ([fe80::69c0:d94f:3933:751e%3]) with mapi id 15.20.4436.009; Fri, 20 Aug 2021 06:04:28 +0000
From: Deepti Rathi <deeptir@juniper.net>
To: Italo Busi <Italo.Busi@huawei.com>
CC: "draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org" <draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
Thread-Index: AddhI9L1yOOS4MxaRt24LmA/Qqe0iAAl+X+wAGq/JjAABL76EANyqPmgAuBg1mAAEl2/UAYecOMg
Date: Fri, 20 Aug 2021 06:04:28 +0000
Message-ID: <MW4PR05MB8810AD51EC1D1A96D3E9C202AFC19@MW4PR05MB8810.namprd05.prod.outlook.com>
References: <fa5f1e295e0946c5928613f49e24bddf@huawei.com> <SA1PR05MB8439C398FBD5807756038B8DAF0E9@SA1PR05MB8439.namprd05.prod.outlook.com> <CY4PR05MB357687AE89CB6A0842D1D315D50E9@CY4PR05MB3576.namprd05.prod.outlook.com> <SA1PR05MB843989D62791B28BFFF80B52AF0E9@SA1PR05MB8439.namprd05.prod.outlook.com> <MWHPR05MB3247BF6F1FF241F8BD013D8CAF1C9@MWHPR05MB3247.namprd05.prod.outlook.com> <93cecf5e94e14269ac77127fdf7eee73@huawei.com> <MW4PR05MB8810C0E8FD6A5A374A6506B9AFE29@MW4PR05MB8810.namprd05.prod.outlook.com>
In-Reply-To: <MW4PR05MB8810C0E8FD6A5A374A6506B9AFE29@MW4PR05MB8810.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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-08-20T06:04:25Z; 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=8be7eeff-3ec5-4a59-8dfd-849f1c38836a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e450a369-df21-44f2-60fc-08d963a05ee8
x-ms-traffictypediagnostic: MWHPR05MB2895:
x-microsoft-antispam-prvs: <MWHPR05MB2895B89FD77407DD4D3A1DEEAFC19@MWHPR05MB2895.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lo7S4f5vn0qOhls0ntSpRQwztYBwm/KotkYNmNzk0DoovRUY0d/79LBsStUVimJGfb8wewSdJLOsOXAlA1pZ0Ht2hRZn3cKt9JKPR5qxBEDzfSL0g6VPUEjEJgsqIUaY5bPCaBmHcIEseDPQkRPWQGSf9+pcGgZ9pZ3FQFOKaoN5ldrYYefuAQ07pSCxXN+O98djlR2YJh5ZxZMve2247MFEfR50gAzjGhWU+Us4Dirp801atE11ownKc229FJCjPPjtsBVYfA3n2zhZ/NSZYmhzIkDTRvA+pD+LFMHM6falHkywMFbxi3tDJiWGTJjCIz0Ku1rIkbyZycID6KK/u0LFCnmNQoLRwnjwv8q/ahrmvO93yzKxsIJDMb/nQk4I9rcYuxtaTmyyocsu+9rKo6wIIG2B4kpDCbhAuiFbiR1sypLOrYGIp302hWX28UckwUp+RGFZuzFWFAnWe+V6gj0/yHs4WvTTfUMpCwAlBmxdaKQ0Y/jSk6QwmfOKtaZl1DwsaUMP0C8ocNFadzKUkON65Ubv5wC4tGbd8kRej75cd/9+fG5nMZvpUlkVUMv7NAs300EM9PzzgDc91CC77wj+WsKRETSkMlq2EqtmNiFasOu2/bT+XrjGLUBD34FZAi0qD88+2AijY8CakHnB/Gd3NQ8ZWYRwv5pSdmYIVnjLPKtFTTrdLDdwbf/KD5V/5+BbmPdOW2OxPQbCou/u2A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR05MB8810.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(396003)(39860400002)(376002)(66446008)(71200400001)(122000001)(8936002)(86362001)(52536014)(53546011)(5660300002)(9326002)(55236004)(38100700002)(76116006)(66556008)(9686003)(55016002)(66476007)(7696005)(8676002)(33656002)(38070700005)(6506007)(54906003)(6916009)(478600001)(64756008)(66946007)(83380400001)(4326008)(66574015)(186003)(2906002)(316002)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?GVS+SZDR0nZd7drDLPx1mq9WRSfXWzpCq75+7UTsl10MYgtswYGCsOMf5U?= =?iso-8859-1?Q?sFeMBF2lMDlr/KLIWlvfiNQH7jHjKhfkCxYW9MV5/yJOht2yDlR4klTdXr?= =?iso-8859-1?Q?Fx2MRq5WJSmCb+OZeS6p1tAj5jcuZVCCWXG7TU+n5ZGBBzw7lccL+4kcvc?= =?iso-8859-1?Q?LmdNsTcC2LVL8UpFc+0BA+BNKH/rZ3fqqHlKpqZt8Zd8nS3jrS7KAiUpcx?= =?iso-8859-1?Q?ujoqFwQp17iWccchzv3ozKxm4axSXIA4v11MTrdGMb97DmtuaM6NRdgKaw?= =?iso-8859-1?Q?EhuujzkcEfTVNxAuhUVvVRJQRUrRF9c7FNJ9wmnKFzWwtswvCu1+GKWoxl?= =?iso-8859-1?Q?mbvPIdIcSv/jgphLvb8muNGgJyInLpDpmNgoQJNV4tRS13V6NF+k9kMZ6f?= =?iso-8859-1?Q?xlLikhEDprGQoWTb/cR9PX35ZoTfiabh9rGUlElDlRcyQXj5M0rnWR0Cis?= =?iso-8859-1?Q?6q8XDiZCVN2Omc1I4tQ0MVo659KyxZhSLqKSjoph358wX4gRu84MX6H/0X?= =?iso-8859-1?Q?wfulMEn/faoAO3gleDP/Oz6fRMXaA02ienOIxbu49q30K9T71uXfJMlTBh?= =?iso-8859-1?Q?zojx162H70czIXVpyTBYT5VBgYZ50rQDkXCRNgwzdCLSqEX6+xthbnV4iV?= =?iso-8859-1?Q?ta+NoMvJHRmYmRuyifFpe5PX+NzLpmcuqJWkRRYfU9589KMzvHMngkHgSN?= =?iso-8859-1?Q?LxN/9MtjDHGwsCXQkktmKIy35+L5HNe2sHH87QAgMf5FvAj7At0LJ/Vxnk?= =?iso-8859-1?Q?rAP1Tq6TsGNtTaJbNEMeMIniEOBKC9Fsin5jWZiSfOQMb2TdNGDLFvU5AZ?= =?iso-8859-1?Q?sH97phrQNtYqSK/0G3WY0JcPEpKkav+wW9dwojZUnyoHUkjDYgJC0qT0hs?= =?iso-8859-1?Q?5uR3KcfIKZBLif5VVhstbm4QLzKK6a6TLFC4noByKTX3i6MvyMaTct4Elm?= =?iso-8859-1?Q?gy2H31P3mIMrAH+bDg1CYuoB/m4ZSidnFUskq+3isCv5ibQIUCWYh+ADty?= =?iso-8859-1?Q?FHF3RDidRuOgs300XSEvuc+wYbhpsgPEK62r848LOrk0rkmzgP5NqNucUz?= =?iso-8859-1?Q?vIhOXwhOjpS7v4horj1jxKZwljhli6759xfe5n75eHvZx2kjAeVMYcHqle?= =?iso-8859-1?Q?ujno6pFjodkXx/whOfV3A4UOVw+RNzMSY+aue4/b0V8O7yprew58X6Xdvd?= =?iso-8859-1?Q?gb/K8IYSJ2myId/voHoJIAv+JE6bYxJqPsviXt8I4rgLmBt5gjvfn5IXks?= =?iso-8859-1?Q?E6Gw/0v1Jpjhcqxkk7D34gTeoNBVe2kgiepJef/c11/KXkmApio0UCQDuF?= =?iso-8859-1?Q?Ch6G7s2vgtVaElPyscyIgI3ELkdhuGF4bs5enbnpwO0fT/I63WSBCCFe3m?= =?iso-8859-1?Q?pKKk8G0X/U?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW4PR05MB8810AD51EC1D1A96D3E9C202AFC19MW4PR05MB8810namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4PR05MB8810.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e450a369-df21-44f2-60fc-08d963a05ee8
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2021 06:04:28.6118 (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: 188yxm1eKhsF9hSCDplTngmffrD8LtBcbYre/jlRCJFzGeknpnMOm3ZZsMb5sFj/egKawgsbUZu4ZG8tTJwy8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2895
X-Proofpoint-GUID: uvKm4EFVeF-bWTuLQdPOR4kzV6u3yApR
X-Proofpoint-ORIG-GUID: uvKm4EFVeF-bWTuLQdPOR4kzV6u3yApR
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-20_02:2021-08-20, 2021-08-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 adultscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108200034
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/KQ9B4L4TGIBeTWE6GbRALjXaxKI>
Subject: Re: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
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: Fri, 20 Aug 2021 06:04:54 -0000

Hi Italo,
Both the below comments has been taken care in latest version of draft.

Regards,
Deepti



Juniper Business Use Only
From: Deepti Rathi
Sent: Tuesday, July 20, 2021 8:06 AM
To: Italo Busi <Italo.Busi@huawei.com>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org
Subject: RE: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

Thanks Italo for reviewing the draft and comments.
I will update the draft for the 1st comment as per suggestion.

For 2nd comment, yes in either case (with/without EGRESS-TLV validation), best-return-code will be 3. So let me discuss and get back on your suggestion.

Regards,
Deepti



Juniper Business Use Only
From: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
Sent: Monday, July 19, 2021 11:40 PM
To: Deepti Rathi <deeptir@juniper.net<mailto:deeptir@juniper.net>>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org<mailto:draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

[External Email. Be cautious of content]

Hi Deepti/co-authors,

Thanks for having addressed my comment and my apologize for the late reply (too busy with other topics in the last few weeks)

It is now clear to me what is the problem you are trying to address and why the existing solutions are not suitable, so the document is ready for WG adoption

I have a couple of comments which can be addressed as you prefer before or after WG adoption and hopefully could help improving the clarify and the solution


  1.  I have been a bit confused by this text:



>   ... When router in the label-stack path

>   receives MPLS ping/traceroute packets, there is no definite way to

>   decide on whether its egress or transit since Nil FEC does not carry

>   any information.



I would propose the following rephrase:



>   ... When router in the label-stack path

>   receives MPLS ping/traceroute packets, there is no definite way to

>   decide on whether it is the intended egress router since Nil FEC does not carry

>   any information.



With a reference to your example, my understanding is that if the MPLS ping/traceroute packet is mis-delivered to an incorrect destination (e.g., R8), R8 will behave as R7 and set Best-return-code to 3.



I do not think there is any issue if the packet arrives to an intermediate node (e.g., R6) since R6 will set Best-return-code to 8.



  1.  With the current rules, the solution works if and only if all the egress routers are upgraded to support the EGRESS TLV. Otherwise, if the MPLS ping/traceroute packet is mis-delivered to an incorrect destination that does not support the EGRESS TLV, that egress router will behave as the intended destination and set Best-return-code to 3.



I am wondering whether a new return-code should be defined to report that the  EGRESS TLV has been checked and validated.

My 2 cents

Italo

From: Deepti Rathi [mailto:deeptir@juniper.net]
Sent: lunedì 5 luglio 2021 04:21
To: Deepti Rathi <deeptir@juniper.net<mailto:deeptir@juniper.net>>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org<mailto:draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec


Thanks Italo for the comments.

I have posted the new version of draft taking care of all the review comments.



Regards,

Deepti




Juniper Business Use Only
From: Deepti Rathi <deeptir@juniper.net<mailto:deeptir@juniper.net>>
Sent: Thursday, June 17, 2021 7:08 PM
To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org<mailto:draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec


Hi Italo,
Please find my comments inline.
I will update draft for:

  1.  why "NIL FEC + EGRESS TLV" and not Generic IPV4/IPV6 FEC.
  2.  Backward compatibility.

Regards,
Deepti



Juniper Business Use Only
From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Italo Busi
Sent: Monday, June 14, 2021 7:26 PM
To: 'mpls@ietf.org' <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

[External Email. Be cautious of content]

Hi all,

I have been selected as one of the  MPLS-RT reviewers of draft-rathi-mpls-egress-tlv-for-nil-fec-04

>>IMHO, being able to use LSP Ping/Traceroute perform to validate only the data path and not the control plane state makes sense but I think that the draft requires more information about the problem that >>it is trying to address and why existing solutions are not suitable
[Deepti]:
NIL FEC is used to traverse the path without validation for cases where the FEC is not defined or routers are not upgraded to support the new FECs (like newer features, explicit-null, router-alert etc).
But it is a very powerful tool to check any combination of segments on any data path.
Since it does not carry any information to identify the intended egress/destination,

  *   Mis-forwarding of the packet is possible
  *   Not possible to figure out mis-configuration of label stack
But in any case it will always return success even though egress/destination is not the intended one which is not desired.
To overcome this and to provide minimal validation, EGRESS TLV is added in the packet. This will help to do egress/destination validation.
NIL FEC processing will be same as defined in RFC 8029. This draft is for addition of EGRESS TLV as extension to NIL FEC for path egress/destination validation.

>Let me try to clarify my confusion after having read the draft

>Unless I am missing something, section 4.4.1 of RFC8029 already provides support for checking only the data path and not the control plane state:

>  If the outermost FEC of the Target FEC stack is the Nil FEC, then the
> node MUST skip the Target FEC validation completely.

>The draft mention some challenges with the current definition, but it seems describing only one potential issue:

>   ... When router in the label-stack path
>   receives MPLS ping/traceroute packets, there is no definite way to
>   decide on whether its egress or transit since Nil FEC does not carry
>   any information.

>However, I am not sure about this issue: looking at the example in the draft, my understanding is that R7 will reply with code 3 while, in traceroute, the intermediate nodes will reply with code 8.

>Reading the procedure in section 4.2, I am wondering whether the real intention is to be able to validate the prefix X in R7, rather than the SR path toward R7.

>However, in this case, it is not clear why using a FEC for the prefix X instead of the Nil FEC is not suitable.

[Deepti]: The real intention is to reach the correct egress/destination node.
The details of generic FEC and validation procedures are not very detailed in the RFC 8029.
The use-case mostly specifies inter-AS VPNs as the motivation.

Certain aspects of Segment Routing such as anycast SIDs required clear guideline on how the validation procedure should work.
Also Generic FEC may not be widely supported and if transit routers are not upgraded to support validation of generic FEC, traceroute may fail.
So instead of adding such clarifications to generic FEC, we went with new EGRESS TLV in Nil FEC.
Its an optional TLV so the procedures will work fine even if transit routers are not upgraded.
While we clearly specify the processing of egress tlv so that all SR cases are well specified.

Since explicit path can be created using node-sid, adj-sid, binding-sid, anycast-sids etc. EGRESS TLV prefix will be derived from path egress/destination and not based on labels used in the path to reach the destination.

I will update introduction section of draft with this comparison.

>>I also think that section 5 requires more details about how backward compatibility is achieved. What is the behavior of a node that does not support this solution when it receives the EGRESS TLV?

[Deepti]:
Backward compatibility on egress-node:
On egress/destination, it will ignore EGRESS TLV and use current NIL-FEC procedure with return code 3 but egress validation will not be done (same as RFC 8029). So we wont know for sure if packet has reached the correct path egress.

Backward compatibility on transit-node:
If the transit node doesn't support, it will use current NIL-FEC procedure and send return code of 8.

I will add section in draft for backward compatibility.

Italo