Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 03 June 2020 09:17 UTC

Return-Path: <ketant@cisco.com>
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 2B8103A0F5E; Wed, 3 Jun 2020 02:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.587
X-Spam-Level:
X-Spam-Status: No, score=-9.587 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WOhLdAf9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ni1sCG/J
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 pxEKJdJV2amx; Wed, 3 Jun 2020 02:17:38 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E023A0F5C; Wed, 3 Jun 2020 02:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44000; q=dns/txt; s=iport; t=1591175858; x=1592385458; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+ZL/Cd5fHVml6/s/omcbjriJIhWbQ37zrXun7YoUyho=; b=WOhLdAf9w3fuoj+Dve57jY4HMdt1dO1UW0wSBdH898Kp/BJFTkSLMHfP R2gpFS/57/gTP9Yt+tUWaRXPIPOWZn18CYisH9GbgpeOhM1s6GOhZPV88 UGC9YJEeDElmyNPpGJ716794RAgKjjTe12+3sU93i7OH2x9YS81EUyeFK U=;
IronPort-PHdr: 9a23:Nlg73RIBjgBcqzZBr9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeGvKU/jkLPXJ3W8bRChvaF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGtv4ZkXfuDu04CJBUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mRY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ChBQCzadde/4QNJK1mHAEBAQEBAQcBARIBAQQEAQGCCoEjLykpB29YLywKhBuDRgONRZhQgUKBEANVCwEBAQwBAR4PAgQBAYREAheCBAIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAgESEQoTAQEpAwYFAQQHAgICAQgRBAEBIQEGAwICAhkXFAkIAgQBDQUIEQmDBYF+TQMOIAEOo1wCgTmIYXaBMoMBAQEFhS4Ygg4DBgWBM4Jkgk2HGxqBQT+BEUOCTT6CZwEBA4EtARIBCRoEAQcJFgkCglwzgi2OYhiDB4Ysm0MKglmINJBggmeJDJAyghWQcYFhiB2Pc4E9gloCBAIEBQIOAQEFgWoiZnBwFTuCaVAXAg2QHCQMFxVuAQKCSYUUhUJ0AgE0AgYBBwEBAwl8iyotgQYBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.73,467,1583193600"; d="scan'208,217";a="500577753"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2020 09:17:36 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0539HaeL022436 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2020 09:17:36 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 04:17:36 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 04:17:35 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 3 Jun 2020 04:17:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=detDjGTxP41KTPZc52HcXwtjAiS8YPdNex4zAk1/wB+P8Mo2Q5CJ/iwixGa/cuVn0JkhvrSjtYmzCQ91HdUZINwDe5qf/wMG8SZ6Kb/L16wTZ25mEEpFjX5kTZOW/QmhnFo5J3d8m2OaebwYpUlwft+pZsnPnE0cuck7NF3y/xdkTmrhktXhgDSPQDRT2ChFimFEVt+KmKuIE9EVjvdYYGLAf5p/zkV8mXURexJzRoYy4tHLPsC2Cip0M9XvVNHjT+H7omSh3j3wLawVpiTVpXTlzwel+USY+dqWwZH2NNbHmKfHCbF1qLiZiHPnRzdWIHY+mOBFSKOatQSXlgwSfA==
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=+ZL/Cd5fHVml6/s/omcbjriJIhWbQ37zrXun7YoUyho=; b=Nd7aUlrVKaMCAOwr5uD8hzrzx/w7Rncu3OaBZcG8swWQGzx59KiGoJfeKjBdifMwsg3QU5HfYkDbzDH4vk+yf+uPSW0URlBG8UNmZQT4N0EtbxMOR80BAF8sSmaY9+J3ytXeg7p7x8eAP3ZCjabyyv5fnJebgnxtfNXwYZ+em0maHVT668CDJ5WRnAZbR12aEUP6/J9NNIKVi1AIN1/cHFKl5BAl8H/P4bDXA8A5HdDunwghbj1RVmAczk2SF6HPMI7+EaE3dqOqbrJzhLaf3YmT47AbSO+jCd3uxQ/HGoXvNIZzGVTceGOgQHzGfDA86exT/1etnl6edOELRZr49g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ZL/Cd5fHVml6/s/omcbjriJIhWbQ37zrXun7YoUyho=; b=ni1sCG/JC+h3g8/XLzIpMIDrEHNqlv5EzrL8DJvE9eVRgMD8JsDLvnYmip3Xm7I65ezZzewVP4UZvmyC0Gdqg8BNX3b4vONH/DGqpclgt8v8NyhraxYvjUqylLMc29Bvu848IwlQId/tvLfFiGpvVZlX6soXWNIcLgLz1OCgMLA=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4667.namprd11.prod.outlook.com (2603:10b6:303:53::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Wed, 3 Jun 2020 09:17:33 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%5]) with mapi id 15.20.3045.024; Wed, 3 Jun 2020 09:17:33 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, Loa Andersson <loa@pi.nu>, "draft-hegde-mpls-spring-epe-oam@ietf.org" <draft-hegde-mpls-spring-epe-oam@ietf.org>
CC: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam
Thread-Index: AQHWHpsk6nlFZ6TN2kqqRb0ulI9i7qikhoawgADv8gCAAAKPkIAhJ36AgAAwVxA=
Date: Wed, 03 Jun 2020 09:17:33 +0000
Message-ID: <MW3PR11MB4570D5E2E194A212B2C099B5C1880@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <6eee6cce-b7b3-dcce-b3b8-2229745e778d@pi.nu> <MW3PR11MB4570253C1341AB1D6F8CA6D2C1BE0@MW3PR11MB4570.namprd11.prod.outlook.com> <1717e4b0-17cf-13f7-d1bc-fd9a849418e1@pi.nu> <MW3PR11MB45706309655EAA2FC15A0FCEC1BF0@MW3PR11MB4570.namprd11.prod.outlook.com> <CY4PR05MB3576826D834B4FA93E4AD1B4D5880@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB3576826D834B4FA93E4AD1B4D5880@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-06-03T06:18:56Z; 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=5d9b56cc-13db-4ada-8043-c2f00f7cbf5e; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a090bf11-12b3-4843-9a79-08d8079ef323
x-ms-traffictypediagnostic: MW3PR11MB4667:
x-microsoft-antispam-prvs: <MW3PR11MB46677D77DCC575E1D106696CC1880@MW3PR11MB4667.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04238CD941
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jirp1JzilYfxNmQXPr2winaIP3K+cMJPN+C215FeOTPTnnaLmhExu3YP2ZQu8wXc6PFjDw25WV5Ivh148aKyi7C0bN8tLLUNPBqoqKCGSkLbdqmdFyKD799rEwUiwpRdh1PE/P7rOL2HJB+TwIVmBJ7vIeuItEHK7xaMJvR1fa+/86aTmwRPGlbRzMYFKWH+g5dud5BSDwZskmUmLkL/H6f1NAgZLGeJz780jkVLuXtzcGAUhz5tQ/2L7gDtu5IVC5tLxNldNhYEp8jzU9+NdD0oXWPhhlrpBXR8tS3ogCgWNLOL35NZVVRY86P1mcdb7rCymlShLnrUIXtGXZEr2g7lYAtoaWDmZr9QipO9QueCQfHj9TXSWo6yg+XmcmUsKyk3OJsUQ9DmabLhyc7Ugw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(396003)(346002)(9686003)(9326002)(86362001)(110136005)(55016002)(52536014)(54906003)(2906002)(83380400001)(71200400001)(53546011)(478600001)(186003)(4326008)(66476007)(7696005)(6506007)(26005)(8676002)(33656002)(966005)(5660300002)(166002)(8936002)(66574014)(316002)(64756008)(66556008)(66946007)(66446008)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3XxcTNAgGfw/JaYxed6ISGJ6mY8TVfqDOqSCrxWXe4dcgQ2yXsav+UZf34JL1wH6QQCWqZqDPMRNnbK5A1OQo+/Unwq2sXHUXFTDdJH2BxYGM2qrG9DQ8FwOMpGsa/bAXsXSyVxNCJFm1RoaibKssD16CWXWT1+FrPoiRAAdvBMihF5X7ZN6UjlggTLEDAB5YLI6sOqEooA/C0bEqVGMY0I+2A/flxUQd4/RBJ7x0BChJeDNQPc2lVGueaVrJpfadScHP28jx+QcD5m/IeDP5bfBAgwpkGI7Mw9oigi9p2GuS56Cv/gqI6Edvq4qBvDp27gQnfCCDKJ4bi7Xb8rD5ye8YPL358tt9/Yas6zIabjrRwNrdNvf18We8d0azCYb13igOQvrgue1Rw0LSgEVz+BxcIBTmxW9IikzKpPO+RVByH1jF7yBnSuad4ycavgMbFF0vxQwjx6nBiac6Qu9oOU606vP2otE2VrbTsvjSmo=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570D5E2E194A212B2C099B5C1880MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a090bf11-12b3-4843-9a79-08d8079ef323
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 09:17:33.5023 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ESqRaf9iKCLbml/DmuW9uFt2vyeYGA3YoNYRioTeFpHWkalAP477zteNpm7a3iEO4VbL6XmzkKCNbkCClEdAYA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4667
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BGpsjTf1yNqYtJn3BhnVrudHZ2Q>
Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam
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: Wed, 03 Jun 2020 09:17:41 -0000

Hi Shraddha,



Thanks for your response and update. Please check inline below.



-----Original Message-----
From: Shraddha Hegde <shraddha@juniper.net>
Sent: 03 June 2020 11:49
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Loa Andersson <loa@pi.nu>; draft-hegde-mpls-spring-epe-oam@ietf.org
Cc: mpls-chairs@ietf.org; mpls@ietf.org
Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam



Hi ketan,



Thanks for the detailed review and comments. Pls see inline for response.





Juniper Business Use Only



-----Original Message-----

From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>

Sent: Wednesday, May 13, 2020 9:38 AM

To: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>; draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>

Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>

Subject: RE: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam



[External Email. Be cautious of content]





Hi  Loa,



There is no doubt about the need for LSP ping and traceroute operations to cover BGP EPE SIDs. So the requirement is real and something that the WG should be taking up.



My concerns is that the proposal in the draft is diverging from the control plane protocol semantics for what constitutes the FEC (or context) and how it is to be validated. These are some core aspects that IMHO need to be addressed before adoption while the rest may be taken up during its life as a WG document. I would suggest to wait for the authors response.



Thanks,

Ketan



-----Original Message-----

From: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>

Sent: 13 May 2020 09:22

To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>

Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>

Subject: Re: [mpls] working group adaption poll (wgap) for draft-hegde-mpls-spring-epe-oam



Ketan,



Anything of this that need to addressed before wg adoption?





Authors



I leave the wgap opeb a few extra days to llow you to respond to this.





/Loa



On 12/05/2020 23:32, Ketan Talaulikar (ketant) wrote:

> Hello Authors,

>

> I have the following comments on this draft and would be good if you could clarify/respond.

>

> 1)The FEC description should match the "context" that is advertised in

> the control plane for Peer Adj SID. E.g. the local/remote Interface

> IDs are not being included from

> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr>

> -bgpls-segment-routing-epe-1__;!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIH

> qrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y-5xIny8$

> 9#section-4.2



<Shraddha> The EPE draft mandates interface-ids and allows remote interface-id to be zero.

Remote interface ID being zero does not help in validating the incoming interface which is very Useful OAM functionality. For this reason, this draft recommends sending interface addresses in the PeerADJ SID Link descriptors which is optional.



I have updated the PeerAdj SID section with this information and also updated with the possibility of sending zero In which case incoming interface validation should be skipped. This is to accommodate cases when the advertising node does not send the interface addresses

[KT] Ack – this sounds good to me. Thanks.



>

> 2) For the Peer Node SID, the control plane definition is https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19*section-4.1__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y6sXdlcY$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19*section-4.1__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y6sXdlcY$>  and the FEC description in this draft is not aligned with the corresponding control plane. The Peer Node SID is meant for the packet to be delivered to a specific BGP peer and it does not matter over which interface it is received. So why have those interface addresses as mandatory in the FEC. The only thing the control plane indicates is the peering session itself.

>

> 3) Same as (2) above, for the Peer Set SID, the interfaces are don't care.

<Shraddha> The reason for need to have interface addresses specified is for incoming interface validation as explained above. For Peer Node SID interfaces are advertised with draft I-D.hegde-idr-bgp-ls-epe-inter-as.I have added this to the reference and updated text as to why it is needed. Also the ingress can send 0 pair of addresses in which case Incoming interface validation will be skipped and success will be sent based on other validations.

Pls check -07 version and let me know if you are OK with it.

[KT] I have a concern here. The semantics of the FEC for Peer Node and Set SIDs does not include (i.e. does not care about the interface over which the packet was received). So the link information is in any case part of the response that is sent back to the requester which can perform this validation. I don’t see how it can be included in the FEC definition.

>

> 4) The draft just says that the procedures are borrowed from RFC8287 but I don't think this is so straightforward or trivial. E.g. https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8287*section-7.2__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y3Z0DrZ_$<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8287*section-7.2__;Iw!!NEt6yMaO-gk!W0-Gp88WKnqRfX4kdfeWV8aIHqrXTj0Pzz9Vl-B2ZVn78SFO60XGBDi2Y3Z0DrZ_$>  has the following:

>

>     The network node that is immediately downstream of the node that

>     advertised the Adjacency Segment ID is responsible for generating the

>     FEC Stack Change sub-TLV for POP operation for the Adjacency Segment

>     ID.

>



<shraddha> A new section for EPE FEC validation has been added in -06 version. This section specifies the details when return code 3 Has to be sent. As per  RFC 8029 sec 3.4.1.3 FEC stack change and IS_EGRESS code are treated identically.

" A Downstream Detailed Mapping TLV containing only one FEC stack

       change sub-TLV with pop operation is equivalent to IS_EGRESS

       (Return Code 3, Section 3.1) for the outermost FEC in the FEC

       stack.  The ingress router performing the LSP traceroute MUST

       treat such a case as an IS_EGRESS for the outermost FEC."



I don't see the need to re-iterate RFC 8029 sections in this draft. If it is still not clear let me know.

[KT] Sure. I think we can work through this once we converge on the FEC definition.



> In the case of IGPs, the downstream node does have the label and context for adjacency SID (which is functionally closest to BGP EPE SIDs). In the BGP-EPE SIDs case, this is not always the case. So I believe, it would be better if the entire operation were described.

<Shraddha> EPE SID validation section is added. Pls take a look and let me know if it looks good.

[KT] Same as previous comment.



>

> 5) The ping or traceroute done to any of the BGP EPE SID corresponding to an eBGP session may result in the packet being sent to another entity. The security consideration talk about it, but the problem is not addressed by the remote AS dropping the packets. The security issue is that the OAM packet could expose the FECs and information of the local AS to a remote AS. So it is more as an caveat for the operators performing the OAM operation to be mindful of this fact.

>

<Shraddha> Yes. This was raised in RT review and security section has been updated with this info in -06 version.



> In general, some more description that set the stage for the introduction of the new extensions and elaborate more on the operations (some considerations above on what is mandatory to evaluate and what is optional).

<Shraddha> Sure. Pls check the -07 version which I'll be posting soon and let me know if you have further comments.

[KT] Thanks again for the update. I believe we can work through the remaining/open points over course of time.



Thanks,

Ketan



>

> Thanks,

> Ketan

>

> -----Original Message-----

> From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Loa Andersson

> Sent: 30 April 2020 08:26

> To: mpls@ietf.org<mailto:mpls@ietf.org>

> Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>

> Subject: [mpls] working group adaption poll (wgap) for

> draft-hegde-mpls-spring-epe-oam

>

> Working Group,

>

> This is to start a two week poll on adopting draft-hegde-mpls-spring-epe-oam as a MPLS working group document.

>

> Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org<mailto:mpls@ietf.org>). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.

>

> There is one IPR disclosure against this document.

>

> The authors have stated on the MPLS wg mailing list that they are unaware of any IPRs that relates to this document.

>

> The working group adoption poll ends May 15, 2020.

>

> /Loa

>



--



My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail<mailto:loa.pi.nu@gmail>





Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>

Senior MPLS Expert

Bronze Dragon Consulting             phone: +46 739 81 21 64